You are here

Pay Per Patch: A Free Software Market Model

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.

Free software market should be built on Copyleft

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.

Anyone can describe the patch, and fund its development

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.

Comments

Mike Linksvayer has brought to my attention the existence of a similar model to the one I laid out here. Readers may want to see the Linux Magazine post mentioned here for any "prior art": https://identi.ca/conversation/55248200

To my knowledge, however, there is no infrastructure that offers services described here. Pay Per Patch still needs work, so comments are encouraged. I would like to hear from parties interested in developing this further - please send your e-mails to: luka DOT marcetic AT foi DOT hr

Note also that in order to be able to post ordinary comments here, you need to be logged in.

On the face of it this sounds like a good idea. Indeed I know of a few cases where particular functions or features have been sponsored by "investors" or groups of them. Reimbursing the coder for their time (instead of for the code) is at the heart of any sustainable software development model.

That said I can foresee some issues with this idea. Firstly you have based some of it on a popularity contest. History tells us that popularity does not always give a good idea of what is best. What happens when the developers want to take the software in a new direction but all the users want them to do is add feature X (which coincidentally mimics the leading proprietary alternative). Add to this that feature X might not be a good idea and you start running into situations whereby nobody wants to pay for what *needs* to be done.

Secondly what happens if the patch doesn't meet the expectation of the investor? Do they get their money back? Is this a legal contract or just a donation with strings?

As a programmer I can tell you that there have been several cases when end-users have made requests which have been dangerously sparse in substance. I can also tell you that sometimes I have been asked to add something which would turn the product into something else entirely. While I am all for including users in development direction (indeed user consultation is vital to software development and project management) I worry that there could be undeserved negative kudos for a project simply because "investors" don't get what they think they have asked for.

Having said all that the idea does have merit and it is worth pursuing some kind of infrastructure to support it. Most of the models like this I have seen rely on investors making online payments or pledges and once the target is reached the developer sets about the work.

BTW FSM used to have anonymous commenting but the signal to noise (e.g. spam) ratio was too low. Even with the requirement to have an account you'd be surprised at the amount of spam that gets posted here as comments but requiring logins puts many spammers off.
--
Equitas IT Solutions - fairness, quality, freedom
http://www.equitasit.co.uk

Indeed you are correct, if you fail to convince your users that a version update is necessary, you fall back to voluntarism for that particular feature. This is something not easily solved. I have thought about how to encourage unpopular innovation, but I have yet to think of something better than what we already have - ie "support project" donations. Taking it further, it is questionable whether the community will be able to sponsor research the way mega-corporations do. Pay Per Patch is about commercialization of free software, and right now that means tending to user's needs: Even if that sometimes means waiting for them to realize that they have a need.

>What happens if the patch doesn't meet the expectation of the investor? Do they get their money back? Is this a legal contract or just a donation with strings?

Investors do get their money back, and so we rely on the good will of the majority to judge the resulting patch fairly. I hope contracts aren't necessary (for public bazaars anyway); instead, developers take the risk of not being paid for something their users dislike. However, this may be slightly rectified by a hinted reputation system, using which we can introduce the guaranteed percentage for developer's time - and ensure that the same won't be abused. A similar reputation system may be applied to investors, so we can hopefully altogether exclude "poisonous" people.
Programmers, as well as users are involved in patch descriptions. It is expected that discussions would sort out any misunderstandings. It is only after this patch description making period that the users who remain interested can start investing, and programmers can start offering services (ie bid). No one is forced to invest if their feature is not explicitly mentioned in the final patch description, and only capable and willing programmers should offer their services.

P.S. About comments: I understand that spam is a problem, but comments have now become rare. One thing that might help is removing the confusing "Writing a full post in response to an article" for users not logged in, and introducing a simple "login to post comments" instead. But this may be the CMS' problem.