Opinion: Why You Should Pay for Free

[In this thought-provoking opinion piece, Unangband developer Andrew Doull discusses ways to support smaller game developers through alternative means, advocating for the expansion of a new category: 'full time developer paid from voluntary contributions from a wider community'.] The Amateur has championed the cause of free -- those people willing to spend their spare time chasing a dream and making it reality. In this opinion piece, I switch sides and argue why you should pay for your games -- even to people who just don’t want the money. Imagine a large number of people have a pressing need for a piece of software (or game, potentially): and within that pool of people, there are enough talented developers capable of producing that software in a relatively short space of time (say a week) who are willing to make it available as open source or free upon completion. But development of the software has a fixed cost associated with it that is not rational for any one person to pay for: say a patent which has a $100,000 licensing fee. The large group of people agree to distribute the cost between them evenly, and the software is written and released as version one. If you replace the ‘willing to work for free’ and ‘fixed cost’ with ‘programmer salaries’ in the above example, you would be describing a situation not dissimilar to how commercial software and/or game development works -- but with a couple of significant differences. The most obvious one is that the costs of commercial software development are not known in advance, and the payment from customers is acquired retrospectively rather than up front. In this sense, commercial software is more altruistic than free software: the developer is willing to give money away for free, paying staff and other incurred expenses, without even the promise of costs being reimbursed. But before you choke on your free-as-in-beer, let’s go back to the example. Version 2.0 With version one of the software released, the needs of the community who’ve agreed to pay for the costs have been met, and the talented developers go back to their day jobs. ‘But what about version two?’ a smaller group of the original community replies. 'It’s obvious that we need widget X in the program as well.' Unfortunately, no talented developers are sufficiently interested in widget X to devote time to version two. Or perhaps only a few of the original talented programmers are interested in it -- and the time to deliver widget X stretches into years, rather than weeks. And widget X doesn’t satisfy those people who wanted widget Y but weren’t outspoken enough in the community to recruit any developers to their cause. How do you incentivize the developers willing to work for free so that their efforts are best spent representing the community? It turns out auctioning the developers' time is the most appropriate mechanism for this. And short of creating an artificial currency, money is what you’ll be bidding with. This artificial example is intended to start you thinking about the role of money for programmers who are willing to work for free -- in other words, whether you should pay for amateurs. In reality, the ability to incentivize development of features by auction is only a recent phenomena, unique to the open source community -- the historic equivalent has been profit. The Prophecy Of Profit Profit is, essentially, overpayment for a good or service. A rational group of individuals should never pay more than the costs incurred in developing something, because otherwise they could start a non-for-profit company themselves and develop it instead. But this seldom occurs in real life, because the costs are never known, and the same good has different value for different individuals. We are willing to overpay companies for their services because of these unknowns, and the companies are rewarded by deriving a profit for doing so, provided they are able to cover their costs. But how does profit help someone who is willing to work for free? Well, it turns out, profit does something other than reward companies for risks in developing a required good -- it also causes them to continue to innovate after the good has been developed. Historically, profit is reinvested into a company to reduce the cost of producing subsequent copies of that good; in the world of software, where the marginal cost of reproduction is effectively zero, profit is used to extend the utility of the good so that it will satisfy new consumers, or to release newer versions of the good which will be repurchased by existing customers. That is, profit is what enables version one of a piece of software to turn into the version two that best matches the requirements of those people willing to pay for it further. Id Software released Doom as shareware, and has made, or will make, all subsequent games they’ve developed open source after sufficient time has passed that they are not making a significant profit on them. But the only reason they’re able to do so, is that version one (Doom) made them enough money that they were able to invest in the risk of developing a commercial release. Another example: Dwarf Fortress is an incredible, baroque, deep world game, only made possible because enough people are willing to donate money to enable Tarn Adams to program full time (and then some). In addition, World of Goo was pirated approximately 90 percent of the time because it was unencumbered by DRM. The reason it wasn’t 100 percent is that enough people cared about the game and the developers to want them to profit from their endeavors, even though those same consumers could have got the game for free. In this era, it is straightforward to acquire a pirated copy of any game released. Furthermore, there are enough free games available that you could spend the rest of your life playing new, addictive, delightful games without ever having to invest another cent. But if everyone did so, we would not get the sequels, the innovations and the failures that we do. How Much And For Who? The complication, of course, is that you do want to support the tireless, inspired, passionate amateurs, and you don’t want to support the monolithic, faceless, DRM-loving corporations (Otherwise, why would you be reading this column?). How do you go about it? If your favorite developer is smart, he’ll have set up a tip jar, or released the game as shareware, so that you can pay a recommended amount to incentivize him (or her) to continue working. If you value the game less than the recommendation, you have a problem, but I’m sure most developers in this position will accept partial payments. A little research may be required to get the developer’s details directly (especially if they’ve released via Steam or another digital distribution platform). If you want to pay more than the recommended amount -- no problem. Buy additional copies and gift them to people, even if they are never likely to play the game. If there is no clear mechanism for payment, you have more work to do. It may be just that the developer has not thought to make this option available – in which case pestering them repeatedly may allow you to pay them. Or it may be the software is released under a license that does not allow the developer to profit from the software. The GPL allows for this, but other licenses may not. In this event, you’ll have to give money to the developer directly as a gift. The most likely issue will be that there are multiple developers working on the program, and there is no clear mechanism for apportioning the profit. This is how friendly amateurs turn into faceless corporations -- corporations at their most simple are a mechanism for rewarding individuals from a shared pot of money. And as soon as you have the possibility of sharing money, someone will be looking to profit at someone else’s expense. No matter how altruistic the participants, there will inevitably be a third party capable of persuading one of them otherwise, if enough money is involved. What Do You Get? In order to avoid this potential conflict of interest, it may be better to set up a non-for-profit company with specific funding goals. An ergonomic keyboard, a new development box, a test farm, dedicated hosting for the source code repository, paying the lead developer to work a day on the code per week, where the goals are stated in advance and the money channeled towards these goals. This is something you can do without directly involving the developers -- although they’re in a better position to coordinate and publicize this. It is these incremental goals that allow a developer to realize the benefits of profit without having to work full time on the code base. But this, ultimately, is many amateurs’ dream -- to be able to dedicate themselves solely to game development, instead of working in their spare time. I look forward to the day I can argue to extend the definition of amateur to ‘full time developer paid from voluntary contributions from a wider community.’ [Andrew Doull is an IT manager from New Zealand, now based in Sydney, who spends his free time developing Unangband, a rogue-like game, and blogging at Ascii Dreams.]