Je vous invite à lire le livre Produire du logiciel libre publié par Framabook et dont voici l’introduction :
La plupart des projets de logiciels libres échouent.
Nous avons tendance à ne pas trop remarquer les échecs. Seuls les succès attirent notre attention, et le nombre total de projets de logiciels libres est si important que leur visibilité reste forte malgré un taux de réussite relativement faible. De même, nous n’entendons pas
parler des échecs car l’insuccès est un non-évènement. Le moment précis où un projet cesse d’être viable n’existe pas : les gens s’en écartent et finissent par l’abandonner. Il se peut qu’à un moment donné un dernier changement soit apporté au projet mais l’auteur, à cet instant, ne sait pas qu’il s’agit du dernier. Comment déterminer la mort d’un projet ? 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é celui des développeurs ? Et que dire d’un projet abandonné parce que ses développeurs, se rendant compte qu’ils reproduisaient un travail existant, se décident à rejoindre un autre projet pour l’améliorer en y intégrant une grande partie de leurs travaux précédents ? Le premier projet est-il mort ou a-t-il simplement changé d’adresse ?
En raison de cette complexité, il est impossible de déterminer précisément le taux d’échec. Mais le constat qui ressort de plus d’une décennie dans l’Open Source, de quelques participations à SourceForge.net et d’un peu de « googlage » est le suivant : ce taux est extrêmement élevé, probablement de l’ordre de 90% à 95%. Il l’est encore plus si l’on y inclut les projets survivants mais qui fonctionnent mal : certes ils produisent des applications utilisables, mais il est pénible d’y travailler, ou bien il est impossible d’y progresser comme on pourrait le souhaiter.
L’objectif de cet ouvrage est d’éviter l’échec. Il passe en revue non seulement les bonnes pratiques, mais aussi les mauvaises, afin que chacun puisse détecter et corriger les problèmes rapidement.
Mon plus grand souhait est qu’après sa lecture, on puisse disposer d’un répertoire de techniques pour, d’une part, éviter les pièges les plus courants du développement Open Source, et d’autre part, gérer la croissance et la maintenance d’un projet réussi. Le succès n’est pas un jeu à somme nulle et il ne s’agit pas ici de victoire ni de domination de la concurrence. En réalité, une part importante du développement d’un projet Open Source consiste à travailler sans heurt avec les autres projets apparentés. À long terme, chaque réussite contribue au bien-être du « logiciel libre », dans son ensemble et partout dans le monde. Il serait tentant de dire que les projets de logiciels libres et les projets à caractère propriétaire échouent pour les mêmes raisons.
Le libre n’a pas le monopole des agendas farfelus, des spécifications floues, de la mauvaise gestion des ressources humaines, des phases de conception insuffisantes et autres nuisances bien connues de l’industrie du logiciel. La somme d’écrits traitant de ce sujet est déjà considérable, je ne m’étendrai donc pas davantage. J’essaierai plutôt de décrire les problèmes spécifiques au logiciel libre. Quand un projet 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é.
Mesurez vos attentes vis-à-vis de l’Open Source, ne tombez pas dans le piège d’une trop grande ambition. Une licence ouverte ne met pas immédiatement des légions de développeurs au service de votre projet, et ouvrir le code d’un projet en difficulté n’est pas un remède à tous les maux. En fait, c’est plutôt le contraire : ouvrir un projet peut ajouter une nouvelle série de complications et coûte plus cher à court terme que le garder fermé. Ouvrir veut dire remanier le code pour le rendre compréhensible par quelqu’un de complètement étranger au projet, mettre en place un espace Web de développement, des listes de diffusion et, souvent, écrire pour la première fois la documentation. Tout ceci représente beaucoup de travail. Bien sûr, si des développeurs intéressés se présentent, il faudra les intégrer, répondre à leurs questions, tout cela peut prendre un certain temps avant que vous ne perceviez 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 :
« 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 traiter à la poudre de perlimpinpin « Open Source »
pour que tout se mette à marcher comme par magie.
Le développement logiciel c’est difficile.
Les solutions ne sont pas si simples. »
Lésiner sur la présentation et la création de paquets en remettant cela à plus tard, une fois le projet sur les rails, est une erreur. La présentation et la création de paquets comportent un nombre important de tâches visant à en faciliter l’approche. Pour rendre le projet accueillant aux néophytes, il faut écrire la documentation développeur et utilisateur, créer pour le projet un site Web informant les curieux, 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, c’est à leurs yeux une perte de temps car ils n’en tirent pas directement les bénéfices contrairement aux personnes moins familières avec le projet. Après tout, les gens qui développent le projet n’ont pas vraiment besoin qu’on leur prépare des paquets. Ils savent déjà comment installer, administrer et utiliser le logiciel qu’ils ont écrit. Deuxièmement, les compétences requises pour la présentation et la création de paquets sont souvent complètement différentes de celles nécessaires à l’écriture du 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 examine en détail les questions de présentation et de création de paquets. Il explique pourquoi il est essentiel d’en faire une priorité dès le lancement du projet.
Vient ensuite l’idée fausse que l’Open Source n’a guère besoin de gestion de projet et qu’inversement les techniques de direction utilisées pour les développements 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. Inutile de pousser la réflexion très loin 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 ne se sont très probablement jamais rencontrés et qui peuvent participer en ayant chacun des objectifs personnels différents. Il est facile d’imaginer ce que deviendrait un tel groupe sans management. À moins d’un miracle, il s’écroulerait ou éclaterait très vite. Les choses ne vont pas marcher d’elles-mêmes, que nous le voulions ou non. Mais le management, aussi actif soit-il, est le plus souvent informel, subtil et voilé. La seule chose qui maintienne un groupe de développeurs ensemble est la croyance commune 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.
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 : plus maintenant. Une culture reconnaissable a émergé lentement et bien qu’elle ne soit pas monolithique (elle est autant sujette à la dissidence et aux factions que n’importe quelle culture géographiquement définie), elle est basée sur un noyau fondamentalement 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é pouvant différer foncièrement de celle qui prévaut par ailleurs. Et, chose primordiale, 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 commune du comportement raisonnable par défaut. Ainsi, quand les problèmes surgissent, la situation peut se détériorer rapidement, les participants ne disposant pas d’un stock de réflexes culturels établis auxquels recourir pour résoudre les différends.
Cet ouvrage est un guide pratique et non une étude anthropologique ou historique. Cependant, une réelle connaissance de la culture du logiciel libre est une base essentielle pour profiter de tout conseil pratique. Une personne qui appréhende cette culture peut parcourir, en long et en large, le monde de l’Open Source, rencontrer maintes variantes locales des coutumes et des dialectes, tout en étant capable de participer partout avec aisance et efficacité. En revanche, pour qui ne la comprend pas, le processus d’organisation ou de participation à un projet sera difficile et plein de surprises. Le nombre de personnes qui développent des logiciels libres ne cessant de croître rapidement, cette dernière catégorie ne désemplit pas. C’est en grande partie une culture de nouveaux migrants, et ça continuera à l’être pendant un certain temps. Si vous pensez être l’un d’eux, la section suivante vous fournira l’arrière-plan des discussions que vous entendrez plus tard, aussi bien dans ce livre que sur Internet (d’autre part, si vous travaillez dans le monde du libre depuis un moment, vous en savez peut-être déjà pas mal sur son histoire. Dans ce cas, n’hésitez pas à sauter la prochaine section).
>>> Source sur : http://framabook.org/
