POSS Chap 4 Intro

Un article de Framalang Wiki.

Jump to: navigation, search

The first questions people usually ask about free software are "How does it work? What keeps a project running? Who makes the decisions?" I'm always dissatisfied with bland responses about meritocracy, the spirit of cooperation, code speaking for itself, etc. The fact is, the question is not easy to answer. Meritocracy, cooperation, and running code are all part of it, but they do little to explain how projects actually run on a day-to-day basis, and say nothing about how conflicts are resolved.

This chapter tries to show the structural underpinnings successful projects have in common. I mean "successful" not just in terms of technical quality, but also operational health and survivability. Operational health is the project's ongoing ability to incorporate new code contributions and new developers, and to be responsive to incoming bug reports. Survivability is the project's ability to exist independently of any individual participant or sponsor—think of it as the likelihood that the project would continue even if all of its founding members were to move on to other things. Technical success is not hard to achieve, but without a robust developer base and social foundation, a project may be unable to handle the growth that initial success brings, or the departure of charismatic individuals.


Les premières questions que les gens posent généralement concernant les logiciels libres sont : "Comment ça marche ? Qu'est-ce qui fait avancer un projet ? Qui prend les décisions ?". Je ne me satisfais jamais des réponses sur la méritocratie, l'esprit de coopération, le code qui parle de lui-même, etc. Le fait est que la réponse à ces questions n'est pas simple. La méritocratie, la coopération et le code qui marche en font partie, mais n'expliquent pas vraiment comment un projet fonctionne au quotidien et encore moins comment sont résolus les conflits.

Ce chapitre tente de mettre en avant les fondements structurels que les projets réussis ont en commun. J'emploie "réussis" non seulement pour parler de qualité technique, mais aussi de santé opérationnelle et de capacité de survie. La santé opérationnelle réside dans la capacité continuelle d'un projet à incorporer de nouvelles contributions au code et de nouveaux développeurs et à être réactif face aux rapports de bogue. Quant à la capacité de survie, c'est l'aptitude du projet à exister indépendamment de tout participant individuel ou sponsor, ce que l'on peut traduire par la probabilité que le projet continue même si tous les membres fondateurs passent à autre chose. La réussite technique n'est pas difficile à atteindre mais, sans une équipe de développeurs et des fondations sociales solides, un projet peut ne pas se montrer capable de faire face à la croissance que génèrent des débuts réussis ou aux départs d'individus charismatiques.


There are various ways to achieve this kind of success. Some involve a formal governance structure, by which debates are resolved, new developers are invited in (and sometimes out), new features planned, and so on. Others involve less formal structure, but more conscious self-restraint, to produce an atmosphere of fairness that people can rely on as a de facto form of governance. Both ways lead to the same result: a sense of institutional permanence, supported by habits and procedures that are well understood by everyone who participates. These features are even more important in self-organizing systems than in centrally-controlled ones, because in self-organizing systems, everyone is conscious that a few bad apples can spoil the whole barrel, at least for a while.


Il y a plusieurs façons d'atteindre à cette réussite. Certaines impliquent une structure de gouvernance formelle qui permet de résoudre les débats, d'intégrer (et parfois d'exclure) de nouveaux développeurs, de planifier de nouvelles fonctionnalités, etc. D'autres impliquent une structure moins formelle, mais plus d'auto-modération volontaire, pour parvenir à une atmosphère de respect des règles sur laquelle les gens peuvent compter comme mode de gouvernance de fait. Les deux moyens mènent au même résultat : un sens de la persistance institutionnelle, étayé par des habitudes et des procédures bien comprises de tous ceux qui participent au projet. Ces caractéristiques sont même plus importantes dans des systèmes auto-organisés que dans ceux où le contrôle est centralisé, car dans les systèmes auto-organisés chacun est conscient du fait que quelques pommes pourries peuvent gâter tout le panier, du moins pendant un certain temps.


Forkability

The indispensable ingredient that binds developers together on a free software project, and makes them willing to compromise when necessary, is the code's forkability: the ability of anyone to take a copy of the source code and use it to start a competing project, known as a fork. The paradoxical thing is that the possibility of forks is usually a much greater force in free software projects than actual forks, which are very rare. Because a fork is bad for everyone (for reasons examined in detail in the section called “Forks” in Chapter 8, Managing Volunteers), the more serious the threat of a fork becomes, the more willing people are to compromise to avoid it.


Fourchabilité

L'ingrédient indispensable qui maintient les développeurs ensemble dans un projet de logiciel libre et les amène à faire des compromis si nécessaire est la "fourchabilité" du code, soit la possibilité pour chacun de prendre une copie du code source et de l'utiliser pour démarrer un projet concurrent, connu sous le nom de "fork" ou "fourche" en français. Le paradoxe est que la possibilité de "fork" exerce généralement une pression plus forte dans les projets de logiciel libre que les "forks" qui se concrétisent qui sont très rares. Parce qu'un "fork" est une mauvaise chose pour tous, (pour des raisons exposées de manière détaillée dans la section "Fourches" du Chapitre 8, Gérer les volontaires), plus la menace de bifurcation devient sérieuse, plus on est prêt à faire de compromis pour l'éviter.


Forks, or rather the potential for forks, are the reason there are no true dictators in free software projects. This may seem like a surprising claim, considering how common it is to hear someone called the "dictator" or "tyrant" in a given Open Source project. But this kind of tyranny is special, quite different from the conventional understanding of the word. Imagine a king whose subjects could copy his entire kingdom at any time and move to the copy to rule as they see fit. Would not such a king govern very differently from one whose subjects were bound to stay under his rule no matter what he did?


Les fourches, ou plutôt le potentiel de démarrer une fourche, sont la raison pour laquelle il n'y a pas de vrai dictateurs dans les projets de logiciels libres. Cette déclaration peut paraître surprenante, étant donné qu'il est très courant d'entendre parler d'un "dictateur" ou d'un "tyran" au sein d'un projet Open Source donné. Mais il s'agit d'une sorte de tyrannie particulière, très différente de la conception générale de ce terme. Imaginez un roi dont les sujets pourraient à tout moment copier le royaume entier et emménager dans la copie pour gouverner comme bon leur semble. Il est à parier que le règne d'un tel roi serait fort différent de celui dont les sujets sont contraints de rester sous sa loi quoi qu'il fasse.


This is why even projects that are not formally organized as democracies are, in practice, democracies when it comes to important decisions. Replicability implies forkability; forkability implies consensus. It may well be that everyone is willing to defer to one leader (the most famous example being Linus Torvalds in Linux kernel development), but this is because they choose to do so, in an entirely non-cynical and non-sinister way. The dictator has no magical hold over the project. A key property of all Open Source licenses is that they do not give one party more power than any other in deciding how the code can be changed or used. If the dictator were to suddenly start making bad decisions, there would be restlessness, followed eventually by revolt and a fork. Except, of course, things rarely get that far, because the dictator compromises first.

But just because forkability puts an upper limit on how much power anyone can exert in a project doesn't mean there aren't important differences in how projects are governed. You don't want every decision to come down to the last-resort question of who is considering a fork. That would get tiresome very quickly, and sap energy away from real work. The next two sections examine different ways to organize projects such that most decisions go smoothly. These two examples are somewhat idealized extremes; many projects fall somewhere along a continuum between them.

C'est pourquoi même les projets qui ne sont pas formellement organisés comme des démocraties sont, dans la pratique, des démocraties quand il s'agit de prendre une décision importante. Pouvoir répliquer le code implique pouvoir créer un fourche et la possibilité de créer un fourche implique le consensus. Il se peut très bien que tout le monde accepte de s'en remettre à un leader (l'exemple le plus célèbre étant Linus Torvalds et le développement du noyau Linux), mais parce qu'ils ont choisi de le faire de manière totalement dénuée de cynisme et de malignité. Le dictateur n'a pas d'emprise magique sur le projet. Une des caractéristiques essentielles des licences Open Source est qu'elles ne donnent pas plus de pouvoir à une personne qu'à une autre pour décider comment le code peut être modifié ou utilisé. Si le dictateur se mettait soudain à prendre de mauvaises décisions, s'élèverait alors un mécontentement suivi éventuellement d'une révolte et d'une fourche. Si ce n'est, bien sûr, que les choses vont rarement si loin, car le dictateur cède le premier.

Mais le fait que la possibilité de fourche fixe la limite supérieure dans laquelle chacun peut exercer son pouvoir à l'intérieur du projet ne veut pas dire qu'il n'y a pas de différences importantes dans la façon de gouverner les projets. Il ne s'agit pas de ramener chaque décision à la question de qui envisage une fourche, ce qui doit rester le dernier recours. Cela deviendrait vite fatigant et détournerait l'énergie du travail à réaliser. Les deux parties suivantes passent en revue différentes manières d'organiser les projets de sorte que la plupart des décisions passent en douceur. Les deux exemples cités sont des extrêmes un peu idéalisés ; la plupart des projets se situent quelque part entre les deux.
Récupérée de « http://www.framalang.org/wiki/POSS_Chap_4_Intro »