POSS Chap 5 Part 6
Un article de Framalang Wiki.
[modifier] Contracting / Signer des contrats
Contracted work needs to be handled carefully in free software projects. Ideally, you want a contractor's work to be accepted by the community and folded into the public distribution. In theory, it wouldn't matter who the contractor is, as long as his work is good and meets the project's guidelines. Theory and practice can sometimes match, too: a complete stranger who shows up with a good patch will generally be able to get it into the software. The trouble is, it's very hard to produce a good patch for a non-trivial enhancement or new feature while truly being a complete stranger; one must first discuss it with the rest of the project. The duration of that discussion cannot be precisely predicted. If the contractor is paid by the hour, you may end up paying more than you expected; if he is paid a flat sum, he may end up doing more work than he can afford.
Le travail sous contrat doit être géré avec précaution dans les projets de logiciel libre. Idéalement, vous voulez que le travail de la personne sous contrat soit accepté par la communauté et ajouté à la distribution publique. En théorie, tant que son travail est bon et satisfait aux lignes directrices du projet l'identité de la personne sous contrat ne devrait pas avoir d'importance. La théorie et la pratique peuvent se rejoindre parfois : quelqu'un de complètement étranger au projet qui propose un bon correctif le verra en général ajouté au logiciel. Le problème est qu'il est très difficile de produire un bon correctif pour une amélioration non-triviale ou une nouvelle fonctionnalité pour une personne est effectivement complètement étrangère au projet, elle doit d'abord en discuter avec le reste du projet. La durée de cette discussion ne peut pas être connue précisément à l'avance. Si la personne sous contrat est payée à l'heure, vous pouvez vous retrouver à payer plus que prévu, s'il reçoit une somme prédéterminée il pourra se retrouver à faire plus d'heures qu'il ne le peut.
There are two ways around this. The preferred way is to make an educated guess about the length of the discussion process, based on past experience, add in some padding for error, and base the contract on that. It also helps to divide the problem into as many small, independent chunks as possible, to increase the predictability of each chunk. The other way is to contract solely for delivery of a patch, and treat the patch's acceptance into the public project as a separate matter. Then it becomes much easier to write the contract, but you're stuck with the burden of maintaining a private patch for as long as you depend on the software, or at least for as long as it takes you to get that patch or equivalent functionality into the mainline. Of course, even with the preferred way, the contract itself cannot require that the patch be accepted into the code, because that would involve selling something that's not for sale. (What if the rest of the project unexpectedly decides not to support the feature?) However, the contract can require a bona fide effort to get the change accepted by the community, and that it be committed to the repository if the community agrees with it. For example, if the project has written standards regarding code changes, the contract can reference those standards and specify that the work must meet them. In practice, this usually works out the way everyone hopes.
Il y a deux manières d'éviter ceci. La solution privilégiée est de prévoir intelligemment la durée du processus de discussion, en se basant sur des expériences passées et en prévoyant une marge et baser le contrat dessus. Cela aide également à décomposer le problème en autant de parties indépendantes que possible pour faciliter la prévision de chaque partie. L'autre possibilité est de signer le contrat uniquement pour la livraison d'un correctif et de traiter séparément l'acceptation du correctif par le projet. Alors il devient beaucoup plus simple de rédiger le contrat, mais vous vous retrouverez avec la charge de maintenir le correctif pour aussi longtemps que vous aurez besoin du logiciel, ou au moins le temps que vous arriviez à faire entrer le correctif ou une fonctionnalité équivalente dans le développement. Évidemment, même avec ces solutions privilégiée, le contrat ne peut pas imposer l'intégration du correctif au code, cela reviendrait à vendre quelque chose qui n'est pas à vendre. (Que se passerait-il si le reste du projet décidait sans prévenir de ne pas supporter cette fonction ?) Cependant, le contrat peut exiger un effort de bonne foi pour que la modification soit acceptée par la communauté et qu'elle soit validée dans le dépôt si la communauté le trouve bon. Par exemple, si le projet possède des standards concernant les modifications du code, le contrat peut faire référence à ces standards et préciser que le travail doit y être conforme. En pratique, cela fonctionne généralement comme prévu.
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.
La meilleure tactique pour que la signature d'un contrat se révèle payante est d'engager l'un des développeur du projet, préférentiellement un committer. L'influence qu'à un développeur au sein d'un projet est principalement due à la qualité du code qu'il produit et à ses relations avec les autres développeurs. Le fait qu'il soit sous contrat pour mener à bien certaines tâches ne change en rien son statut, bien que pour cette raison les gens seront plus attentifs à ce qu'il fait. La plupart des développeurs ne risqueraient pas leur statut à long terme dans un projet en supportant une nouvelle fonctionnalité inappropriée ou largement désapprouvée. En fait, une partie de ce vous obtiendrez, ou devriez obtenir, quand vous faites signer un développeur sont des conseils à propos des modifications qui auraient une chance d'être acceptées par la communauté. Vous obtiendrez également un léger glissement des priorités du projet. Puisque les priorités sont établies en fonction de qui à le temps de faire quoi, quand vous achetez le temps de quelqu'un le résultat est que le travail de cette personne remonte un peu dans la liste des priorités. C'est une vérité bien comprise au sein des développeurs Open Source expérimentés et au moins certains d'entre eux feront attention au travail de la personne sous contrat simplement parce qu'il a des chances d'être terminé, ils veulent donc aider à ce qu'il soit bien fait. Peut-être n'écriront-ils aucune ligne du code mais ils discuteront quand même de sa conception et en feront des vérifications, les deux pouvant être très utiles. Pour toutes ces raisons il vaut mieux faire signer une personne parmi celles qui sont déjà impliquées dans le projet.
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?
Deux questions surviennent alors : les contrats devraient-ils toujours être privés ? Et s'ils ne le sont pas, devriez vous vous inquiéter de la création de tensions dans la communauté dues au fait que vous avait fait signer certains développeurs et pas d'autres ?
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?
Il vaut mieux être ouvert à propos des contrats quand vous le pouvez. Autrement l'attitude de la personne sous contrat pourra sembler étrange aux autres personnes de la communauté, peut-être d'un coup voudra-t-il donner une priorité importante à des fonctions auxquelles il n'avait jamais prêté attention par le passé. Quand les gens lui demanderont pourquoi ce revirement, comment peut-il répondre de façon convaincante s'il ne peut pas évoquer le fait qu'il a signé un contrat pour les écrire ?
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.
De la même manière, ni vous, ni la personne sous contrat ne devraient attendre que les autres jugent important votre arrangement. J'ai souvent vu des personnes sous contrat débarquer sur une liste de développement en s'attendant à ce que leur contribution soit prise plus au sérieux pour la simple raison qu'ils étaient payés. Ce genre d'attitude montre au reste du projet que pour la personne sous contrat, le contrat, en opposition au code résultant du contrat, est la chose qui compte. Mais pour les autres développeurs c'est uniquement le code qui compte. Quoiqu'il arrive, l'attention devrait être centrée sur les problèmes techniques, pas sur des histoires de qui paie qui. Par exemple, l'un des développeurs de Subversion traite les contrats d'une manière particulièrement élégante. Pendant qu'il parle de ses modifications du code sur IRC, il dira à part (souvent sous la forme d'une remarque privée, un message privé sur IRC à l'un des autres committers) qu'il est payé pour son travail sur cette fonction ou sur ce correctif en particulier. Mais en même temps il donne systématiquement l'impression qu'il veut travailler sur ce changement de toute façon et qu'il est content que l'argent lui donne la possibilité de le faire. Il révélera, ou pas, l'identité de son client, mais dans tous les cas il ne se repose pas sur le contrat. Les remarques qu'il formule à ce propos ne sont que des apports à un discours qui pour le reste est technique et qui porte sur la manière de mener les choses à bien.
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.
Cet exemple illustre une autre raison de ne pas cacher l'existence des contrats. Il pourrait y avoir plusieurs organisations finançant des contrats sur un même projet Open Source et si chacun sait ce que les autres tentent de faire ils pourraient partager leurs ressources. Dans le cas ci-dessus, le donateur principal du projet (CollabNet) n'est impliqué d'aucune manière dans ces contrats à la pièce, mais savoir que quelqu'un d'autre finance certaines corrections de bogues permet à CollabNet de rediriger ses ressources sur d'autres bogues, ce qui au final permet au projet entier d'être plus efficace.
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.
Est-ce que les autres développeurs seront dérangés par le fait que certains d'entre eux sont payés pour travailler sur le projet ? En général, non, en particulier quand ceux qui sont payés sont des membres bien implantés dans le projet et respectés par la communauté. Personne ne s'attend à ce que les contrats soient répartis équitablement entre tous les committers. Les gens comprennent l'importance des relations à long terme : les incertitudes liées à la signature de contrats sont telles qu'une fois que vous avez trouvé quelqu'un avec qui vous pouvez travailler en toute confiance vous n'êtes que peu enclin à changer de personne uniquement par soucis d'équité. Voyez les choses ainsi : la première fois que vous engagez quelqu'un, il n'y aura pas de plaintes puisqu'à l'évidence vous deviez choisir quelqu'un, ce n'est pas de votre faute si vous ne pouvez pas engager tout le monde. Par la suite, quand vous engagez la même personne pour la deuxième fois, c'est simplement faire preuve de bon sens : vous la connaissez déjà, votre association a fonctionné la fois précédente alors pourquoi prendre des risques inutiles ? Il est donc parfaitement normal qu'il y ait une ou deux personnes sur lesquels vous vous reposez dans la communauté plutôt que de répartir le travail équitablement.
[modifier] Review and Acceptance of Changes / Révision et acceptation des changements
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.
Malgré tout, la communauté reste importante dans le succès d'un contrat. Leur implication dans la conception et le processus de vérification pour des changements importants ne peut pas être omise. Elle doit être considérée comme une partie du travail et être entièrement prise en compte par la personne sous contrat. Ne voyez pas l'examen par le reste de la communauté comme un obstacle à surmonter, voyez le comme un espace de question/réponse et de conception libre. C'est un avantage que vous devez chercher activement, pas quelque chose à simplement endurer.
[modifier] Case study: the CVS password-authentication protocol / Cas d'étude : le protocole d'authentification de mot de passe CVS
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.
En 1995, j'étais la moitié du binôme qui fournissait le support et les améliorations pour CVS (Concurrent Versions System; voir http://www.cvshome.org/). Mon partenaire Jim et moi même étions, de manière officieuse, les personnes chargées de maintenir CVS à ce moment. Mais nous n'avons jamais vraiment pris la peine de penser au fonctionnement de nos relations avec la communauté de développement existante de CVS, des volontaires pour la plupart. Pour nous, ils envoyaient les correctifs et nous les appliquions, c'était à peu près comme ça que ça marchait.
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.
A cette époque, le travail en réseau sur CVS ne pouvait se faire que grâce à un programme de connexion distant tel que rsh. Le fait d'utiliser le même mot de passe pour l'accès à CVS et pour ce programme était un risque de sécurité évident et cela a découragé de nombreuses entreprises. Une grande banque d'investissement nous a engagé pour créer un nouveau système d'authentification afin qu'ils puissent utiliser CVS en ligne de manière sure depuis leur bureau distant.
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.
Jim et moi avons accepté le contrat et nous avons pris le temps d'établir un nouveau système d'authentification. Notre solution était plutôt simple (les États-Unis exerçaient un contrôle sur l'exportation de code cryptographique à cette époque, donc nos clients comprenaient que nous ne pouvions introduire une authentification forte), mais comme nous n'avions pas d'expérience dans ce domaine nous avons commis quelques gaffes qui auraient été évidentes pour un expert. Nous aurions facilement détecté ces erreurs si nous avions pris le temps d'écrire un premier jet et de le soumettre aux autres développeurs pour inspection. Mais nous ne l'avons jamais fait, parce qu'il ne nous est jamais venu à l'idée que la liste de développement renfermait des ressources que nous pouvions utiliser. Nous savions que les gens accepteraient sûrement tout ce que nous pourrions proposer et, parce que nous ne savions pas ce que nous ne savions pas, nous n'avons pas pris la peine de faire le travail de manière visible, c'est-à-dire, d'envoyer fréquemment des correctifs, en faisant des petites modifications, facilement digestibles pour une branche spécifique, etc. Le protocole d'authentification résultant n'était pas très bon, et bien sûr, une fois mis en place il était difficile à améliorer pour des raisons de compatibilité.
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.
La base du problème n'était pas le manque d'expérience, nous aurions facilement pu apprendre ce que nous devions savoir. Le problème était plutôt notre attitude vis-à-vis de la communauté de développeurs bénévoles. L'acceptation des modifications était pour nous un haie à sauter plutôt qu'un processus par lequel la qualité des modifications aurait pu être améliorée. Puisque nous savions que tout ce que nous faisions serait accepté (comme c'était effectivement le cas) nous n'avons pas fait l'effort d'impliquer les autres.
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.
De toute évidence, lorsque vous choisissez quelqu'un pour effectuer un contrat, vous voulez quelqu'un ayant les bonnes aptitudes techniques et une bonne expérience pour cette tâche. Mais il est aussi important de choisir quelqu'un qui tisse des relations constructives avec les autres développeurs dans la communauté. De cette manière vous engagez plus qu'une seule personne, vous engagez un agent qui sera capable de se reposer sur un réseau de compétences pour s'assurer que le travail est fait de manière solide et facile à maintenir.
