O trabalho contratado necessita de ser cuidadosamente tratado em projectos de software livre. Idealmente deseja que o trabalho executado pelo contratado seja aceite pela comunidade e englobado na distribuição pública. Teoricamente, não importa quem seja o contratado, desde que o seu trabalho seja bom e esteja em conformidade com as directrizes do projecto. A teoria e a prática podem por vezes corresponder: um completo estranho que aparece com um bom patch irá geralmente ser capaz de entrar no software. O problema é que é muito difícil produzir um bom patch para uma melhoria não trevial ou uma nova capacidade sendo um completo estranho; em primeiro lugar é necessário discutir-la com o resto do projecto. A duração da discussão não pode ser prevista com precisão. Se o contratado trabalhar à hora, poderá acabar por lhe pagar mais do que o esperado; se lhe pagar uma soma pré-determinada ele poderá ficar prejudicado.
Há duas maneiras de contornar isto. A maneira preferida é efectuar uma estimativa sobre a duração do processo de discussão, baseada em experiência passada, dar alguma folga para erro de estimativa e finalmente basear o contrato no resultado. Ajuda dividir o problema em tantas componentes independentes mais pequenas quanto possível, de modo a aumentar a previsibilidade de cada porção. A outra maneira é contratar com base na entrega de um patch, e tratar da aceitação do path pelo projecto público como um assunto separado. Assim torna-se mais fácil escrever o contrato, mas ficará com o peso de manter um patch privado enquanto depender do software ou pelo menos até que consiga que o patch ou funcionalidade equivalente seja encorporada no corpo principal. Claro que mesmo da forma preferida o contrato propriamente dito não pode exigir que o patch tenha que ser aceite no código, porque isso seria vender algo que não está à venda. (O que sucederia se o projecto inesperadamente decidisse não suportar a capacidade?) Contudo o contrato pode exigir esforço bona fide de modo a que a alteração seja aceite pela comunidade, e que seja committed no repositório se a comunidade concordar com isso. Por exemplo, se o projecto tiver normas escritas para alterações do código, o contrato pode referir-se a essas normas e especificar que o trabalho deve ser feito em conformidade com as mesmas. Na prática, normalmente isto funciona de acordo com o que as pessoas esperam.
The best tactic for successful contracting is to hire one of the project's developers—preferably a committer—as the contractor. This may seem like a form of purchasing influence, and, well, it is. But it's not as corrupt as it might seem. A developer's influence in the project is due mainly to the quality of his code and to his interactions with other developers. The fact that he has a contract to get certain things done doesn't raise his status in any way, and doesn't lower it either, though it may make people scrutinize him more carefully. Most developers would not risk their long-term position in the project by backing an inappropriate or widely disliked new feature. In fact, part of what you get, or should get, when you hire such a contractor is advice about what sorts of changes are likely to be accepted by the community. You also get a slight shift in the project's priorities. Because prioritization is just a matter of who has time to work on what, when you pay for someone's time, you cause their work to move up in the priority queue a bit. This is a well-understood fact of life among experienced open source developers, and at least some of them will devote attention to the contractor's work simply because it looks like it's going to get done, so they want to help it get done right. Perhaps they won't write any of the code, but they'll still discuss the design and review the code, both of which can be very useful. For all these reasons, the contractor is best drawn from the ranks of those already involved with the project.
This immediately raises two questions: Should contracts ever be private? And when they're not, should you worry about creating tensions in the community by the fact that you've contracted with some developers and not others?
It's best to be open about contracts, when you can. Otherwise, the contractor's behavior may seem strange to others in the community—perhaps he's suddenly giving inexplicably high priority to features he's never shown interest in in the past. When people ask him why he wants them now, how can he answer convincingly if he can't talk about the fact that he's been contracted to write them?
At the same time, neither you nor the contractor should act as though others should treat your arrangement as a big deal. Too often I've seen contractors waltz onto a development list with the attitude that their posts should be taken more seriously simply because they're being paid. That kind of attitude signals to the rest of the project that the contractor regards the fact of the contract—as opposed to the code resulting from the contract—to be the important thing. But from the other developers' point of view, only the code matters. At all times, the focus of attention should be kept on technical issues, not on the details of who is paying whom. For example, one of the developers in the Subversion community handles contracting in a particularly graceful way. While discussing his code changes in IRC, he'll mention as an aside (often in a private remark, an IRC privmsg, to one of the other committers) that he's being paid for his work on this particular bug or feature. But he also consistently gives the impression that he'd want to be working on that change anyway, and that he's happy the money is making it possible for him to do that. He may or may not reveal his customer's identity, but in any case he doesn't dwell on the contract. His remarks about it are just an ornament to an otherwise technical discussion about how to get something done.
That example shows another reason why it's good to be open about contracts. There may be multiple organizations sponsoring contracts on a given open source project, and if each knows what the others are trying to do, they may be able to pool their resources. In the above case, the project's largest funder (CollabNet) is not involved in any way with these piecework contracts, but knowing that someone else is sponsoring certain bug fixes allows CollabNet to redirect its resources to other bugs, resulting in greater efficiency for the project as a whole.
Will other developers resent that some are paid for working on the project? In general, no, particularly when those who are paid are established, well-respected members of the community anyway. No one expects contract work to be distributed equally among all the committers. People understand the importance of long-term relationships: the uncertainties involved in contracting are such that once you find someone you can work reliably with, you would be reluctant to switch to a different person just for the sake of evenhandedness. Think of it this way: the first time you hire, there will be no complaints, because clearly you had to pick someone—it's not your fault you can't hire everyone. Later, when you hire the same person a second time, that's just common sense: you already know him, the last time was successful, so why take unnecessary risks? Thus, it's perfectly natural to have one or two go-to people in the community, instead of spreading the work around evenly.
The community is still important to the success of contract work. Their involvement in the design and review process for sizeable changes cannot be an afterthought. It must be considered part of the work, and fully embraced by the contractor. Don't think of community scrutiny as an obstacle to be overcome—think of it as a free design board and QA department. It is a benefit to be aggressively pursued, not merely endured.
In 1995, I was one half of a partnership that provided support and enhancements for CVS (the Concurrent Versions System; see http://www.cvshome.org/). My partner Jim and I were, informally, the maintainers of CVS by that point. But we'd never thought carefully about how we ought to relate to the existing, mostly volunteer CVS development community. We just assumed that they'd send in patches, and we'd apply them, and that was pretty much how it worked.
Back then, networked CVS could be done only over a remote login
program such as rsh. Using the same password for
CVS access as for login access was an obvious security risk, and many
organizations were put off by it. A major investment bank hired us to
add a new authentication mechanism, so they could safely use networked
CVS with their remote offices.
Jim and I took the contract and sat down to design the new authentication system. What we came up with was pretty simple (the United States had export controls on cryptographic code at the time, so the customer understood that we couldn't implement strong authentication), but as we were not experienced in designing such protocols, we still made a few gaffes that would have been obvious to an expert. These mistakes would easily have been caught had we taken the time to write up a proposal and run it by the other developers for review. But we never did so, because it didn't occur to us to think of the development list as a resource to be used. We knew that people were probably going to accept whatever we committed, and—because we didn't know what we didn't know—we didn't bother to do the work in a visible way, e.g., posting patches frequently, making small, easily digestible commits to a special branch, etc. The resulting authentication protocol was not very good, and of course, once it became established, it was difficult to improve, because of compatibility concerns.
The root of the problem was not lack of experience; we could easily have learned what we needed to know. The problem was our attitude toward the volunteer development community. We regarded acceptance of the changes as a hurdle to leap, rather than as a process by which the quality of the changes could be improved. Since we were confident that almost anything we did would be accepted (as it was), we made little effort to get others involved.
Obviously, when you're choosing a contractor, you want someone with the right technical skills and experience for the job. But it's also important to choose someone with a track record of constructive interaction with the other developers in the community. That way you're getting more than just a single person; you're getting an agent who will be able to draw on a network of expertise to make sure the work is done in a robust and maintainable way.