Ce livre n'est pas une recette censée mener tout droit à la réussite d'une application-qui-tue (killer app). Il entreprend une mise au point sur les pièges à éviter, la surestimation des objectifs, la mauvaise évaluation des délais, la négligence des détails (comme la documentation), ou, pire, confondre l'ouverture d'un code avec une solution de repli pour un projet déjà en perdition.
Une mise en garde ? Non. Comme l'auteur l'affirme : « La seule chose qui maintienne un groupe de développeurs ensemble est la croyance commune qu'ils peuvent faire plus collectivement qu'individuellement. » C'est ce qui nous rassemble ici aujourd'hui et, j'en suis sûr, pour longtemps encore. Il nous semblait important d'annoncer cette sortie sur un site communautaire tel que LinuxFr. Après tout, il n'y a pas que les logiciels libres qui soient développés en intégrant les volontés des uns et des autres. Les exemples ne manquent pas où les pratiques collaboratives sont plus que valorisées : des sites d'actualités, comme ici même sur LinuxFr ; le partage des connaissances comme Wikipédia (et Wikileaks, dans un autre registre) ; ou encore les Framabooks, des livres libres bâtis sur un mode de contribution libre. Pourtant, comme le dit Karl Fogel dans la première phrase de son introduction : « la plupart des projets de logiciels libres échouent ». Est-ce dû aux outils employés pour leur développement ? Certains le pensent, comme le montre ce billet de Frédéric de Villamil à propos de l'emploi de GitHub.
Néanmoins, Karl Fogel nous fait surtout partager son expérience autour du développement de Subversion, et nous montre que la réflexion dépasse le seul cadre des bonnes pratiques de rapport de bogue ou de gestion des branches et autres forks. Développer un logiciel libre relève d'une véritable stratégie de gestion des ressources humaines. En prendre conscience signifie déjà une certaine maturité dans le projet, mais quelle différence avec le développement de logiciels privateurs ? En réalité, en matière de logiciel libre, engager et gérer des bénévoles et autant de volontés individuelles implique de structurer la communauté (là où une entreprise « classique » propose déjà une structure), organiser les compétences, envisager l'impact des décisions sur un très long terme. En somme, cela ne s'improvise pas.
Retrouvez ce livre sur Framabook.org.
Un billet du Framablog fait état de cette sortie très attendue, fruit d'une collaboration entre différents membres de Framasoft et d'ailleurs.
Comme d'habitude, l'ouvrage est sous licence libre (CC-By). Vous pouvez acheter sa version papier (avec une très belle couverture) chez In Libro Veritas (lien archive.org) ou télécharger le PDF, la version HTML, les sources, le format ePub...
Aller plus loin
- Page Framabook de l'ouvrage (32 clics)
- En vente chez ILV (lien archive.org) (7 clics)
- Communiqué de presse (4 clics)
- Framasoft.net (4 clics)
- Framabook.org (6 clics)
- Producingoss.com (5 clics)
# Très bon...
Posté par rewind (Mastodon) . Évalué à 7.
Le seul reproche qu'on peut faire à ce livre, c'est sut les gestionnaires de version. Quand on lit que "CVS est le plus courant", on se retrouve presque dans les années 90. Mais il est pardonné par le fait d'avoir été écrit avant l'explosion des DVCS (git est mentionné comme un projet embryonnaire). Je pense que ça serait intéressant de refaire une analyse de ce côté là tant les choses ont changé.
# À propos des brevets logiciels
Posté par swilmet . Évalué à 3.
Voici le passage :
Les dommages causés aux logiciels libres par les brevets logiciels
sont plus insidieux que la simple menace sur le développement. Les
brevets logiciels encouragent au secret chez les développeurs de firm-
ware qui craignent, à juste titre, qu’une publication des détails de
leur interface ne fournisse une aide technique aux adversaires ne
cherchant qu’à les attaquer pour violation de brevet logiciel. Tout
ceci est loin de n’être que théorique, le secteur des cartes graphiques
en est un bon exemple. Beaucoup de fabricants de cartes graphiques
sont réticents à l’idée de publier les spécifications détaillées de leurs
programmes. Elles sont pourtant nécessaires à l’écriture de pilotes
Open Source de très bonne qualité pour leur matériel. Le support
de ces cartes par les systèmes d’exploitation libres est donc lar-
gement incomplet. Pourquoi les fabricants font-ils cela ? Pourquoi
empêcheraient-ils le support de leurs produits ? Après tout, si leurs
cartes devenaient compatibles avec davantage de systèmes d'exploi-
tation, cela se traduirait par de meilleures ventes. C’est surtout
un problème de discrétion. Dans le secret des salles de fabrication,
ces vendeurs ne cessent de violer la propriété intellectuelle de leurs
concurrents, parfois sciemment, parfois par accident. Les brevets
sont si imprévisibles, et couvrent parfois des domaines si vastes,
qu’aucun fabricant de carte ne peut jamais être sûr de ne violer
aucun brevet logiciel, même après une recherche d’antériorité. Par
conséquent, les producteurs n’osent pas publier les spécifications
complètes de leurs interfaces de peur de fournir à leurs adversaires
le bâton pour se faire battre. (Évidemment, le sujet étant sensible,
vous ne trouverez aucun témoignage écrit d’une source sûre le confir-
mant, je l’ai appris grâce à un contact personnel.)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.