Free software can be viewed as sort of a public good — everyone can benefit from it. Instead of paying for complete applications, buyers may wish to only pay for specific program elements they want, which the software lacks. Therein lies an opportunity to make money on free software, instead of around it.
Introduction
Seeing how free software programmers seldom gain financial benefit directly from their software, I have sought to imagine a way to sell freedom respecting software on the existing market, playing by its rules. Some of you, having read the title "Pay Per Patch", may have already started seeing the outline of the idea. It is, of course. about selling individual software patches in a way which would provide quality and four freedoms to the buyer, all the while being able to provide income to the developer. How exactly this can be realized is the question I will try to address shortly. I would like you, the free software community, to peer-review it and offer your constructive criticism.
Development as a service
First, it is important to understand why the traditional way of "selling software" is incompatible with freedom respecting software. The problem lies in the fact that the existing market tends to treat software as a tangible product. It is becoming increasingly clear that this is a mistaken approach to selling many virtual goods. But even more, viewing software as a consumable is contrary to the free software definition. Once free software is sold, four freedoms give the user ownership of their copy, including the ability to further make and distribute other copies (freeedom 2). Thus, repeated sales become implausible. Therefore, my goal is to create a viable commercial model that would make the first sale profitable.
Most today's commercial free software models focus on things around the actual software, for example: Support, ads or hardware. I took a different route, one where software development itself is viewed as a service, which — as I will attempt to show — doesn't necessarily require that every company has in-house programmers on its payroll, nor does it necessitate signing any contracts with developers. That there is a demand for software features, and that there are people able and willing to satisfy it is a fact. We need to solve the remaining question, which is how to easily connect the two groups, so that buyers can pay for services they require.
If programmers are paid for work whose end product is released as free software, it follows that complete applications can be viewed as sort of a public good — virtually everyone can benefit from them. That being the case, there is no need for buyers to pay for applications. Instead of paying for complete software solutions, buyers may wish to pay only for specific program elements they want, which the software lacks. All such elements, regardless of whether they be basic functionality or new features, can be submitted in the form of patches. Paying for patches costs the buyer less than it would cost to pay for the whole application, and it ensures further development of the software they are using.
The model
Bazaars
The realization of the Pay Per Patch model as I imagine it is a system based on well established concepts such as bug tracking systems, wiki-like collaboration, and escrow sites. I call the said mix a "bazaar". Bazaars are essentially online meeting places for programmers and software users, where supply and demand converge and create software patches. Bazaars may be accessed via web pages or native clients — both of which use common, well defined protocols to exchange information about patches and users (workers and buyers). Whether the actual data is hosted on few central servers, or circulated around in a distributed, peer-to-peer manner doesn't matter — as long as it is available and searchable on demand. If this sounds too abstract, it is sufficient for now to imagine a bazaar as a single web site which hosts patch descriptions, where the users are programmers and buyers. Indeed, that is one of the possible solutions.
How it works
Let me now describe the nature of patches and processes involved in describing and creating them. Put quite simply, everything is a patch: A new feature, a bug fix, a new set of icons, or even a project fork. Descriptions of patches are submitted by whomever, and likewise edited by anyone in a wiki-like fashion; meaning collaboration, discussions, and democracy. Same goes for their splitting and merging. Once a certain amount of time for editing has passed, under the condition that most contributors are satisfied with the final result, the patch description becomes definite and escrowing can commence.
Money is contributed by interested investors and entrusted to a third party — a micropayment service, a bank, or the website's facilities. Upon completion of the work, the chosen programmer (or a team of programmers) is awarded the aforementioned payment. The motivation behind paying vs. waiting for others to pay is that patches which pay more are more likely to attract the developers' attention, including those with good reputation. Paying ensures the software patch is made promptly and that the end result is satisfactory. Furthermore, if an upper pay limit is set, the more buyers there are, the less they need to pay individually. Naturally, it follows that popular patches (those with more buyers) will be solved first.
Since bugs are patches, to eliminate potential abuse and to motivate the programmer to write quality code, there is also a trial period after the patch is completed, reserved for testing for bugs. The original programmer may fix bugs that were found or, alternatively, a third party can do that for him (eg. a bug hunter), which will then be awarded a part of the total sum. The end result is voted on by all buyers according to their share in the investment. Once they find it has met the requirements from the patch description, the invested money is finally paid out to the programmer(s) involved in the making of the patch.
A global market
Ultimately, it is expected that most bazaars provide publicly accessible data, which they share among each other. This creates a global market for buying and selling software related services (most importantly, programming work). The interface for data exchange can be defined by a committee of bazaars, and all featured servers and clients must be conform with it. Software projects could have their own bazaars, or use specialized hosting services instead. Upgrading revision control sites to share data and provide the necessary requirements is a possible solution. Borrowing from the old should make the transition fairly simple.
Users would be able to choose whichever bazaar they prefer for accessing the shared data. Their choice would no doubt be influenced by extra tools and other provided features. If those features prove useful and are universally applicable, they could enter the official exchange protocol specification. However, submarkets or even private bazaars can be desirable at times. Submarkets may be defined by characteristics such as language: For example, a Croatian buyer might prefer Croatian speaking programmers, and may visit one of his local bazaars. It is also conceivable that companies might want to be able to control patch descriptions, applicants or impose any additional contract terms at their own discretion, and this would necessitate a private (disconnected) bazaar.
One might wonder what is stopping companies that produce non-free software from applying this model to their business? The answer is - nothing really, but this is not a problem. The popularization of Pay Per Patch is in our interest: We get buyers accustomed to paying for features, who can now more easily see the advantages provided by freedom respecting software in comparison to proprietary programs, whether those be vendor independence, peer review of the code, open participation, or any number of practical advantages resulting from having four basic freedoms.
Copyright information
Copyright (C) 2010, Luka Marčetić. License: CC-BY-SA 3.0