Version 1.1
Original published in 1999 on lss.com
Original Author: Paul johnson

Paying Contributors

One of the key characteristics of Liberal Source Software (LSS) is that people who contribute to a software package are given some kind of financial reward for doing so. This page outlines some possible systems for distributing the money. However it is important to remember that this is not part of the definition of LSS, and many other systems could be used. If you think you have an improvement then by all means try it out.

Adding Value versus Adding Effort

Work done on a software package (or any other commodity) can be measured in two ways:

1. The value of the inputs. For instance I might value my time spent programming at £20/hour. If I spend 5 hours hacking on a package then I will want to be paid £100.
2. The value of the outputs. For instance my work on the package might result in 8 extra sales beyond what what would have been sold had I not made my contribution. If each sale is at £10 then I have added £80 to the total value of the software.

These two methods of valuing the work done can give very different answers. However the work is only worth doing if the value of the output exceeds the value of the input. Otherwise the exercise was, to at least some degree, a waste of time. If I am paid by the value of the input (my labour) then the project is worse off. On the other hand if I am paid by the value of the outputs I would have been better off doing something more productive, or just enjoying my free time.

But nobody can know exactly what value my contribution is going to add to the project. Even after the 8 extra sales there is no way to distinguish between sales due to my contribution and sales due to everyone elses: software is a cooperative effort. Despite this we have at least an intuitive notion of what constitutes a "large" or a "small" contribution. The problem for distributing the revenue from license sales lies in tying down exactly how much a particular contribution is worth.

Dealing with Uncertainty and Risk

The core problems with valuing a contribution to a software project are:

1. Uncertainty: we have no accurate way of measuring the relative values of two contributions. Given two contributions we cannot even say, with any certainty, which one is more valuable to the project. Suppose a software package has a defect which renders it useless, and hence of zero value. A one-line patch for this defect makes the package usable, and hence gives it a value X. But that does not give either the patch or the original package the value X/2 because neither is usable without the other: their individual values are still zero.
2. Risk: we can try to predict how many licences will be sold, but its still going to be a prediction. There is a risk that we will not make many sales, or that we will wildly exceed the prediction. Quite why exceeding a target is a risk is something I will return to later.

Averaging out the Uncertainty

In Europe packets of loose goods are often marked with a special "e" symbol. This means that the weight of individual packets may vary, but the average packet weight is as stated on the label. The previous system was to require that every packet must be within, say 5% of its stated weight. This was changed when some companies were found to be selling packets labelled 100g which were in fact all 96 +/- 1 g. Rather than trying to place expensive requirements on the accuracy of the weighing machines the regulations were written to ensure that consumers were treated honestly on average.

A similar approach can be applied to dealing with the uncertainties in measuring contribution value. As long as there is no systematic bias in the method we use for measuring contributions the random variations will tend to cancel out. The trick is not to eliminate all uncertainty (although the less uncertainty the better), but to eliminate bias. In areas where human judgement is required the way to do this is to ensure that the interests of the person doing the judging lie in giving the most accurate possible judgement rather than slanting it one way or another.

It might appear that the most effective way of eliminating bias is to use an entirely automatic mechanism. However the errors in such mechanisms are always repeatable. This makes the errors a form of bias rather than uncertainty.

Where Does The Risk Go?

Its all very well saying that software development is risky, but that risk has to be taken by someone. That someone needs to be paid for doing this. Otherwise they won't bother.

Consider a conventional software development company. They pay their software engineers to develop a software package which can then be sold. Before starting the project they estimate the size of the market and the cost of the development. If either estimate is wrong then the company could make a big loss. But no matter what happens the programmers still get paid, at least until the company runs out of money.

What has happened here is that the company has taken on almost all the risk of the development. The programmers only start to lose out once the size of the loss exceeds the capacity of the company to absorb it. But on the other hand the company could also make a fortune from selling this product. If this happens the programmers don't get anything either.

Now consider a scheme whereby part of the employees pay is in the form of shares in the company. If the company does well or badly then the employees will be affected because their share value and dividends will change. Conversely, if the package fails to sell then the company loses less money than if it paid wholly in cash, and if the package is a best seller then the company does less well, because the employees get some of the money through the shares. In effect some of the risk from the development has been transferred from the company to the employees.

The problem with risk is that its effects are non-linear. There is an old gambling strategy of doubling your stake after every loss. Its easy to show that when you eventually win you get back all your losses. The problem is that the strategy assumes that your pockets are infinitely deep. If I start out by betting £1 then after 10 lost games I have to bet £1024, and a few lost games later I'm betting my entire wealth. Sooner or later I will run out of money.

This non-linearity is what makes risk something to avoid unless you are paid for it. If you are paid to take on a risk then it effectively tips the odds of the game in your favour. Once the odds are in your favour you can make a reliable profit (which is exactly what casinos and bookmakers do).

There is now a complicated field of economics and accountancy devoted to the pricing of risk so that it can be traded. This has revolutionized the financial industry over the past two decades. However our aims here are much more modest: we want to understand how the various people in an LSS project can understand and manage their exposure to the risks inherent in software development.

Pooling Risk

If you take lots of risks and put them together then the whole is less than the sum of its parts. If the risk of one loss is p then the risk of two losses together is p² , which is much smaller. Hence if I can pool both these risks then the overall level of risk is decreased. This is the principle behind the averaging of uncertainty discussed above: any single contribution carries the risk that it will be undervalued, but a lot of contributions added together run a much lower risk that they will all happen to be undervalued.

In fact because of this programmers working for a small company with only one product are running much the same risk as the company itself. If the product fails then so will the company and they will all be out of work. The way to reduce this risk is to pool several projects under one roof. That way a few failures will not destroy the company, and the programmers who worked on the failures can be transferred to other projects.

Programmers making a living from LSS need to work in the same way. Rather than dedicating all your time to a single LSS project which might sink or swim, split your time between several projects.

Contribution Points

This is probably the best basic method of dividing up the proceeds from an LSS project. There may be others.

The Basic Principles

• Every time somebody makes a contribution to an LSS project a number of "points" are allocated to them in return.
• If someone holds p points out of a total of T points allocated to all developers then they get a fraction p/T of all licence fees paid for the software.

This differs from a conventional commercial "share" system in two important ways:

1. The points are not tradeable or transferable (except that on the death of the developer they can be assigned to an heir).
2. All revenues are paid to the contributors, rather than just a portion of the profits.

The first difference is designed to reduce as far as possible the scope for fraud. A basic principle of conventional shares is that they can be sold. There are a number of good reasons why this should be. Selling shares allows companies to raise extra capital, and the ability to sell a share allows shareholders to manage their risk and get access to the value of the company. However the ability to sell shares introduces the scope for a wide range of frauds. The regulations required to combat these frauds are onerous and expensive to comply with. The advantage of a contribution point system is that it can be set up quickly and cheaply, allowing an LSS project to start small.

The second difference stems from the fact that software projects require very little equipment (apart from computers which the developers already own) to produce and almost none to distribute. Almost the entire investment is in the form of time spent by the developers. This is in sharp contrast to enterprises producing physical objects, in which significant decisions need to be taken about investing some of the revenue in inventory and plant.

Allocating Points

The biggest question in a contribution points system is: "How do we decide how many points a contribution is worth"?

A single "contribution" can be any size from a one-line patch up to a major module. It can take anything from a few minutes to many weeks of work. It can take many forms, including code and documentation.

In most cases a project coordinator will be able to predict the need for a particular contribution. The simplest example is a bug fix. Many open-source software projects already maintain and publish lists of bugs. An LSS project would include a "bounty" of points for each problem. Critical bugs would be given higher bounties than minor ones, and if a bug is not fixed for some time then the coordinator can increase the bounty on that bug. This will encourage programmers to go after the easy but important bugs initially (where their time is most productive), but allow for the other bugs to be fixed later on.

Many larger contributions can be dealt with in the same way: the coordinator can publish a "to-do" list containing the descriptions of extra functionality and the bounty associated with each one.

The points value of a particular bounty should be proportional to both:

• The estimated time required to do the job.
• The value of the resulting code to the project.

As with the bug list, programmers will thus be encouraged to do the important but easy work first and then fill in the harder items later. If a particular item is neglected while less important work is done then the bounty on that item needs to be increased.

Quality Assurance

A scheme managed by bounties in this way has the great advantages of transparency and simplicity. However it is not sufficient for the coordinator to pay over the points in return for the a chunk of code. Some code is of high quality, other of low quality. Even a single line bug fix can be erroneous. Therefore the coordinator has to take responsibility for checking the quality of the contributions. This will require testing and code inspection. This work can of course be delegated to other members of the project in return for more contribution points. If a contribution is not up to the required standard the coordinator can either reject it ("come back when you've fixed it") or offer only part of the bounty in return. The rest of the bounty can go to someone else who is prepared to fix it themselves. The coordinator can of course include tests as part of the requirement in order to reduce the work of quality assurance.

The key thing about such a system is that both sides can bargain. The contributor has the code required by the coordinator, whilst the coordinator has the points desired by the contributor. The best course of action for both parties is to exchange one for the other at a price acceptable to both. If either party holds out for more then both sides lose.

Points for the Coordinator

One thorny issue here is: how many contribution points does the coordinator get? There is no doubt that some points are due: coordinating a software project is hard work. But much of the coordination job can only be done by one person (which prevents the "bounty" system from working) and its the coordinator's job to assign points (but he can't bargain with himself).

Possible solutions include:

• A fixed proportion of all allocated points go to the coordinator
• The other contributors regularly vote on point allocations to the coordinator

Any such system will have to be tied in with the other issues involved in making the coordinator accountable to the other developers. This will be the subject of another page at some time in the future.

Paul Johnson - 1999