Dictators in free and open source software
De Framalang Wiki.
Les dictateurs sont partout, même dans l'open source. Article original sur Free Software Magazine.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Olivier | OLV | Traduction | Terminé |
| Penguin | Relecture | Terminé | |
| aKa | Validation | Terminé |
Article en ligne à l'adresse : http://www.framablog.org/index.php/post/2008/12/01/logiciels-libres-et-dictateur-bienveillant
Titre
Dictators in free and open source software
Les dictateurs dans les logiciels libres et open source
Introduction / Introduction
Some people seem to challenge the idea that most (if not all) free software projects need a benevolent dictator—that is, somebody who has the last say on every decision. They are quick to point out Linus Torvalds’ past “mistakes” (see the speech marks): using BitKeeper to manage the kernel, not allowing “pluggable” schedulers in Linux, etc. As a software developer, I feel that a dictator is absolutely necessary in every free software project. Here is why.
Certaines personnes remettent en cause l'idée que la plupart (si ce ne sont pas tous) des projets de logiciels libres ne peuvent pas se passer d'un dictateur bienveillant, c'est à dire une personne qui a le dernier mot sur toutes les décisions prises. Ils pointent facilement les "erreurs" passées de Linus Torvalds (notez les guillemets) : l'utilisation de BitKeeper pour gérer le noyau, ne pas autoriser les programmateurs sous forme de greffon dans Linux, etc. En tant que développeur logiciel, je pense qu'un dictateur est absolument nécessaire dans un projet de logiciel libre. Voici mes raisons.
Respect earned by the BDFL / Respect gagné par le DBAV
The first reason is probably the most important one: respect. The benevolent dictator for life (BDFL from now on) needs to make decisions — in fact, a lot of decisions — and at the same time maintain other people’s respect. Decisions are not always popular, and are not always right (especially in other people’s eyes). However, the BDFL needs to have the personal and technical charisma in order to keep the team’s respect. Nobody would ever dream of forking Linux, because very few Linux developers would abandon Linus and follow the forker. This is true for most projects, and that’s why forking is so rare. It must be said, however, that sometimes the BDFL does manages to alienate the development team so much that somebody ends up forking and bringing over most of the original developers. At that point, normally a new project is created (with a new name and inheriting the codebase) and the old one disappears after a while. This is a good thing: the DBFL is there because the crowd wants him or her to be there. It’s a dictatorship, but it’s an odd one: anybody can walk away at any point, create a new state, or join another one.
La première raison est aussi certainement la plus importante : le respect. Le dictateur bienveillant à vie (on le nommera DBAV à partir de maintenant) doit prendre des décisions, et même beaucoup de décisions, et en même temps il doit conserver le respect de ses pairs. Les décisions ne sont pas toujours populaires, et elles ne sont pas non plus toujours justes (particulièrement aux yeux des autres). Cependant, le DBAV doit faire preuve de charisme, aussi bien sur le plan technique que relationnel, pour conserver le respect du reste de l'équipe. Personne ne songerait jamais à initier une fourche de Linux, car peu de développeurs abandonneraient Linus au profit de la personne à l'origine de la fourche. C'est vrai pour la plupart des projets et c'est pourquoi les fourches sont rares. Il faut reconnaître cependant qu'il arrive que le DBAV réussisse à se mettre toute l'équipe de développement à dos, et que quelqu'un finisse par créer une fourche en entraînant la majeure partie des développeurs avec lui. Un nouveau projet avec un nouveau nom se crée en s'appuyant sur le code source existant et l'ancien projet disparaît après quelques temps. C'est une bonne chose : le DBAV est en place parce que le peuple le souhaite. C'est une dictature, mais une dictature étrange puisqu'à tout moment les citoyens peuvent s'en aller créer un nouvel état ou en rejoindre un autre.
Knowledge / Connaissance
The BDFL knows the project inside-out. He or she is the person who will know if a decision will break the project’s foundations — and who knows how to solve a problem keeping the structure as solid as it needs to be. I see this with Drigg (a popular project I maintain) pretty much every week: I realise that my deep knowledge of the project protects it from bad patches and bad feature requests. A BDFL is crucial — and he or she needs to be the person in charge of making decisions. In commercial software, a dummy-like manager (who doesn’t know how to code) will sometimes manage to impose some features or modifications that will necessarily break the software’s structure. This happened to me as well — and I think it happened to most people who worked on proprietary, client-based software.
Le DBAV connaît le projet de A à Z. Il ou elle est à même de savoir si une décision détruira les fondations du projet, et saura également résoudre un problème en conservant la solidité de la structure. Drigg (un projet populaire que je maintiens) m'en apporte la preuve presque chaque semaine : je me rends compte que ma très bonne connaissance du projet le protège des mauvais correctifs et des mauvaises demandes de fonctionnalités. Un DBAV est crucial et il ou elle doit être la personne qui prend les décisions. Dans un logiciel commercial, un manager moyen (qui ne sait pas coder) arrivera parfois à imposer une fonctionnalité ou une modification qui détruira inévitablement la structure du logiciel. Cela m'est aussi arrivé et je pense que c'est arrivé à presque toutes les personnes travaillant sur des logiciels clients propriétaires.
Speed / Rapidité
Free software development is often really fast. Sometimes design and technical decisions need to be made very quickly. While the BDFL can ask for opinions, he or she will be in charge of the final decision. The saying “A Camel is a horse designed by committee” is probably a little too harsh —it obviously depends on the committee — but it’s generally (and sadly) true. Decisions need to be made, and looking at some project’s mailing lists, you really wish people stopped discussing things, and somebody said “enough, we’ll do it this way”.
Tout se passe souvent très vite dans le développement de logiciels libres. Parfois les décisions sur la conception et la technique doivent être prises très vite. Même si le DBAV peut demander leur avis aux autres membres, c'est à lui ou à elle que revient la décision finale. Il existe une expression anglaise qui dit "A Camel is a horse designed by committee" ["Un chameau est un cheval créé par un comité" pour dire que les décisions prises en comité ne sont jamais optimales], je la trouve légèrement exagérée, tout dépend évidemment du comité, mais c'est en général vrai et c'est bien dommage. Des décisions doivent être prises, et parfois quand on suit la liste de discussion d'un projet, on souhaiterait vraiment que quelqu'un mette fin aux argumentations et dise "ça suffit, on va faire les choses comme ça".
Workloads / Charge de travail
Making feature requests is a fundamental right. (Please note that demanding features isn’t.) Team members can talk about those feature requests and discuss how to implement them. However, code is better. If a user makes a request, and one of the other coders thinks it’s a priority, much can be discussed forever, but normally “something must be coded if you want something to happen”. A team member will gain respect and credibility if he or she comes up with a patch, and the patch doesn’t break the project’s structure. This means that contributing team members will take on things they care the most about, and will need to code those things in such a way that the BDFL won’t reject them. This helps both the code and people’s motivations. And other team members’ code needs to be good. Which brings us to the next point…
Soumettre des idées pour de nouvelles fonctionnalités est un droit fondamental (par contre les exiger ne l'est pas). Les membres de l'équipe peuvent débattre de ces demandes de fonctionnalités et de leur implémentation. Cependant, le code est meilleur. Si un utilisateur propose quelque chose qui trouve écho chez une développeur, les discussions peuvent tirer en longueur, mais à un moment "quelque chose doit être codé si vous voulez qu'il se passe quelque chose". En proposant un correctif un membre de l'équipe gagnera du respect et de la crédibilité, à condition que le correctif ne détruise pas la structure du projet évidemment. Cela signifie donc que les membres qui veulent contribuer prendront en charge ce qui leur tiens vraiment à cœur et ils devront coder ces éléments de manière à ce que le DBAV ne les rejettent pas. Cela est bénéfique à la fois pour le code et pour la motivation des gens. Le code créé par les autres membres de l'équipe doit être bon. Ce qui nous amène au point suivant...
Sending good patches, and consistency / Envoyer de bons correctifs et un message fort
If a developer knows that his or her patches will be reviewed by somebody who knows the project intimately, and will look for problems, then his or her patches will be better. If instead of the BDFL there’s a committee who will decide on each patch by voting, bad patches will end up in the codebase — patches that will cripple the project’s structure, or will have some obscure, hard-to-debug side effects. This can also happen if the BDFL is behaving like a trusting and caring father rather than like a BDFL. And yes, I have accepted patches a little too quickly sometimes, and found myself in this very situation.
Si un développeur sait que son correctif sera inspecté par une personne ayant une connaissance poussée du projet, et que cette personne cherchera la petite bête, il mettra plus d'application dans l'élaboration de son correctif. Si ce n'est pas un DBAV mais un comité démocratique qui décide du sort des contributions, de mauvais correctifs seront intégrés au code, des correctifs qui mettront à mal la structure du projet ou qui auront des effets secondaires obscures et difficiles à corriger. Ceci peut aussi se produire si le DBAV se comporte comme un père de famille confiant et aimant plutôt que comme un DBAV. Oui, il m'est déjà arrivé d'accepter des correctifs trop rapidement, et je me suis retrouvé dans cette situation.
Keeping things non-political / Maintenir la politique à l'écart du projet
A committee will bring politics to the projects. This equation is often true: Politics + Technical project = Disaster. If a committee decides on patches etc., a bunch of members might end up teaming up to get things through for reasons that are not purely technical (see: returned favours, asked favours, and so on). It’s true that the BDFL might make political decisions, but they will always focus on the political decisions of one person — the BDFL himself or herself — who will know that any bad technical decision will cost the project a lot of development efforts.
Créer un comité c'est ouvrir la porte à la politique. L'équation suivante est souvent vraie : Politique + Projet technique = Catastrophe. Si un comité prend toutes les décisions, un groupe de membres du comité pourrait finir par s'allier afin de faire passer des décisions pour des raisons autres que techniques (comprendre ici : renvoyer l'ascenseur, demander une faveur, etc.). Le DBAV peut aussi prendre des décisions politiques, mais ce ne seront toujours que les décisions politiques d'une personne, le DBAV lui-même, qui saura qu'une mauvaise décision sur le plan technique sera très préjudiciable au développement du projet.
To conclude… / Pour finir...
I am not a big fan of committees. I believe that a merit-based oligarchy with a BDFL is much more functional, and gets things done much more quickly. I have managed a free software project for nearly a year, and have experienced — although in a much smaller scale — what many free software maintainers face every day. If you don’t agree with these ideas, you can try forking a project and managing it through a committee. But, you aree likely to end up with a dromedary rather than a horse.
Feel free to prove me wrong.Je ne suis pas spécialement fan des comités. Je pense qu'une méritocratie avec un DBAV fonctionne beaucoup mieux et réalise les choses beaucoup plus rapidement. Durant ma courte expérience de chef de projet de logiciel libre (presque un an), j'ai fait face, à une échelle plus modeste bien sûr, aux mêmes problèmes que rencontrent tous les jours beaucoup de développeurs de logiciels libres. Si vous n'êtes pas d'accord avec mes idées, vous pouvez créer une fourche à partir d'un projet et mettre sa gestion dans les mains d'un comité. Mais vous avez de bonne chance d'accoucher d'un chameau plutôt que d'un cheval.
Vous êtes libres de me prouver que j'ai tort.
