POSS Chap 8 Part 6
Un article de Framalang Wiki.
[modifier] Forks / Les fourches
In the section called “Forkability” in Chapter 4, Social and Political Infrastructure, we saw how the potential to fork has important effects on how projects are governed. But what happens when a fork actually occurs? How should you handle it, and what effects can you expect it to have? Conversely, when should you initiate a fork?
Dans la section « Fourchabilité » dans le Chapitre 4, Infrastructure sociale et politique, nous avons vu l'influence qu'à la possibilité de fourcher sur la gestion du projet. Mais que se passe-t-il quand une fourche se concrétise réellement ? Comment devriez vous gérer la situation et à quelles conséquences devriez vous vous attendre ? Et inversement, quand devriez vous concrétiser une fourche ?
The answers depend on what kind of fork it is. Some forks are due to amicable but irreconcilable disagreements about the direction of the project; perhaps more are due to both technical disagreements and interpersonal conflicts. Of course, it's not always possible to tell the difference between the two, as technical arguments may involve personal elements as well. What all forks have in common is that one group of developers (or sometimes even just one developer) has decided that the costs of working with some or all of the others now outweigh the benefits.
Les réponses dépendent du type de fourche à laquelle vous avez affaire. Certaines fourches sont dues à des différences de point de vue amicales mais irréconciliables sur la manière de mener le projet mais peut-être que plus nombreuses sont celles dues à la fois à des désaccords techniques et des conflits de relation. Bien sûr, il n'est pas toujours possible de discerner l'un de l'autre puisque les débats techniques peuvent contenir des sentiments personnels également. Ce que toutes les fourches ont en commun est qu'un groupe de développeurs (parfois même juste un seul développeur) a décidé que le travail avec certains ou avec tous les autres développeurs lui coûte plus qu'il n'en tire de bénéfices.
Once a project forks, there is no definitive answer to the question of which fork is the « true » or « original » project. People will colloquially talk of fork F coming out of project P, as though P is continuing unchanged down some natural path while F diverges into new territory, but this is, in effect, a declaration of how that particular observer feels about it. It is fundamentally a matter of perception: when a large enough percentage of observers agree, the assertion starts to become true. It is not the case that there is an objective truth from the outset, one that we are only imperfectly able to perceive at first. Rather, the perceptions are the objective truth, since ultimately a project—or a fork—is an entity that exists only in people's minds anyway.
Dès qu'un projet fourche il est difficile de dire quelle est la « vraie » fourche ou quel est le projet « original ». Les gens parleront de la fourche F issue du projet P, avec P poursuivant à l'identique le long d'un chemin naturel alors que F s'aventure sur un nouveau territoire, mais ceci, déjà, est teinté de subjectivité. C'est principalement un problème de perception : quand un nombre suffisamment important d'observateurs sont d'accord l'assertion devient vraie. Ici il n'y a pas de vérité objective dès le début, pas de vérité qui saute aux yeux. Ce sont plutôt les perceptions qui forment cette vérité objective puisque, au final, le projet ou la fourche est une entité qui n'existe que dans l'esprit des gens de toute façon.
If those initiating the fork feel that they are sprouting a new branch off the main project, the perception question is resolved immediately and easily. Everyone, both developers and users, will treat the fork as a new project, with a new name (perhaps based on the old name, but easily distinguishable from it), a separate Web site, and a separate philosophy or goal. Things get messier, however, when both sides feel they are the legitimate guardians of the original project and therefore have the right to continue using the original name. If there is some organization with trademark rights to the name, or legal control over the domain or Web pages, that usually resolves the issue by fiat: that organization will decide who is the project and who is the fork, because it holds all the cards in a public relations war. Naturally, things rarely get that far: since everyone already knows what the power dynamics are, they will avoid fighting a battle whose outcome is known in advance, and just jump straight to the end.
Si ceux à l'origine de la fourche pensent qu'ils font germer une nouvelle branche sur le projet principal, la question de la perception est résolue immédiatement et facilement. Tout le monde, à la fois les développeurs et les utilisateurs, verra la fourche comme un nouveau projet, avec un nouveau nom (peut-être basé sur l'ancien nom, mais facilement reconnaissable), un site Web distinct et une philosophie ou un but distinct. Cependant, les choses se compliquent quand les deux camps considèrent qu'ils sont les légataires de l'esprit original du projet et qu'ils ont donc le droit de le poursuivre sous son nom d'origine. Si un organisme possède les droits sur le nom ou le contrôle légal du domaine ou des pages Web la question est en général résolue légalement : cet organisme décidera de qui est le projet et qui est la fourche puisqu'il a toutes les cartes en main dans la guerre des relations publiques. Évidemment, les choses vont rarement aussi loin : puisque tout le monde est au fait de qui tient les rennes, ils éviteront de commencer une bataille dont l'issue est connue d'avance et iront droit au résultat.
Fortunately, in most cases there is little doubt as to which is the project and which is the fork, because a fork is, in essence, a vote of confidence. If more than half of the developers are in favor of whatever course the fork proposes to take, usually there is no need to fork—the project can simply go that way itself, unless it is run as a dictatorship with a particularly stubborn dictator. On the other hand, if fewer than half of the developers are in favor, the fork is a clearly minority rebellion, and both courtesy and common sense indicate that it should think of itself as the divergent branch rather than the main line.
Heureusement, dans la plupart des cas il y a peu de doute quant à qui est le projet et qui est la fourche puisque, par nature, une fourche est un vote de confiance. Si plus de la moitié des développeurs sont pour le chemin tracé par la fourche, en général, il n'y a pas besoin de fourche, le projet peut simplement emprunter ce chemin à moins qu'il ne soit dirigé comme une dictature dont le chef serait particulièrement borné. A l'opposé, si moins de la moitié des développeurs sont pour, la fourche est clairement la rébellion d'une minorité et la courtoisie et le bon sens veulent qu'ils se considèrent alors comme la branche divergente plutôt que la ligne principale.
[modifier] Handling a Fork / Gérer une fourche
If someone threatens a fork in your project, keep calm and remember your long-term goals. The mere existence of a fork isn't what hurts a project; rather, it's the loss of developers and users. Your real aim, therefore, is not to squelch the fork, but to minimize these harmful effects. You may be mad, you may feel that the fork was unjust and uncalled for, but expressing that publicly can only alienate undecided developers. Instead, don't force people to make exclusive choices, and be as cooperative as is practicable with the fork. To start with, don't remove someone's commit access in your project just because he decided to work on the fork. Work on the fork doesn't mean that person has suddenly lost his competence to work on the original project; committers before should remain committers afterward. Beyond that, you should express your desire to remain as compatible as possible with the fork, and say that you hope developers will port changes between the two whenever appropriate. If you have administrative access to the project's servers, publicly offer the forkers infrastructure help at startup time. For example, offer them a complete, deep-history copy of the version control repository, if there's no other way for them to get it, so that they don't have to start off without historical data (this may not be necessary depending on the version control system). Ask them if there's anything else they need, and provide it if you can. Bend over backward to show that you are not standing in the way, and that you want the fork to succeed or fail on its own merits and nothing else.
Si quelqu'un menace de lancer une fourche de votre projet, gardez votre calme et souvenez vous de vos buts à long terme. Le simple fait qu'une fourche existe n'est pas ce qui menace votre projet, la perte de développeurs et d'utilisateurs voilà le vrai risque. Votre réel objectif alors n'est pas de bâillonner la fourche mais d'en minimiser les effets néfastes. Vous pourrez être énervé, vous pourrez penser que la fourche n'est pas justifiée et n'a pas de légitimité, mais exprimer cela en public ne peut que vous aliéner les développeurs indécis. A la place vous ne devriez pas forcer les développeurs à faire un choix entre les deux projets et vous devez être aussi coopératifs que possible avec la fourche. En premier lieu, ne retirez pas à quelqu'un son accès de commit dans votre projet simplement parce qu'il a décidé de travailler sur la fourche. Le fait de travailler sur la fourche ne veut pas dire qu'il a soudainement perdu ses capacités à travailler sur le projet original, ceux qui étaient committers devraient le rester. Au delà de ça vous devriez exprimer votre envie de maintenir la compatibilité avec la fourche et dire que vous espérez que les développeurs feront des portages entre les deux chaque fois que ça sera approprié. Si vous avez un accès direct au serveur hébergeant le projet, offrez publiquement à la fourche une aide matérielle pour ses débuts. Par exemple, proposez leur un historique complet et détaillé du dépôt de gestion de version, s'ils n'ont pas d'autre moyen de l'obtenir, afin qu'ils n'aient pas à débuter sans historique (cela n'est pas forcément nécessaire, ça dépend du logiciel de gestion de version). Demandez leur s'il y a autre chose dont ils ont besoin et fournissez leur si vous le pouvez. Inclinez vous, avec réserve, pour montrer que vous ne serez pas un obstacle et que vous voulez voir la fourche réussir ou échouer grâce ou à cause de ses qualités intrinsèques et pas pour d'autres raisons.
The reason to do all this—and do it publicly—is not to actually help the fork, but to persuade developers that your side is a safe bet, by appearing as non-vindictive as possible. In war it sometimes makes sense (strategic sense, if not human sense) to force people to choose sides, but in free software it almost never does. In fact, after a fork some developers often openly work on both projects, and do their best to keep the two compatible. These developers help keep the lines of communication open after the fork. They allow your project to benefit from interesting new features in the fork (yes, the fork may have things you want), and also increase the chances of a merger down the road.
Si vous devez faire tout cela, et le faire publiquement, ce n'est pas pour aider la fourche en fait, mais pour montrer aux développeurs que rester de votre côté est le pari le plus sûr en vous montrant aussi peu vindicatif que possible. En temps de guerre il est parfois logique (stratégiquement parlant si ce n'est pas humainement) de forcer les gens à choisir leur camp, mais pour les logiciels libres ce n'est presque jamais le cas. En fait, quand une fourche apparaît, certains développeurs ne cachent pas le fait qu'ils travaillent sur les deux projets et font de leur mieux pour maintenir leur compatibilité. Ces développeurs aident à conserver les lignes de communications ouvertes après la séparation. Ils permettent à votre projet de bénéficier des nouvelles fonctionnalités intéressantes de la fourche (oui, la fourche peut proposer des choses que vous désirez) et augmentent aussi la probabilité d'une fusion ultérieure.
Sometimes a fork becomes so successful that, even though it was regarded even by its own instigators as a fork at the outset, it becomes the version everybody prefers, and eventually supplants the original by popular demand. A famous instance of this was the GCC/EGCS fork. The GNU Compiler Collection (GCC, formerly the GNU C Compiler) is the most popular Open Source native-code compiler, and also one of the most portable compilers in the world. Due to disagreements between the GCC's official maintainers and Cygnus Software,[23] one of GCC's most active developer groups, Cygnus created a fork of GCC called EGCS. The fork was deliberately non-adversarial: the EGCS developers did not, at any point, try to portray their version of GCC as a new official version. Instead, they concentrated on making EGCS as good as possible, incorporating patches at a faster rate than the official GCC maintainers. EGCS gained in popularity, and eventually some major operating system distributors decided to package EGCS as their default compiler instead of GCC. At this point, it became clear to the GCC maintainers that holding on to the « GCC » name while everyone switched to the EGCS fork would burden everyone with a needless name change, yet do nothing to prevent the switchover. So GCC adopted the EGCS codebase, and there is once again a single GCC, but greatly improved because of the fork.
Parfois une fourche gagne un tel succès que même si elle était considérée comme une fourche par ses instigateurs au départ, elle devient la version que tout le monde préfère et finalement supplante la version original à la demande des utilisateurs. Un exemple connu de ceci était la fourche GCC/EGCS. Le GNU Compiler Collection (GCC, anciennement GNU C Compiler) est le compilateur de code exécutable Open Source le plus populaire et aussi l'un des compilateurs les plus portables du monde. En raison de désaccords entre les développeurs officiel de GCC et Cygnus Software, [23] l'un des groupes de développement de GCC le plus actif, Cygnus créa une fourche de GCC appelée EGCS. Ils avaient décidé de ne pas entrer en compétition : les développeurs d'EGCS n'ont jamais, à aucun moment, essayé de présenter leur version de GCC comme étant la nouvelle version officielle. Ils se sont plutôt concentrés sur l'amélioration de EGCS en ajoutant des correctifs plus rapidement que ne le faisaient les développeurs officiels de GCC. EGCS a gagné en popularité et finalement certains parmi les principaux distributeurs de systèmes d'exploitation ont décidé d'adopter EGCS comme compilateur par défaut à la place de GCC. Il était alors devenu clair pour les développeurs de GCC que s'accrocher au nom « GCC », alors que tout le monde adoptait la fourche EGCS, ne serait qu'un désagrément pour tout le monde avec un changement de nom inutile mais qui au final n'empêcherait pas la migration. Alors GCC a adopté le code de base de EGCS et il y avait alors à nouveau plus qu'un seul GCC, mais grandement amélioré grâce à la fourche.
This example shows why you cannot always regard a fork as an unadulteratedly bad thing. A fork may be painful and unwelcome at the time, but you cannot necessarily know whether it will succeed. Therefore, you and the rest of the project should keep an eye on it, and be prepared not only to absorb features and code where possible, but in the most extreme case to even join the fork if it gains the bulk of the project's mindshare. Of course, you will often be able to predict a fork's likelihood of success by seeing who joins it. If the fork is started by the project's biggest complainer and joined by a handful of disgruntled developers who weren't behaving constructively anyway, they've essentially solved a problem for you by forking, and you probably don't need to worry about the fork taking momentum away from the original project. But if you see influential and respected developers supporting the fork, you should ask yourself why. Perhaps the project was being overly restrictive, and the best solution is to adopt into the mainline project some or all of the actions contemplated by the fork—in essence, to avoid the fork by becoming it.
Cet exemple montre que vous ne pouvez pas toujours voir une fourche comme une sorte d'adultère. Même si une fourche peut être douloureuse et indésirable, vous ne pouvez pas forcément prédire si elle réussira ou pas. Vous, et le reste du projet, devriez donc la surveillez et vous préparez, non seulement à en absorber des fonctionnalités et du code quand c'est possible, mais dans les cas les plus extrêmes à rejoindre la fourche si elle gagne le cœur du gros du projet. Bien sûr, vous pourrez souvent prédire les chances de succès d'une fourche d'après personnes qui s'y joignent. Si la fourche est initiée par les pires empoisonneurs et ralliée par un groupe de développeurs mécontents qui n'apportait rien de constructif de toute façon ils vous font en fait une faveur en choisissant un autre chemin et vous n'avez pas à vous soucier de l'importance que prendra la fourche par rapport au projet originel. Mais si vous voyez des développeurs influents et respectés soutenir la fourche vous devriez vous demander pourquoi. Peut-être que le projet devenait trop restrictif et la meilleure solution est alors que le projet principal fasse siennes toutes ou une partie des actions envisagées par la fourche, c'est-à-dire, éviter que la fourche se concrétise.
[modifier] Initiating a Fork / Amorcer une fourche
All the advice here assumes that you are forking as a last resort. Exhaust all other possibilities before starting a fork. Forking almost always means losing developers, with only an uncertain promise of gaining new ones later. It also means starting out with competition for users' attention: everyone who's about to download the software has to ask themselves: « Hmm, do I want that one or the other one? » Whichever one you are, the situation is messy, because a question has been introduced that wasn't there before. Some people maintain that forks are healthy for the software ecosystem as a whole, by a standard natural selection argument: the fittest will survive, which means that, in the end, everyone gets better software. This may be true from the ecosystem's point of view, but it's not true from the point of view of any individual project. Most forks do not succeed, and most projects are not happy to be forked.
Tous les conseils donnés ici supposent que la fourche intervient en dernier recours. Épuisez toutes les autres solutions avant de commencer une fourche. Le fait d'amorcer une fourche est presque toujours synonyme de perte de développeurs, avec seulement la promesse vague d'en gagner de nouveaux plus tard. Cela implique également que vous allez entrer en compétition pour gagner l'attention des utilisateurs : tous ceux qui s'apprêtent à télécharger le logiciel vont se demander : « Hum, est-ce que je veux celui-là ou cet autre là ? » Que vous soyez le premier ou le deuxième, la situation est épineuse car une nouvelle question a été ajoutée. D'après certaines personnes les fourches sont bonnes pour l'écosystème du logiciel entier si l'on se base sur les arguments de la sélection naturelle : le plus adapté survivra, ce qui signifie que, au final, tout le monde profite d'un meilleur logiciel. Cela peut être vrai du point de vue de l'écosystème, mais ce n'est pas vrai du point de vue du projet prit individuellement. La plupart des fourches ne réussissent pas et la plupart des projets ne sont pas enchantés d'être divisés.
A corollary is that you should not use the threat of a fork as an extremist debating technique—"Do things my way or I'll fork the project!"—because everyone is aware that a fork that fails to attract developers away from the original project is unlikely to survive long. All observers—not just developers, but users and operating system packagers too—will make their own judgement about which side to choose. You should therefore appear extremely reluctant to fork, so that if you finally do it, you can credibly claim it was the only route left.
Un corollaire à cela est que vous ne devriez pas utiliser l'argument de la fourche comme un argument extrémiste. : « Faites ce que je veux ou je commencerai une fourche ! », parce que tout le monde sait que les fourches qui n'arrivent pas à capter des développeurs du projet originel n'ont qu'une faible chance de survie. Tous les observateurs, pas seulement les développeurs, mais aussi les utilisateurs et ceux qui font les dépôts pour les systèmes d'exploitation, choisiront leur camp selon leurs propres critères. Vous devriez donc vous montrer réticent à l'idée de commencer une fourche, ainsi si vous devez finalement vous y résoudre, vous pourrez affirmer avec crédibilité que c'était votre dernière alternative.
Do not neglect to take all factors into account in evaluating the potential success of your fork. For example, if many of the developers on a project have the same employer, then even if they are disgruntled and privately in favor of a fork, they are unlikely to say so out loud if they know that their employer is against it. Many free software programmers like to think that having a free license on the code means no one company can dominate development. It is true that the license is, in an ultimate sense, a guarantor of freedom—if others want badly enough to fork the project, and have the resources to do so, they can. But in practice, some projects' development teams are mostly funded by one entity, and there is no point pretending that that entity's support doesn't matter. If it is opposed to the fork, its developers are unlikely to take part, even if they secretly want to.
Ne négligez aucun facteur lorsque vous évaluez les chances de succès de votre fourche. Par exemple, si beaucoup de développeurs sur un projet ont le même employeur, alors même s'ils sont mécontents et secrètement en faveur d'une fourche il y a peu de chance qu'ils l'annoncent ouvertement si leur employeur est contre. De nombreux programmeurs de logiciels libres aiment à penser que le fait d'appliquer une licence libre au code signifie qu'aucune entreprise ne peut en dominer le développement. C'est vrai que la licence est au final une garantie de liberté, si certains veulent vraiment initier une branche et ont les moyens de le faire ils le peuvent. Mais en pratique les équipes de développement de certains projets sont principalement financées par une entité et vous ne pouvez pas faire comme si ce soutien ne comptait pas. Si cette entité est opposée à la fourche il y a peu de chance que ses développeurs y prennent partie, même s'ils le désirent secrètement.
If you still conclude that you must fork, line up support privately first, then announce the fork in a non-hostile tone. Even if you are angry at, or disappointed with, the current maintainers, don't say that in the message. Just dispassionately state what led you to the decision to fork, and that you mean no ill will toward the project from which you're forking. Assuming that you do consider it a fork (as opposed to an emergency preservation of the original project), emphasize that you're forking the code and not the name, and choose a name that does not conflict with the project's name. You can use a name that contains or refers to the original name, as long as it does not open the door to identity confusion. Of course it's fine to explain prominently on the fork's home page that it descends from the original program, and even that it hopes to supplant it. Just don't make users' lives harder by forcing them to untangle an identity dispute.
Si pour autant vous pensez toujours qu'une fourche est nécessaire assurez vous de vos soutiens en privé en premier, annoncez ensuite la naissance de la fourche de manière amicale. Même si vous êtes en colère ou déçu par les responsables actuels ne le dites pas dans le message. Exposez sans emportement les raisons qui vous ont poussé à prendre cette décision et annoncez que vous ne souhaitez pas nuire au projet en faisant cela. En supposant que vous la considérez bien comme une fourche (en opposition avec une manœuvre d'urgence de préservation du projet originel), soulignez bien que vous utiliserez le code, mais pas le nom du projet et que vous choisissez un nom qui ne prêtera pas à confusion. Vous pouvez utiliser un nom qui contient ou fait référence au nom original tant qu'il évite toute confusion d'identité. Évidemment vous pouvez mettre en avant sur le page Web de la fourche le lien de parenté avec le programme originel et même que vous espérez le supplanter. Essayez simplement de ne pas compliquer la vie des utilisateurs en les mêlant à une bataille identitaire.
Finally, you can get things started on the right foot by automatically granting all committers of the original project commit access to the fork, including even those who openly disagreed with the need for a fork. Even if they never use the access, your message is clear: there are disagreements here, but no enemies, and you welcome code contributions from any competent source.
[23] Now part of RedHat (http://www.redhat.com/).Pour finir, vous pouvez commencer du bon pied en octroyant automatiquement l'accès de commit pour la fourche à tous ceux qui l'avaient déjà pour le projet originel, même à ceux qui montraient ouvertement leur désaccord sur la nécessité d'une fourche. Même s'ils n'utilisent jamais leur accès, votre message est clair : il y a des désaccords, mais pas d'ennemis et toutes les contributions de tous ceux qui en ont les compétences sont les bienvenues.
[23] Maintenant partie intégrante de RedHat (http://www.redhat.com).
