« Produire du logiciel libre » enfin en français dans la collection Framabook

Posté par (page perso) . Modéré par patrick_g.
Tags :
25
29
jan.
2011
Culture
Framasoft et les équipes Framalang et Framabook sont heureux et fiers de vous annoncer la sortie d'un nouveau Framabook : Produire du logiciel libre. Il s'agit de la traduction française (enfin !) du célèbre ouvrage de Karl Fogel : Producing open source software. How to run a successful free software project (Producingoss.com).

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 ou télécharger le PDF, la version HTML, les sources, le format ePub...
  • # Très bon...

    Posté par . Évalué à 7.

    Très bon bouquin. Je ne connaissais pas l'original donc je découvrais et je me suis vraiment plongé dedans. Je peux dire qu'il est vraiment très bien fait. Certes, les vieux routiers du logiciel libre (dont font partie ceux qui traînent ici depuis un certain nombre d'années) ne trouveront rien de vraiment nouveau dedans. Mais ils auront surtout la satisfaction (comme j'ai pu l'avoir) de lire ce dont ils ont l'intuition depuis pas mal de temps à force d'observer toutes les communautés du LL.

    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 (page perso) . Évalué à 3.

    J'ai regardé la table des matières et quelques sujets m'ont intéressé, particulièrement la partie sur les brevets logiciels où j'ai appris que beaucoup de constructeurs de matériels ne fournissent pas les spécifications par peur d'être attaqués par d'autres entreprises pour des histoires de brevets.

    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.)

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.