POSS Chap 1 Part 0
Un article de Framalang Wiki.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Oivier | OLV | Traduction | Terminé |
| Coeurgan | CGN | Relecture | En cours |
| ??? | Validation |
Sommaire |
[modifier] Chapter 1. Introduction / Introduction
[modifier] §1
Most free software projects fail.
We tend not to hear very much about the failures. Only successful projects attract attention, and there are so many free software projects in total[2] that even though only a small percentage succeed, the result is still a lot of visible projects. We also don't hear about the failures because failure is not an event. There is no single moment when a project ceases to be viable; people just sort of drift away and stop working on it. There may be a moment when a final change is made to the project, but those who made it usually didn't know at the time that it was the last one. There is not even a clear definition of when a project is expired. Is it when it hasn't been actively worked on for six months? When its user base stops growing, without having exceeded the developer base? What if the developers of one project abandon it because they realized they were duplicating the work of another-and what if they join that other project, then expand it to include much of their earlier effort? Did the first project end, or just change homes?
La plupart des projets de logiciel libre échouent.
Nous avons tendance à ne pas trop remarquer les échecs. Seuls les projets qui réussissent attirent notre attention et le nombre de projets de logiciels libres dans leur ensemble [2] est si conséquent que même si le nombre de projets réussis est relativement faible, leur visibilité est néanmoins importante. Si nous n'entendons pas parler des échecs c'est aussi parce qu'un échec est un non événement. Un projet ne cesse pas d'être viable à un instant précis ; je dirais plutôt que les gens s'en écartent et finissent par l'abandonner. Il se peut qu'à un moment donné on apporte un dernier changement au projet, mais ceux qui le menaient alors ne savaient pas que ce serait le dernier. Il n'existe même pas de définition claire de la mort d'un projet. Est-ce quand on n'y a plus travaillé activement depuis six mois ? Quand le nombre de ses utilisateurs cesse de croître, sans avoir dépassé le nombre de ses développeurs ? Et que dire d'un projet qui est abandonné parce que ses développeurs se sont rendus compte qu'ils dupliquaient un travail existant et qu'ils décident de rejoindre cet autre projet pour l'améliorer et y intégrer une grande partie de leurs travaux précédents ? Le premier projet est-il mort ou a-t-il juste changé d'adresse ?[modifier] §2
Because of such complexities, it's impossible to put a precise number on the failure rate. But anecdotal evidence from over a decade in Open Source, some casting around on SourceForge.net, and a little Googling all point to the same conclusion: the rate is extremely high, probably on the order of 90-95%. The number climbs higher if you include surviving but dysfunctional projects: those which are producing running code, but which are not pleasant places to be, or are not making progress as quickly or as dependably as they could.
En raison de cette complexité, il est impossible de déterminer précisément le taux d'échec. Mais le constat empirique après plus d'une décennie dans l'Open Source, quelques participations à SourceForge.net et un peu de « googlage » est le suivant : le taux est extrêmement élevé, probablement de l'ordre de 90% à 95%. Ce taux est encore plus élevé si l'on y inclut les projets qui ont survécu mais qui fonctionnent mal, à savoir ceux qui produisent des applications utilisables mais qui ne sont pas des lieux où il fait bon vivre ou qui ne progressent pas de manière aussi rapide et fiable qu'ils le pourraient.
[modifier] §3
This book is about avoiding failure. It examines not only how to do things right, but how to do them wrong, so you can recognize and correct problems early. My hope is that after reading it, you will have a repertory of techniques not just for avoiding common pitfalls of Open Source development, but also for dealing with the growth and maintenance of a successful project. Success is not a zero-sum game, and this book is not about winning or getting ahead of the competition. Indeed, an important part of running an Open Source project is working smoothly with other, related projects. In the long run, every successful project contributes to the well-being of the overall, worldwide body of free software.
L'objet de cet ouvrage est d'éviter l'échec. Il passe en revue non seulement comment faire les choses correctement, mais aussi comment les faire de travers afin que chacun puisse détecter et corriger les problèmes rapidement. Mon plus grand souhait est qu'après l'avoir lu, le lecteur dispose d'un répertoire de techniques pour éviter les pièges les plus courants du développement Open Source mais aussi pour gérer la croissance et la maintenance d'un projet réussi. La réussite n'est pas un jeu à somme nulle et cet ouvrage ne parle pas de gagner ni de dépasser la concurrence. En effet, un aspect important dans le développement d'un projet Open Source consiste à travailler sans heurt avec d'autres projets connexes. Sur le long terme, chaque projet réussi contribue au bien-être de l'organisme « logiciel libre » dans son ensemble et partout dans le monde.
[modifier] §4
It would be tempting to say that free software projects fail for the same sorts of reasons proprietary software projects do. Certainly, free software has no monopoly on unrealistic requirements, vague specifications, poor resource management, insufficient design phases, or any of the other hobgoblins already well known to the software industry. There is a huge body of writing on these topics, and I will try not to duplicate it in this book. Instead, I will attempt to describe the problems peculiar to free software. When a free software project runs aground, it is often because the developers (or the managers) did not appreciate the unique problems of Open Source software development, even though they might have been quite prepared for the better-known difficulties of closed-source development.
Il serait tentant de dire que les projets de logiciels libres échouent pour les mêmes raisons que les projets de logiciels propriétaires. Le libre n'a pas le monopole des cahiers des charges farfelus, des spécifications floues, de la gestion déficiente des ressources humaines, des phases de conception insuffisantes et autres lutins malveillants bien connus de l'industrie du logiciel. La somme d'écrits en cette matière est déjà considérable, je ne m'étendrai donc pas sur ce sujet. J'essaierai plutôt de décrire les problèmes spécifiques au logiciel libre. Quand un projet de logiciel libre s'écroule c'est souvent parce que les développeurs (ou les directeurs) n'ont pas su évaluer les problèmes propres au développement d'un logiciel Open Source, alors même qu'ils étaient rodés aux difficultés mieux connues du développement à code fermé.
--217.128.190.93 22 mars 2007 à 13:56 (CET):hobgoblins -> gremlins ;)
[modifier] §5
One of the most common mistakes is unrealistic expectations about the benefits of Open Source itself. An open license does not guarantee that hordes of active developers will suddenly volunteer their time to your project, nor does open-sourcing a troubled project automatically cure its ills. In fact, quite the opposite: opening up a project can add whole new sets of complexities, and cost more in the short term than simply keeping it in-house. Opening up means arranging the code to be comprehensible to complete strangers, setting up a development web site and email lists, and often writing documentation for the first time. All this is a lot of work. And of course, if any interested developers do show up, there is the added burden of answering their questions for a while before seeing any benefit from their presence. As developer Jamie Zawinski said about the troubled early days of the Mozilla project:
Une des erreurs les plus courantes consiste à placer des espérances démesurées à l'égard de l'Open Source. Une licence ouverte ne garantit pas que des hordes de développeurs se mettront immédiatement au service de votre projet et ouvrir le code d'un projet en difficulté ne le guérit pas automatiquement de tous ses maux. En fait, c'est plutôt le contraire : ouvrir un projet peut ajouter une nouvelle série de complications et coûter plus cher à court terme que le garder fermé. Ouvrir veut dire remanier le code pour le rendre compréhensible pour quelqu'un de complètement étranger au projet, mettre en place un espace web de développement et des listes de diffusion et, souvent, écrire pour la première fois la documentation. Tout ceci représente beaucoup de travail. Et bien sûr, si des développeurs intéressés se présentent, les intégrer, répondre à leurs questions, tout cela peut prendre un certain temps avant de percevoir les bénéfices de leur présence. Comme l'a dit Jamie Zawinski en parlant des périodes troubles du début du projet Mozilla :
- Open Source does work, but it is most definitely not a panacea. If there's a cautionary tale here, it is that you can't take a dying project, sprinkle it with the magic pixie dust of 'Open Source', and have everything magically work out. Software is hard. The issues aren't that simple
- « L'Open Source fonctionne, mais ce n'est vraiment pas la panacée. La morale de cette histoire c'est qu'on ne peut pas prendre un projet moribond et le saupoudrer de poudre de perlimpinpin « Open Source » pour que tout se mette à marcher par magie. Le développement logiciel c'est difficile. Les solutions ne sont pas si simples. »
- (extrait de http://www.jwz.org/gruntle/nomo.html)
[modifier] §6
A related mistake is that of skimping on presentation and packaging, figuring that these can always be done later, when the project is well under way. Presentation and packaging comprise a wide range of tasks, all revolving around the theme of reducing the barrier to entry. Making the project inviting to the uninitiated means writing user and developer documentation, setting up a project web site that's informative to newcomers, automating as much of the software's compilation and installation as possible, etc. Many programmers unfortunately treat this work as being of secondary importance to the code itself. There are a couple of reasons for this. First, it can feel like busywork, because its benefits are most visible to those least familiar with the project, and vice versa. After all, the people who develop the code don't really need the packaging. They already know how to install, administer, and use the software, because they wrote it. Second, the skills required to do presentation and packaging well are often completely different from those required to write code. People tend to focus on what they're good at, even if it might serve the project better to spend a little time on something that suits them less. Chapter 2, Getting Started discusses presentation and packaging in detail, and explains why it's crucial that they be a priority from the very start of the project.
Une erreur connexe consiste à économiser sur la présentation et le packaging en se disant que ça peut être fait plus tard quand le projet sera sur les rails. La présentation et le packaging comportent un nombre important de tâches qui ont toutes pour objectif de faciliter l'accès. Pour rendre le projet accueillant aux non initiés il faut écrire la documentation à destination des développeurs et des utilisateurs, mettre en place un site web pour le projet qui informe les nouveaux arrivants, automatiser autant que possible la compilation et l'installation du logiciel, etc. Beaucoup de programmeurs considèrent malheureusement ce travail comme secondaire par rapport au code lui-même. Et ceci pour plusieurs raisons. Premièrement, ce travail leur apparaît comme une perte de temps car ses bénéfices sont plus visibles pour ceux qui sont le moins familiarisés avec le projet et inversement. Après tout, les gens qui développent le projet n'ont pas vraiment besoin du packaging. Ils savent déjà comment installer, administrer et utiliser le logiciel qu'ils ont écrit. Deuxièmement, les compétences requises pour faire la présentation et le packaging sont souvent complètement différentes de celles requises pour écrire le code. Les gens ont tendance à se concentrer sur ce qu'ils connaissent le mieux, même s'ils peuvent rendre un meilleur service au projet en consacrant un peu de temps aux choses qui leur conviennent moins. Le Chapitre 2 Bien démarrer, examine en détail les questions de présentation et de packaging et explique pourquoi il est essentiel d'en faire une priorité dès le commencement du projet.
--Coeurgan 29 avril 2007 à 18:02 (CEST):
de tâches qui tournent toutes autour de la question de réduire la barrière d'accès -> de tâches qui ont toutes pour objectif de faciliter l'accès.
[modifier] §7
Next comes the fallacy that little or no project management is required in Open Source, or conversely, that the same management practices used for in-house development will work equally well on an Open Source project. Management in an Open Source project isn't always very visible, but in the successful projects, it's usually happening behind the scenes in some form or another. A small thought experiment suffices to show why. An Open Source project consists of a random collection of programmers-already a notoriously independent-minded category-who have most likely never met each other, and who may each have different personal goals in working on the project. The thought experiment is simply to imagine what would happen to such a group without management. Barring miracles, it would collapse or drift apart very quickly. Things won't simply run themselves, much as we might wish) otherwise. But the management, though it may be quite active, is often informal, subtle, and low-key. The only thing keeping a development group together is their shared belief that they can do more in concert than individually. Thus the goal of management is mostly to ensure that they continue to believe this, by setting standards for communications, by making sure useful developers don't get marginalized due to personal idiosyncracies, and in general by making the project a place developers want to keep coming back to. Specific techniques for doing this are discussed throughout the rest of this book.
Vient ensuite l'idée fallacieuse que l'Open Source n'a pas besoin ou presque de gestion de projet et, inversement, que les techniques de management utilisées pour les projets développés en interne fonctionneront également pour le projet Open Source. Le management dans un projet Open Source n'est pas toujours très visible, mais dans les projets réussis, il est toujours présent en coulisse d'une manière ou d'une autre. Un petit exercice d'imagination suffit pour s'en rendre compte. Un projet Open Source consiste en un assemblage fortuit de programmeurs, catégorie déjà réputée pour son indépendance d'esprit, qui très probablement ne se sont jamais rencontrés et qui peuvent y participer en ayant chacun des objectifs personnels différents. Il est facile d'imaginer ce que deviendrait un tel groupe sans management. A moins d'un miracle, il s'écroulerait ou se séparerait très vite. Les choses ne vont pas marcher d'elles-même, que nous le voulions ou non. Mais le management, aussi actif soit-il, est le plus souvent informel, subtil et en demi-teinte. La seule chose qui maintienne un groupe de développeurs ensemble est la croyance partagée qu'ils peuvent faire plus collectivement qu'individuellement. Dans ce cadre, le management a pour but principal de faire en sorte qu'ils continuent à le croire, en établissant des formes de communication, en s'assurant que des développeurs utiles ne sont pas marginalisés en raisons de caractéristiques personnelles et de manière générale en faisant en sorte que le projet reste un espace où les développeurs ont envie de revenir. Les techniques spécifiques pour réussir cela sont abordées dans le reste de l'ouvrage.
Coeurgan 29 avril 2007 à 18:02 (CEST):
Les choses ne marchent pas d'elles-mêmes, pour autant que nous le voudrions. -> Les choses ne vont pas marcher d'elles-même, que nous le voulions ou non.
[modifier] §8
Finally, there is a general category of problems that may be called "failures of cultural navigation." Ten years ago, even five, it would have been premature to talk about a global culture of free software, but not anymore. A recognizable culture has slowly emerged, and while it is certainly not monolithic-it is at least as prone to internal dissent and factionalism as any geographically bound culture-it does have a basically consistent core. Most successful Open Source projects exhibit some or all of the characteristics of this core. They reward certain types of behaviors, and punish others; they create an atmosphere that encourages unplanned participation, sometimes at the expense of central coordination; they have concepts of rudeness and politeness that can differ substantially from those prevalent elsewhere. Most importantly, longtime participants have generally internalized these standards, so that they share a rough consensus about expected conduct. Unsuccessful projects usually deviate in significant ways from this core, albeit unintentionally, and often do not have a consensus about what constitutes reasonable default behavior. This means that when problems arise, the situation can quickly deteriorate, as the participants lack an already established stock of cultural reflexes to fall back on for resolving differences.
Enfin, il y a une catégorie générique de problèmes qu'on pourrait appeler « échecs de navigation culturelle ». Il y a dix ou même cinq ans, il aurait été prématuré de parler d'une culture mondiale du logiciel libre, mais plus maintenant. Une culture reconnaissable a émergé lentement et bien qu'elle ne soit pas monolithique, elle est aussi sujette à la dissidence et aux factions que n'importe quelle culture géographiquement définie, elle est basée sur un noyau solide. La plupart des projets Open Source réussis affichent quelques-unes sinon toutes les caractéristiques de ce noyau. Ils récompensent certains types de comportements et en punissent d'autres ; ils créent une atmosphère qui encourage la participation non planifiée, parfois au détriment de la coordination centralisée ; ils possèdent leur propre conception de la politesse et de la brutalité qui peuvent différer foncièrement de celle qui prévaut ailleurs. Et plus important, les participants de longue date ont généralement intériorisé ces critères au point d'être plus ou moins unanimes sur les comportements attendus. Les projets qui échouent généralement s'écartent de manière significative de ce noyau, même involontairement et n'ont pas de définition unanime de ce qui constitue le comportement raisonnable par défaut. Ce qui veut dire que quand les problèmes surgissent la situation peut se détériorer rapidement car les participants ne disposent pas d'un stock de réflexes culturels établis auxquels recourir pour résoudre les différends.
[modifier] §9
This book is a practical guide, not an anthropological study or a history. However, a working knowledge of the origins of today's free software culture is an essential foundation for any practical advice. A person who understands the culture can travel far and wide in the Open Source world, encountering many local variations in custom and dialect, yet still be able to participate comfortably and effectively everywhere. In contrast, a person who does not understand the culture will find the process of organizing or participating in a project difficult and full of surprises. Since the number of people developing free software is still growing by leaps and bounds, there are many people in that latter category-this is largely a culture of recent immigrants, and will continue to be so for some time. If you think you might be one of them, the next section provides background for discussions you'll encounter later, both in this book and on the Internet. (On the other hand, if you've been working with Open Source for a while, you may already know a lot of its history, so feel free to skip the next section.)
Cet ouvrage est un guide pratique et non une étude anthropologique ou historique. Cependant, une réelle connaissance des origines de la culture actuelle du logiciel libre est une base essentielle pour tout conseil pratique. Une personne qui en comprend la culture peut parcourir en long et en large le monde de l'Open Source, rencontrer maintes variantes locales dans la coutume et le dialecte, tout en étant capable de participer partout avec aisance et efficacité. En revanche, pour une personne qui ne comprend pas cette culture, le processus d'organisation ou de participation d'un projet sera difficile et plein de surprises. Comme le nombre de personnes qui développent des logiciels libres ne cesse de croître à grandes enjambées, il y a beaucoup de monde dans cette dernière catégorie, c'est en grande partie une culture de nouveaux immigrants, et ça continuera à l'être pendant un certain temps. Si vous pensez être l'un d'eux, la section suivante vous fournit l'arrière-plan des discussions que vous entendrez plus tard, aussi bien dans ce livre que sur Internet. (D'autre part, si vous avez travaillé dans le monde du libre depuis longtemps, vous en savez peut-être déjà pas mal sur son histoire. Dans ce cas, n'hésitez pas à sauter la prochaine section.)
--Coeurgan 27 mars 2007 à 15:15 (CEST):
le processus [d'organisation ou de participation] d'organiser ou de participer à un projet -> organiser ou participer à un projet
81.57.208.69 7 mars 2007 à 00:30 (CET)
