In his 1999 book, The Cathedral and the Bazaar, Eric S. Raymond describes and advocates for the “bazaar” style of development. He argues that it produces higher quality software and higher rates of innovation, the Linux kernel being the prime example of the bazaar method. I agree in large part with the analysis, but it is not uncommon for me to see people online generalising the analysis to include games. This is a fallacy, let me explain to you why.
Imagine you’re Leonardo da Vinci and you are painting the Mona Lisa. You have a vision for how the artwork will look, what colours/textures/forms/lighting you intend to use and how that supports and colours the viewers experience of the artwork. You spend high amounts of effort figuring out how the different elements of the artwork interact with each other to produce the desired total artwork. Now imagine you had a coartist and you both paint the painting at the same time from two different ends of the canvas. There will be instant conflict of goals that needs to be resolved, and when you have produced the final artwork it will probably be biased towards one of the two artists strong vision. You could probably make it work, but the difficulty is much higher because of the communication required. Here we see the difference between most software and art.
Two features of a program can be very seperate, Linux’s graphics drivers don’t depend on how the disk driver was implemented, Blenders sculpting tools can be developed without concern for camera rigging. This is not the case for art, two corners of a painting cannot be developed without concern for the other. Two seperate artworks can be made indepentantly, but all the internal elements of an artwork must be developed in an interdependent fashion. The consequence of this is that artworks don’t lend themselves to bazaar style development. As the amount of contributers rises the amount of shared knowledge goes down which necessitates more communication, something you don’t have much of when collaborating over the internet. I imagine most artists don’t think about this because the cost of communicating with yourself is zero.
Games are art. It is though a very young artform and because of that many doubt it’s legitamacy. However the same would have been said about films when they were first invented. Never the less they are art. Which implies that they must be developed in a cathedral style if they are to reach the hights of other artforms. This poses a problem, other software can be developed by large groups of developers spread out over many companies or homes. But games by their cathedral nature need many man hours of development from a small group of developers. This means that for a serious game to be finished in a timely manner or even at all the developers need to be working fulltime. It took the developers of The Witness 7 years to finish their game. That’s a lot of salaries to be payed, and I don’t think it’s a stretch to say that games such as The Witness wouldn’t be possible had they not been able to sell their game to the end user.
Games need to be proprietary to be able to sell. If you disagree with this statement then you are very welcome to go out and spend years of your freetime making a FLOSS game. I truly wish you the best of luck. But the experience of most game developers, big and small, is that when you add a way for the end user to play the game legally free of charge, sales go down, a lot. (Playing a game for free despite the law, piracy, and the use of DRM to prevent this is a seperate issue.) The reality as I see it, Games need to be proprietary. However, the common disgust aimed towards proprietary software is not without merit, even for programs we do not wish to modify.
Since we do not have source code access to proprietary programs, we cannot know what they will do to our computers. From a security and privacy perspective, the only safe assumption is to assume the worst, an assumption that has been proven accurate many times. What stops the developer from adding a backdoor into the program? Nothing. But why is that a problem? Why do we care if there’s a backdoors or malicious code in the programs we run? Because all our Operating Systems are inherently trusting. Say you are tired of Microsoft and any three letter agency being able to spy on you through your proprietary OS. You upgrade to a totally free operating system, you’re running a Linux-libre kernel with completely free userspace. Problem solved? Not in the slightest, because as soon as you run any proprietary program, that program has write access to all of your personal files.
The developer doesn’t have to intend to harm you. An independent malicious group could breach your system through a secrity hole in a proprietary application. Giving them full ability to encrypt all your personal files and demand a ransom. It turns out that the unix model of programs relies on inherently trusting the program. An simple model for the creators of unix since they wrote all the programs themselves but terrible in todays climate. I believe we need to move beyond this model of programs. We need to adopt an explicitly trusting operating system architecture. A design that for example, doesn’t allow programs filesystem access and uses hardlink semantics instead of traditional unix style softlink semantics.
“Proprietary Games and why an inherently trusting OS is a bad idea” was written by Sam H Smith on the 5th of May 2021, 2021-05-05.