Dictators in free and open source software
Un article 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 | En cours |
| Relecture | |||
| Validation |
Sommaire |
[modifier] Titre
Dictators in free and open source software
Les dictateurs dans les logiciels libres et open source
[modifier] 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.
[modifier] 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 finalement quelqu'un créé une fourche en entraînant la majeure partie des développeurs avec lui. Un nouveau projet avec un nouveau nom se créé en s'appuyant sur le code source 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 joindre un autre.
[modifier] 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 projets et il ou elle saura 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 rend 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.
[modifier] 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 opinion 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 disent "ça suffit, on va faire les choses comme ça".
[modifier] 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 puisse pas les rejeter. Cela sert à la fois le code et 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...
[modifier] Sending good patches, and consistency
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.
[modifier] Keeping things non-political
{{{2}}}
[modifier] To conclude…
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.
