Why are software contractors paid so well

Contract work must be handled carefully in free software projects. Ideally, you want the contractor's work to be accepted by the community and included in the published version. In theory, it wouldn't make any difference who the contractor is as long as they do a good job and follow the project guidelines. Theory and practice can sometimes also go together: A complete stranger who shows up with a good patch, becomes generally manage to get this into the software. The difficult thing is that, as a complete stranger, it takes a lot of effort to produce a good patch for a non-trivial extension or function; you have to discuss it with the rest of the participant first. The duration of this discussion cannot be foreseen exactly. If the contractor is paid by working hours, you may be paying more than you expected; if he is paid a flat rate he may work longer than he can afford.

There are two ways around the problem. The preferred way is to make an educated guess about the length of the discussion, based on previous experience, with a buffer for errors, and base the contract on that. It also helps to split the problem into as many independent parts as possible so that you can assess the individual parts more easily. The other way is to limit the job to the actual patch, regardless of its inclusion in the project. This makes it much easier to write the contract, but it has the disadvantage that you then have the chunk of maintaining the patch as long as you rely on the software, or at least until you manage to get an equivalent function in the main branch. Of course, even with the preferred route, the contract itself cannot require that the inclusion of the patch in the code be accepted because that would mean the sale of something that is not for sale. (What happens if the rest of the project decide not to support the feature)? However, the contract may involve some reasonable and credible effort to get the change accepted by the community and then put into the repository. For example, if the project has established standards on code changes, the contract can refer to them and specify that the work must follow them. In practice, this usually works out positively for all parties.

The best tactic for successful contract work is to hire one of the project's developers - preferably an established stakeholder - as the contractor. That may sound like bought influence, and well, it is. But it's not as corrupt as it sounds. The influence that a developer has within a project depends primarily on the quality of his work and how he interacts with other developers. The fact that he has a contract to get certain things done doesn't raise his status in any way, nor does it lower him, although people may question him a little more cautiously. Most developers would not risk their long-term position in a project to support a largely unpopular function. In fact, part of what you get when you hire such a developer should be advice on what changes are likely to be adopted by the community. You also achieve a certain shift in the priorities in the project. Because prioritization often results from the question of who has time to work on which part, since you are paying someone's time, their work moves a little up the list of priorities. This fact is well known among seasoned open source developers and at least some will pay attention to the work of a contractor simply because one suspects that it will be finished, so they want to help get it done right. You may not be writing any code, but you will discuss drafts and criticize the code, which can all be very useful. For all these reasons, the contractor should most likely be drawn from among those already involved in the project.

This raises two questions: Should contracts ever be private? And if they aren't, should you worry about causing tension in the community by contracting some of the developers instead of others?

Contracts should be open where possible. Otherwise, the agent's behavior may seem strange to others in the community - he may suddenly give certain functions an inexplicably high priority that he previously didn't care about. When people approach him about it, how is he supposed to respond convincingly when he can't talk about being hired to write them?

At the same time, neither you nor the contractor should pretend that others should treat their agreement as special. All too many times I've seen contractors come on the mailing list with the mindset that their messages should be taken more seriously simply because they get paid. This setting shows the other participants that the contractor considers the contract itself to be essential - in contrast to that from the contract resulting Code. From the other developer's point of view, the only important thing is the code. Technical problems should always be the focus, not the details of who is being paid by whom. One of the developers in the Subversion community is particularly elegant with commissioned work. While he is discussing his changes to the code on IRC, he makes comments on the side (often in a private message, i.e. privmsg on IRC, to other developers) that he is being paid to work on that particular bug or feature. But he consistently gives the impression that he wants to work on this change and that he is glad that the money makes it possible for him. Regardless of whether he says who he works for or not, he never really makes the contract an issue. His comments on it are merely an ornament to an otherwise technical discussion about solving a problem.

The following example shows another reason for being open about contracts: There may be several organizations contributing contracts to an open source project, and if each is aware of each other's work, they may be able to pool their resources. In the above case, the largest financier (CollabNet) is in no way involved in these individual contracts. But knowing that someone else is promoting certain bug fixes allows CollabNet to focus on other bugs, thereby increasing the overall efficiency of the project.

Do other developers resent the commissioned members for getting paid to work on the project? Generally not, especially when those who are paid are recognized, respected members of the community anyway. Nobody expects commissioned work to be evenly divided among those involved. People understand the importance of long-term relationships: the uncertainties in contract work are such that once you've found a reliable business partner, you'll be reluctant to switch to someone else, just for the sake of fairness. You can think of it this way: When you vote for someone for the first time, there will definitely be no complaints, because after all you had to anyone choose - after all, you can't hire everyone. If you hire the same person a second time later, it makes only sense: you already know him, the last job was successful, why should you take an unnecessary risk? It is therefore natural to have one or two people in the community to turn to instead of dividing the work evenly.

Criticism and acceptance of changes

The community is still important for the success of commissioned work. Your involvement in the design and assessment of the change must not be incidental. You need to see it as part of the job and include it entirely in the order. Don't see community criticism as an obstacle to overcome - rather as a free platform for drafts, questions and answers. It is an advantage that you should decisively take advantage of rather than simply accepting it.

Case study: The CVS protocol for password authentication

In 1995 I was involved in a partnership for technical support and enhancements to CVS (the Concurrent Versions System; see http://www.cvshome.org/). My partner Jim and I were informally responsible for maintaining CVS at the time. But we had never thought carefully about how to deal with the existing, largely volunteer, community of developers at CVS. Our expectation was simply to get patches that we would apply, and that was largely how it went.

At that time CVS could only be operated in the network via a remote access program such as. The same password was required for CVS as for remote access, which was an obvious security risk and deterred many organizations. A major investment bank hired us to implement a new authentication mechanism so that they could use their networked CVS securely with their branch offices.

Jim and I accepted the contract and began working on a blueprint for the new authentication system. Our design was relatively simple (the United States then had restrictions on exporting cryptographic code, so the customer understood that we could not implement Strong Authentication). However, since we had no experience with such protocols, we made some serious mistakes that an expert would have noticed immediately. These slip-ups would have been recognized with ease if we had taken the time to write a proposal and presented the other developer for review. It never occurred to us to consider the developers on the mailing list as a resource and went on alone. We knew that whatever our work looked like, it was likely to be accepted, and - since we didn't know what we didn't know - we didn't bother to make our work visible to everyone, that is, sending off patches often, small, light digestible changes to a particular branch, etc. The resulting authentication protocol was not very good, and of course, once it was in place, it was very difficult to improve due to compatibility concerns.

In essence, the problem wasn't our lack of experience; we could have learned what was necessary with ease. The problem was with our attitude towards the developer community. We viewed accepting the changes as a hurdle to overcome, not a process to improve the quality of the changes. We were confident that any work would be accepted by us (which it did), so we made little effort to get outside participation.

It is obvious that you are looking for the right technical skills and experience when looking for a contractor. However, it is also important to choose someone who has a proven record of working constructively with the other developers in the community. You get more than just one person as a result; You get an agent who will be able to draw on a network of expertise to ensure robust and maintainable work.