POSS Chap 7 Intro
Un article de Framalang Wiki.
This chapter is about how free software projects package and release their software, and how overall development patterns organize around those goals.
Ce chapitre se rapporte à la création et à la publication des logiciels par les projets de logiciels libres ainsi qu'à l'organisation du processus de développement tout entier autour de ces buts.
A major difference between Open Source projects and proprietary ones is the lack of centralized control over the development team. When a new release is being prepared, this difference is especially stark: a corporation can ask its entire development team to focus on an upcoming release, putting aside new feature development and non-critical bug fixing until the release is done. Volunteer groups are not so monolithic. People work on the project for all sorts of reasons, and those not interested in helping with a given release still want to continue regular development work while the release is going on. Because development doesn't stop, Open Source release processes tend to take longer, but be less disruptive, than commercial release processes. It's a bit like highway repair. There are two ways to fix a road: you can shut it down completely, so that a repair crew can swarm all over it at full capacity until the problem is solved, or you can work on a couple of lanes at a time, while leaving the others open to traffic. The first way is very efficient for the repair crew, but not for anyone else—the road is entirely shut down until the job is done. The second way involves much more time and trouble for the repair crew (now they have to work with fewer people and less equipment, in cramped conditions, with flaggers to slow and direct traffic, etc.), but at least the road remains useable, albeit not at full capacity.
L'une des grandes différences entre les projets Open Source et les projets propriétaires est l'absence de contrôle centralisé sur l'équipe de développement. Lorsqu'une nouvelle sortie est en préparation cette différence est particulièrement frappante : une entreprise peut demander à toute son équipe de développement de se concentrer sur la sortie proche en mettant de côté le développement de nouvelles fonctionnalités et les corrections de bogues mineurs jusqu'à ce que la publication de la nouvelle version. Les groupes de volontaires ne sont pas aussi monolithiques. Les gens travaillent sur le projet pour plein de raisons différentes et ceux à qui ça ne dit rien d'aider à la sortie voudront continuer le travail de développement normal alors qu'on approche de la sortie. Comme le développement ne s'arrête jamais, les procédures de sortie en Open Source tendent à être plus longues mais sont moins perturbantes que les procédures de sortie de logiciels commerciaux. C'est un peu le même problème que la réparation d'une autoroute. Il y a deux manières de réparer une route : vous pouvez la fermer complètement afin que les équipes de maintenance puissent l'envahir autant qu'elles le veulent jusqu'à ce que le problème soit résolu ou alors vous pouvez travailler sur quelques voies à la fois en laissant les autres ouvertes au trafic. La première manière est très efficace pour l'équipe de réparation, mais pour tous les autres la route est complètement fermée jusqu'à ce que le travail soit achevé. La deuxième solution implique beaucoup plus de problèmes pour l'équipe de chantier (maintenant ils doivent travailler avec moins de monde et moins d'équipement, dans des conditions plus restreintes, avec des gens pour ralentir et diriger la circulation, etc.), mais au moins la route reste utilisable, même si ce n'est pas à sa capacité maximale.
Open source projects tend to work the second way. In fact, for a mature piece of software with several different release lines being maintained simultaneously, the project is sort of in a permanent state of minor road repair. There are always a couple of lanes closed; a consistent but low level of background inconvenience is always being tolerated by the development group as a whole, so that releases get made on a regular schedule.
Les projets Open Source ont tendance à adopter la deuxième solution. En fait, pour un logiciel évolué ayant plusieurs lignes de sortie maintenues simultanément, le projet est en quelque sorte toujours en travaux. Il y a toujours quelques voies qui sont fermées, un niveau constant, mais bas, d'incommodité est toujours toléré par l'ensemble du groupe afin que les sorties puissent être faites à intervalles réguliers.
The model that makes this possible generalizes to more than just releases. It's the principle of parallelizing tasks that are not mutually interdependent—a principle that is by no means unique to Open Source development, of course, but one which Open Source projects implement in their own particular way. They cannot afford to annoy either the roadwork crew or the regular traffic too much, but they also cannot afford to have people dedicated to standing by the orange cones and flagging traffic along. Thus they gravitate toward processes that have flat, constant levels of administrative overhead, rather than peaks and valleys. Volunteers are generally willing to work with small but consistent amounts of inconvenience; the predictability allows them to come and go without worrying about whether their schedule will clash with what's happening in the project. But if the project were subject to a master schedule in which some activities excluded other activities, the result would be a lot of developers sitting idle a lot of the time—which would be not only inefficient but boring, and therefore dangerous, in that a bored developer is likely to soon be an ex-developer.
Le modèle qui rend tout cela possible ne s'applique pas qu'aux sorties uniquement. C'est le principe de la parallélisation des tâches qui ne sont pas mutuellement interdépendantes, un principe qui n'est en aucun cas spécifique au développement Open Source évidemment, mais un principe que les projets Open Source adaptent à leurs besoins particuliers. Ils ne peuvent pas se permettre de trop embêter l'équipe de chantier ou le trafic habituel, mais ils ne peuvent pas non plus se permettre d'employer des personnes spécialement pour se poster près des plots oranges et agiter leur drapeau pour faire la circulation. Ils s'orientent donc vers des processus qui demandent un niveau constant d'administration plutôt que vers des processus irréguliers. Les volontaires s'accommodent très bien d'un niveau faible, mais constant, de désagréments, comme tout est prévisible ils peuvent aller et venir sans se demander si leur emploi du temps entrera en conflit avec ce qui se passe dans le projet. Mais si le projet était soumis à un emploi du temps général dans lequel certaines activités en excluraient d'autres, au final on se retrouverait avec beaucoup de développeurs n'ayant rien à faire pendant une grande partie du temps, ce qui serait non seulement inefficace mais aussi ennuyeux et donc dangereux puisqu'il y a de bonnes chances qu'un développeur qui s'ennuie quitte le projet.
Release work is usually the most noticeable non-development task that happens in parallel with development, so the methods described in the following sections are geared mostly toward enabling releases. However, note that they also apply to other parallelizable tasks, such as translations and internationalization, broad API changes made gradually across the entire code base, etc.
Le travail de publication est généralement celui qui est le plus visible parmi les tâches qui ne sont pas directement liées au développement et qui sont faites en parallèle au développement, donc les méthodes décrites dans les parties suivantes concernent principalement les sorties. Cependant, notez qu'elles s'appliquent également à d'autres tâches parallélisables, comme les traductions et l'internationalisation, les vastes changement d'API apportés graduellement à l'ensemble du code source, etc.
