Fiche de lecture "Produire du logiciel libre"

Je peux vous le dire par expérience, développer un logiciel libre, pour une entreprise habitué à la logique propriétaire, c'est n'est pas aussi simple que de publier des sources. Quelle licence choisir, quel est le modèle économique, comment appréhender la communauté, quels sont nos droits et nos devoirs ? Autant de questions qui sautent immédiatement à la figure. En cherchant à y répondre, des dizaines d'autres apparaissent, plus pointues, plus précises mais pas plus évidentes.

Heureusement dans le monde du logiciel libre, un des fondements est le partage. De code bien sûr, mais pas seulement. Partage d'expériences aussi.

Karl Fogel a été, de 2000 à 2006, manager de développement pour le logiciel Subversion chez CollabNet, Inc. En 2005, il publie un livre Producing Open Source Software - How to Run a Successful Free Software Project sous licence libre (CreativeCommons Attribution-ShareAlike). En 2010, Framasoft lance une traduction et la publie Produire du logiciel libre, toujours sous licence libre, en version papier chez InLibroVeritas et en téléchargement sur Framabook.

J'ai dévoré ce livre !!! Voici un résumé, chapitre par chapitre et à base d'extraits pour vous donner l'envie, vous aussi, de le lire.

 

A qui s'adresse ce livre ?

« Ce livre s'adresse aux développeurs de logiciels et aux responsables envisageant de lancer un projet Open Source, ou l'ayant déjà commencé, et qui se demandent que faire ensuite.

Nul besoin d'être programmeur, mais le lecteur devrait connaître les concepts basiques d'ingénierie logicielle tels que code source, compilateur et correctif.

Une expérience préalable du logiciel Open Source, en tant qu'utilisateur ou développeur, n'est pas nécessaire. Ceux qui ont déjà travaillé au sein d'un projet de logiciel libre trouveront certaines parties du livre évidentes et pourront les passer. Étant donné le large éventail possible d'expériences des lecteurs, j'ai essayé de nommer clairement les différentes sections et de préciser celles qui peuvent être ignorées par les familiers du sujet. »

Historique

« Le partage des logiciels est aussi ancien que les logiciels eux mêmes. Aux premiers temps des ordinateurs, les fabricants, sentant que les bénéfices économiques se trouvaient principalement dans la production de matériel, ne prêtèrent guère attention aux logiciels et leurs atouts financiers ». Les utilisateurs avaient accès aux codes sources, le modifiaient, se l'échangeaient.

« La jungle des normes matérielles a progressivement permis l'émergence de quelques lauréats grâce à une meilleure technologie, une meilleure stratégie voire la combinaison des deux. En même temps, et pas entièrement par hasard, le développement de langages de programmation dits de "haut niveau" signifiait que l'on pouvait écrire un programme une seule fois, dans un langage, et le voir automatiquement traduit (compilé) afin de fonctionner sur différents types d'ordinateurs. » La concurrence se portait alors vers les logiciels et non plus sur le matériel. C'est l'avènement du logiciel propriétaire fermé.

En 1983, Richard Stallman, ancien chercheur au MIT, lance le projet GNU et la Free Software Foundation (FSF). « En plus de travailler sur le nouveau système d'exploitation, Stallman conçut une licence dont les termes garantissent que son code restera libre à tout jamais » : La GNU General Public License (GPL) .

« Alors que le monde de l'entreprise prêtait de plus en plus attention aux logiciels libres, les programmeurs se trouvèrent confrontés à de nouveaux problèmes de représentation. L'un d'entre eux était le mot « free » lui-même. Entendant pour la première fois « free software », nombre de personnes pensaient, à tort, que cela signifiait « logiciel gratuit ». S'il est vrai que tous les logiciels libres ne coûtent rien, tous les logiciels gratuits ne sont pas libres. » ... « L'incompréhension liée au mot free était telle que les programmeurs de logiciels libres ont fini par créer une formule en réponse : « C'est free (libre) comme dans freedom (liberté), pensez à free speech (liberté de parole), pas à free beer (bière gratuite) ». »

« En 1998, le terme « Open Source » a été inventé, en tant qu'alternative à « libre », par une coalition de programmeurs devenue par la suite The Open Source Initiative (OSI). Pour l'OSI non seulement le terme « logiciel libre » était déroutant, mais le mot « libre » n'était que le symptôme d'un problème plus général : le mouvement avait besoin d'une stratégie de commercialisation pour s'adapter au monde de l'entreprise, et les discours sur les avantages moraux et sociaux du partage ne pénétreraient pas les conseils d'administration des entreprises. »

La situation actuelle

« Quand vous dirigez un projet de logiciel libre, vous n'avez pas besoin de discuter de lourds problèmes philosophiques tous les jours. Les programmeurs n'ont pas à cœur de convertir les autres participants à leurs opinions diverses (ceux qui le font se retrouvent rapidement incapables de travailler sur un projet). Mais vous devez savoir que la question "libre" contre "Open Source" existe, au moins pour éviter de dire des choses inamicales à certains des participants, mais aussi parce que comprendre les motivations des développeurs est la meilleure manière, la seule manière en un certain sens, de diriger un projet.

Le logiciel libre est une culture par choix. Pour y naviguer avec succès, vous devez comprendre pourquoi les gens ont fait le choix d'y participer en premier lieu. Les manières coercitives ne fonctionnent pas. Si les gens ne sont pas heureux au cœur d'un projet, ils vont simplement s'en écarter pour en rejoindre un autre. Le logiciel libre est remarquable, même au sein des communautés de volontaires, par la légèreté de l'investissement. La plupart des gens engagés n'ont jamais vraiment rencontrés d'autres participants face à face, et donnent simplement un peu de leur temps quand ils en ressentent l'envie. Les moyens usuels, par lesquels les humains établissent des liens entre eux et forment des groupes qui durent, sont restreints à leur plus simple expression : des mots écrits transmis par des fils électriques. À cause de cela, la formation d'un groupe soudé et dévoué peut prendre du temps. Inversement, un projet peut facilement perdre un volontaire potentiel dans les cinq premières minutes de présentation. Si un projet ne fait pas bonne impression, les nouveaux venus lui donnent rarement une seconde chance.

La brièveté, ou plutôt la brièveté potentielle, des relations est peut-être l'obstacle le plus intimidant au commencement d'un nouveau projet. Qu'est ce qui persuadera tous ces gens de rester groupés suffisamment longtemps pour produire quelque chose d'utile ? La réponse à cette question est suffisamment complexe pour être le sujet du reste de ce livre, mais si elle devait être exprimée en une seule phrase, ce serait :

"Les gens doivent sentir que leur relation à un projet, et leur influence sur celui-ci, est directement proportionnelle à leurs contributions."

Aucune catégorie de développeurs, ou de développeurs potentiels, ne devrait se sentir mise à l'écart ou être discriminée pour des raisons non-techniques. Les projets portés par une société et/ou des développeurs salariés doivent y faire particulièrement attention, le chapitre 5 aborde ce sujet plus en détail. Bien sûr, cela ne veut pas dire que, si vous ne bénéficiez pas du financement d'une société, vous n'avez à vous soucier de rien. L'argent n'est que l'un des nombreux facteurs pouvant influencer le succès d'un projet. Il y a aussi les questions de choix du langage, de la licence, du processus de développement, du type précis d'infrastructure à mettre en place, de la manière efficace de rendre publique la base du projet et bien plus encore. Commencer un projet du bon pied est le sujet du prochain chapitre. »

Bien démarrer

« La distribution du logiciel libre comporte deux facettes : elle doit trouver des utilisateurs d'une part et des développeurs de l'autre.

Ces deux besoins ne sont pas forcément antagonistes même s'ils rendent la présentation initiale du projet plus compliquée. Certaines informations sont utiles aux deux publics, d'autres le sont uniquement à l'un ou à l'autre. Les deux types d'informations devraient répondre au principe de présentation adaptée, ce qui signifie que le degré de détail présenté à chacun devrait correspondre directement à la somme de temps et d'efforts consentis par le lecteur. Un effort plus important devrait toujours être récompensé à sa juste valeur. Quand le retour sur investissement n'est pas satisfaisant, les gens peuvent rapidement perdre la foi et arrêter de s'investir.

Le corollaire en est que les apparences comptent vraiment. Les programmeurs, en particulier, sont souvent sceptiques à ce sujet. Leur amour pour le fond plutôt que pour la forme est presque une source de fierté professionnelle. Ce n'est pas un hasard si tant de programmeurs montrent de l'antipathie envers le marketing et les relations publiques, ou si les graphistes de métier sont souvent horrifiés par ce que les développeurs peuvent produire.

C'est dommage car il existe des situations - la présentation d'un projet en est une - où la forme fait partie du tout. Par exemple, l'une des premières choses que retient un visiteur à propos d'un projet est l'aspect de son site Web. Cette information est absorbée avant que le vrai contenu du site ne soit compris, avant que le texte ne soit lu ou que le visiteur ne clique sur les liens. Même si cela peut être injuste, les gens ne peuvent s'empêcher de se forger une première impression. L'apparence du site montre l'application apportée à la présentation du projet. Les humains ont des antennes très sensibles pour détecter le souci du détail. La plupart d'entre nous peuvent dire en un coup d’œil si un site Web a été assemblé à la va-vite ou s'il a été mûrement réfléchi. C'est la première information que votre projet montre et l'impression qu'elle crée pèsera, par association, sur le reste du projet. »

« Chacune des sections suivantes décrit un aspect important du commencement d'un nouveau projet. Elles sont plus ou moins présentées dans l'ordre d'apparition pour un nouveau visiteur, même si, bien sûr, votre ordonnancement peut être différent. Vous pouvez vous en servir comme d'une liste de contrôle. Quand vous commencez un projet, suivez cette liste et assurez-vous que chaque point est traité, ou au moins que vous n'aurez pas de problèmes quant aux conséquences possibles si vous décidez d'en écarter un. »

• Choisissez un bon nom : parlant, simple à mémoriser, pas de confusion lors de recherche, nom de domaine disponible
• Définissez clairement vos objectifs : « Une fois le site du projet trouvé, les gens chercheront une description rapide de sa teneur, votre déclaration d'intention, afin de pouvoir décider rapidement (dans les 30 secondes) s'ils souhaitent en savoir plus ou pas. Cette description devrait avoir une place de choix sur la première page, de préférence juste en-dessous du nom du projet. »
• Indiquez clairement que le projet est libre
• Liste des fonctionnalités et pré-requis : « si un aspect n'est pas encore finalisé, vous pouvez toujours le lister en ajoutant à côté "prévu" ou "en cours" »
• Avancement du développement : « […] une page d'avancement, listant les buts du projet à court terme et ses besoins […] La page peut également fournir un historique des versions passées avec la liste de leurs fonctionnalités. Ainsi, les visiteurs peuvent se faire une idée de l'"avancement" du projet et sa vitesse de progression […] N'ayez pas peur de paraître non-préparé et ne cédez pas à la tentation d'exagérer la progression du développement. »
• Téléchargements
• Gestion de versions et accès au système de suivi de bogues
• Les voies de communications : « Fournissez les adresses des listes de diffusion, des canaux IRC et tout autre forum où chaque personne impliquée dans le logiciel peut être jointe. Indiquez clairement que vous-même et les autres auteurs du projets sont inscrits sur ces listes de diffusion afin que les gens puissent voir qu'il existe des moyens de donner leur avis aux développeurs. Votre présence sur les listes n'implique pas que vous êtes tenu de répondre à toutes les questions ou d'intégrer toutes les suggestions. »
• Les directives pour développeurs : « Si une personne envisage de contribuer au projet, elle cherchera les directives pour développeurs. Celles-ci ne sont pas vraiment techniques mais plutôt sociales : elles expliquent comment les développeurs interagissent entre eux et avec les utilisateurs, et finalement comment les choses se déroulent. »
• Documentation : « La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment rapidement mettre le logiciel en route, une vue d'ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. […] Entretenir une FAQ […] Les bonnes FAQ ne sont pas écrites, elles se façonnent. Ce sont, par définition, des documents réactifs, évoluant avec le temps en réponse à l'usage quotidien des utilisateurs du logiciel […] La documentation devrait être disponible en deux endroits : en ligne, directement depuis le site Web, et dans la distribution téléchargeable du logiciel […] La documentation développeur est rédigée pour aider les programmeurs à comprendre le code et pouvoir le réparer et le compléter. Elle ne fait pas double emploi avec les directives pour les développeurs dont nous avons parlé précédemment, qui sont plus un outil social que technique. Ces consignes indiquent aux programmeurs comment bien collaborer entre eux, la documentation développeur leur indique comment se débrouiller avec le code lui-même. »
• Exemples de réalisations et captures d'écran
• Forges : « Quelques sites proposent un hébergement gratuit ainsi que l'infrastructure pour des projets Open Source […] En utilisant l'un de ces sites vous obtiendrez beaucoup en échange de rien. Vous tournez par contre le dos à un contrôle précis de ce que vous offrez aux utilisateurs du site. »
• Choisir une licence et l'appliquer : « Une fois la licence choisie vous devriez la faire apparaître sur la première page du projet. Vous n'avez pas besoin d'ajouter le texte de la licence à cet endroit : précisez simplement le nom de la licence et créez un lien vers le texte complet se trouvant sur une autre page […] Vous annoncez ainsi au public sous quelle licence vous comptez distribuer le projet, mais ce n'est pas légalement suffisant. Pour ceci il faut que le logiciel contienne cette licence. Habituellement, le texte complet de la licence se trouve dans un fichier nommé copie ou licence, et une petite note en début de chaque fichier source indique la date du copyright, le détenteur des droits et l'emplacement du texte complet de la licence. »
• Donner le ton : « Si le projet s'ouvre après des années de développement interne, son processus de développement s'en retrouvera modifié et vous devrez préparer les développeurs déjà présents à ce changement […] Les premiers pas sont les plus durs car les modèles et les attentes pour le futur n'ont pas encore été définis. La stabilité d'un projet n'est pas due à des règles formelles mais à une sagesse collective, difficile à définir, qui se développe avec le temps. […] Une fois le projet ouvert au public, vous et les autres fondateurs serez tentés de régler les problèmes délicats par des discussions privées au sein d'un cercle fermé. Tous les inconvénients des discussions publiques vous apparaîtront de manière palpable […] La tentation sera effectivement grande de prendre les décisions en petit comité et de les présenter comme des faits accomplis […] Ne le faites pas. Aussi encombrantes et lentes qu'elles puissent être, les discussions publiques seront toujours préférables sur le long terme. Prendre les décisions importantes en privé reviendrait à pulvériser du "repousse-bénévoles" sur le projet […] Tuez la vulgarité dans l’œuf […] Effectuez une inspection visible du code […] Si vous libérez un projet déjà existant, sur lequel les développeurs sont habitués à travailler dans un environnement fermé, assurez-vous que tout le monde comprenne qu'un grand changement se profile, essayez de vous mettre à leur place pour comprendre leurs sentiments […] Le meilleur moyen d'éviter ceci, est de tous les prévenir de ce qui les attend, expliquez, dites-leur que l'inconfort du début est parfaitement normal et assurez-les que les choses iront en s'améliorant. »
• Annoncer : « Une fois que le projet est présentable, pas parfait, juste présentable, vous êtes prêt à l'annoncer au monde entier. C'est en fait un processus très simple : allez sur freshmeat.net (NDR maintenant http://freecode.com/) , cliquez sur « Submit » (Soumettre) en haut de la barre de navigation et remplissez un formulaire pour annoncer l'existence de votre nouveau projet. C'est sur Freshmeat que tout le monde se rend pour surveiller les annonces concernant les nouveaux projets. Vous devrez attirer l'attention de quelques paires d'yeux ici pour que le bouche à oreille à propos de votre projet commence. »

 

Infrastructure technique

Ce chapitre liste et décrit les infrastructures techniques nécessaires et utiles à la gestion du projet. « Prenez garde à la tentation d'automatiser les choses qui exigent vraiment une attention humaine. L'infrastructure technique est importante, mais ce qui fait fonctionner un projet Open Source, c'est l'attention et l'expression intelligente de cette attention que les humains impliqués vont déployer. Le but principal de cette organisation est de fournir à l'utilisateur les instruments les plus adaptés pour agir. »

• Site Web : « La vitrine de votre projet aux yeux du public (centralisé et à sens unique). Le site Web peut également servir d'interface administrative à d'autres outils du projet. »
• Listes de diffusion (avec archives publiques) : « Traditionnellement le principal moyen de communication, et aussi le plus actif, au sein du projet. C'est une bonne ressource pour garder trace des discussions. »
• Contrôle de version : « Permet aux développeurs de contrôler facilement les changements apportés au code, les régressions, et de gérer les branches de développements parallèles. Il permet à chacun d'observer les modifications du code. »
• Référencement de bogues : « Permet aux développeurs d'avoir à disposition l'historique de leurs travaux, de se coordonner et de planifier les correctifs. Il Permet à chacun de connaître le statut précis des bogues, et les informations liées (par exemple, les conditions de leur reproductibilité). La même méthode peut d'ailleurs être employée pour faire le suivi, non seulement des bogues, mais également des tâches, des versions, des nouvelles fonctionnalités, etc. »
• Messagerie instantanée ou chat en temps réel : « Un endroit pour les discussions et les échanges sur un mode de questions - réponses énoncées rapidement et simplement. N'est pas toujours archivé complètement. »
• Flux RSS pour les annonces, les suivis de bug...
• Wiki éventuellement

 

Infrastructure sociale et politique

Ce chapitre explore la gestion sociale et politique du projet : qui dirige et comment, la méritocratie, la coopération...

En préalable : « L'ingrédient indispensable qui maintient les développeurs unis autour d'un projet de logiciel libre et les amène à faire, si nécessaire, des compromis est la "fourchabilité" du code, c'est-à-dire la possibilité offerte à chacun de prendre une copie du code source et de l'utiliser pour démarrer un projet concurrent, connu sous le nom de "fork" ou "fourche" en français […] Imaginez un roi dont les sujets pourraient à tout moment copier le royaume entier et emménager dans la copie du royaume pour le gouverner comme bon leur semble. Il est quasi certain que le règne d'un tel roi serait fort différent de celui dont les sujets sont contraints de rester sous sa loi quoi qu'il fasse. »

L'auteur identifie deux types de gestion sociale :

Les dictateurs bienveillants

« Bien que "dictateur bienveillant" soit le terme courant pour ce rôle, il vaut mieux l'imaginer comme un "arbitre approuvé par la communauté" ou un "juge". Généralement, les dictateurs bienveillants ne prennent pas concrètement toutes les décisions, ni même la plupart. Il est peu probable qu'une seule personne puisse avoir les compétences requises dans tous les domaines d'un projet et, de toutes façons, les bons développeurs ne s'éterniseront pas s'ils n'ont pas quelque influence sur la direction du projet. C'est pourquoi les dictateurs bienveillants ne dictent généralement pas grand-chose. En revanche, ils laissent les choses s'éclaircir d'elles-mêmes au cours de la discussion et de l'expérimentation, quand c'est possible. Ils y participent eux-mêmes, mais en tant que simples développeurs, s'en remettent souvent à un responsable du domaine ayant plus de savoir faire. C'est seulement quand il apparaît clairement qu'un consensus ne peut être trouvé et que la majorité veut que quelqu'un prenne une décision afin que le développement puisse continuer, qu'il tape du poing sur la table en disant : "Voilà ce qu'il faut faire." »

La démocratie basée sur le consensus

« En vieillissant, les projets tendent à s'éloigner du modèle du dictateur bienveillant au profit de systèmes plus ouvertement démocratiques. »

« Quand le consensus n'est pas possible, votez […] Le plus difficile, en ce qui concerne le vote, est de déterminer quand il doit avoir lieu […] Un système de vote c'est bien, mais qui a le droit de vote ? C'est là une question potentiellement sensible, car elle oblige le projet à distinguer certaines personnes selon leur implication ou leur jugement. La meilleure solution consiste à utiliser une distinction existante, comme l'accès à la validation ("accès de commit"), et à y attacher les privilèges du vote »

« Arrivé à un certain point, le nombre de conventions et d'accords tacites entourant votre projet risque de devenir si important qu'il deviendra nécessaire de les consigner quelque part »

L'argent

Ce chapitre aborde la question du financement d'un projet de logiciel libre. Il ne concerne pas uniquement les développeurs payés pour travailler sur des projets de logiciel libre, mais aussi leurs responsables, qui doivent comprendre les règles sociales régissant le cadre du développement.

« Si vous dirigez des programmeurs dans un projet Open Source, faites en sorte qu'ils participent au projet assez longtemps pour acquérir l'expertise technique et politique nécessaire, deux ans au minimum […] La crédibilité acquise ne peut être transférée »

« Vos développeurs feront leur possible pour s'exprimer, sur les forums publics de développement, en tant que participants individuels plutôt que comme représentants d'une entreprise monolithique. Ce n'est pas que la présence massive d'une entreprise ait une connotation négative (enfin, c'est possible, mais ce n'est pas le sujet de ce livre). C'est plutôt parce que les projets Open Source ne sont structurellement équipés que pour traiter avec des entités individuelles. »

« Annoncez les buts de votre organisation en toute transparence, sans révéler de secrets commerciaux. Si vous voulez que le projet incorpore une certaine fonctionnalité parce que, par exemple, vos clients la réclament à cor et à cri, annoncez-le clairement sur les listes de diffusion. Si les clients souhaitent rester anonymes, comme c'est parfois le cas, demandez-leur au moins si vous pouvez les citer comme exemples sans les nommer. Les développeurs accepteront d'autant mieux vos propositions qu'ils en connaîtront les raisons. »

« Mais la programmation n'est la seule activité au sein d'un projet Open Source, loin s'en faut. Du point de vue des volontaires du projet, c'est la partie la plus visible et la plus glamour. Ce qui veut malheureusement dire que les autres activités, comme la documentation ou les tests formels par exemple, peuvent parfois être négligés, comparés à l'attention qu'ils reçoivent dans les logiciels propriétaires en tout cas. Les entreprises arrivent parfois à compenser cette lacune en assignant une partie de leur infrastructure de développement de logiciel interne à des projets Open Source. » Ce conseil s'applique aux tests, au côté juridique, à la documentation, l'hébergement...

« Afin de conserver la communauté de développeurs bénévoles de votre côté, il est très important de ne rien dire qui ne soit vérifiable. Contrôlez scrupuleusement toutes vos affirmations et donnez au public les moyens de les vérifier de son côté. La vérification indépendante et rapide compose une grande partie du domaine de l'Open Source et cela s'applique au-delà du code. »

« Abstenez-vous de critiquer les logiciels Open Source concurrents. Vous pouvez tout à fait exposer des faits négatifs, c'est-à-dire des affirmations facilement vérifiables, comme c'est souvent le cas dans les bons tableaux comparatifs. Mais il y a deux raisons pour lesquelles il vaut mieux éviter toute légèreté lorsqu'on diffuse des critiques négatives. Premièrement, elles sont susceptibles d'initier une guerre malsaine qui éloigne des discussions productives. Et surtout, deuxièmement, il se peut que certains développeurs volontaires de votre projet travaillent également sur le projet concurrent. »

Communication

« La capacité à écrire avec clarté est peut-être la qualité la plus importante que l'on puisse avoir dans un environnement Open Source. Sur le long terme, elle compte davantage que les compétences en programmation. S'il a des difficultés à communiquer, un programmeur aura beau être génial, il ne pourra s'occuper que d'une chose à la fois, et il n'est même pas certain d'obtenir l'attention désirée. »

« C'est un fait : sur Internet on ne vous connaît qu'au travers de vos écrits ou de ce que l'on écrit sur vous. »

« Après avoir écrit des milliers de messages, vous observerez sûrement une simplification de votre style. Cela semble être la norme dans la plupart des forums techniques, et intrinsèquement, il n'y a rien de mal à cela. Un degré de simplification inacceptable pour des interactions sociales habituelles est simplement la norme des hackers de logiciels libres. »

« Quand vous participez à un projet en ligne vous serez tenté de répondre à tout, c'est l'un des pièges classiques. Ne le faites pas. Tout d'abord, il risque d'y avoir plus de fils de discussions que vous ne pouvez en suivre, en tout cas une fois que le projet se sera développé. »

« Dans une liste de discussion animée, il y a deux impératifs. Le premier, évidemment, consiste à distinguer ce qui mérite votre attention de ce que vous pouvez ignorer. L'autre consiste à agir de manière à ne pas créer de bruit : vous voulez non seulement que vos propres messages soient pertinents, mais aussi qu'ils incitent les autres à en poster d'aussi pertinents ou bien à s'abstenir. »

« La probabilité de dérive n'est nulle pour aucun fil, mais les sujets techniques simples sont un terreau très propice à l'égarement. Après tout, les sujets techniquement complexes ne seront bien compris que par une faible proportion de participants, certainement les développeurs les plus expérimentés ayant déjà pris part à ce genre de discussions des milliers de fois, et qui savent comment aboutir à un consensus viable pour tous. »

« Éviter les trolls »

« Traditionnellement, toutes les communications échangées dans un projet Open Source (exceptées parfois les conversations IRC) sont archivées. Les archives sont publiques, consultables et ont une stabilité référentielle : c'est-à-dire qu'une information enregistrée a une adresse donnée où elle reste pour toujours. Utilisez ces archives autant que possible et aussi visiblement que possible. Même si vous connaissez par coeur la réponse à une question, si vous pensez qu'il y a dans les archives une référence qui contient la réponse, prenez le temps d'aller la chercher et de la montrer. Chaque fois que vous faites ceci publiquement et de manière visible, quelqu'un apprend pour la première fois que les archives sont là et qu'elles contiennent des réponses aux questions. »

« Pas de discussion dans le système de suivi de bogues »

Faille de sécurité

Une partie très riche en exemples.

« La gestion d'une faille de sécurité est différente de la gestion des autres rapports de bogue. Dans le logiciel libre, tout faire de manière ouverte et transparente relève presque du sacerdoce. Chaque étape d'une correction de bogue standard est visible aux yeux de tous ceux que cela intéresse : l'envoi du rapport initial, la discussion qui s'ensuit et le correctif. »

« Ne pas parler du bogue en public tant qu'il n'y a pas de correctif disponible, fournir le correctif exactement au même moment où vous annoncez le bogue. Concocter un correctif aussi rapidement que possible, surtout si c'est quelqu'un d'étranger au projet qui a rapporté le bogue, parce qu'alors vous savez qu'au moins une personne en dehors du projet est capable d'exploiter la vulnérabilité. »

Paquets, sorties et développement quotidien

Un chapitre très technique sur la numérotation des versions, l'utilisation des branches de publication, le format de livraison, le changelog, la maintenance de plusieurs versions, la planification des publications

Est évoqué également le processus de décision sur ce qui est inclus dans une version.

 

Encadrer les volontaires

Comme son titre l'indique ce chapitre fait le tour de la question de l'encadrement des volontaires :

• délégation
• félicitations et critiques
• partage des taches
• choix des commiters
• responsabilisation (correctif, traduction, documentation, FAQ)
• gestion d'un fork

 

Licences, droits d'auteur et brevets

Ce chapitre commence par un glossaire des termes suivants :

• Logiciel libre
• Logiciel Open Source
• Conforme au DFSG - Conforme au contrat social Debian
• Approuvé OSI - Approuvé par l'Open Source Initiative
• Propriétaire, source fermée
• Domaine public
• Copyleft

Il explique ensuite les différents aspects différenciant les licences :

• Compatibilité avec les licences propriétaires
• Compatibilité avec d'autres licences libres
• L'obligation de crédit
• La protection de marques déposées
• La protection de l'"intégrité artistique"

GPL

« Les licences peuvent être regroupées en deux grandes catégories selon qu'elles sont ou non compatibles avec les licences propriétaires.

On distingue donc la Licence Publique Générale GNU de toutes les autres licences. Parce que l'objectif premier des auteurs de la GPL est la promotion du logiciel libre, ils créèrent délibérément la licence de façon à ce qu'il soit impossible d'intégrer du code sous GPL au sein de programmes propriétaires. En particulier, parmi les conditions de la GPL, on retrouve ces deux dispositions :

• Tout logiciel dérivé, tout logiciel contenant une quantité significative de code sous GPL doit être distribué lui-même sous GPL.
• Aucune restriction additionnelle ne peut être placée sur la redistribution du logiciel original ou dérivé.

Avec ces conditions, la GPL parvient à fabriquer une liberté contagieuse. Une fois qu'un programme est licencié sous GPL, ses termes de redistribution sont viraux, ils se transmettent à tout autre contenu intégrant ce code. L'emploi de code sous GPL dans un programme fermé est donc strictement impossible. Cependant, ces mêmes clauses rendent aussi la GPL incompatible avec certaines autres licences libres. C'est typiquement le cas des licences imposant une exigence supplémentaire comme, par exemple, une clause de crédit. L'incompatibilité avec la GPL est flagrante puisque cette dernière stipule que "Vous ne pouvez pas imposer de nouvelles restrictions.". Du point de vue de la Free Software Foundation, ces effets secondaires sont recherchés, ou en tout cas, ils ne sont pas regrettables. Non seulement la GPL assure la liberté de votre logiciel, mais elle en fait aussi un agent poussant les autres logiciels à devenir libres. »

La GNU Affero GPL : une version de la GNU GPL pour le code côté serveur: En 2007, la Free Software Foundation a publié une variante de la GPL appelée GNU Affero GPL*. Elle a été créée pour appliquer les mêmes clauses de partage introduites par la GPL aux entreprises, de plus en plus nombreuses, qui proposent des services distants, des logiciels qui fonctionnent sur leurs serveurs, des logiciels avec lesquels les utilisateurs n'interagissent qu'en ligne et qui ne sont donc jamais distribués aux utilisateurs sous forme de code source ou d'exécutable. Un grand nombre de ces services employaient des logiciels sous GPL, souvent après y avoir apporté des modifications, et pourtant ils n'avaient pas à partager ces modifications puisque le code n'était pas distribué. La parade de la licence GNU AGPLv3 consiste donc simplement à ajouter à la GPL classique une clause pour les "Interactions à distance" indiquant que "… si vous modifiez le Programme, votre version modifiée doit offrir de manière visible à tous les utilisateurs interagissant à distance grâce à un réseau informatique… la possibilité de recevoir la Source Correspondante de votre version… gratuitement, grâce aux méthodes standard ou habituelles de copies de logiciel". Les règles établies par la GPL sont ainsi applicables dans le nouveau monde de la fourniture de services d'applications. »

Attribution des droits d'auteur et propriété

« La gestion des droits d'auteur sur un code libre, fruit du travail de plusieurs personnes, est une question qu'il vous faudra résoudre. Trois options s'offrent à vous. La première consiste à purement et simplement ignorer le problème du droit d'auteur (je vous le déconseille). La deuxième est de demander un Accord de Licence du Participant (ALP) à chaque personne travaillant sur le projet, accordant explicitement au projet le droit d'utiliser le code du participant. C'est en général suffisant pour la plupart des projets, le point positif étant que dans certaines juridictions ces ALP peuvent être envoyés par courrier électronique. La troisième possibilité est d'obtenir des participants l'attribution complète des droits d'auteur afin que le projet (c'est-à-dire une personne morale, généralement à but non lucratif) concentre tous les droits d'auteur. C'est la voie la plus sûre légalement, mais aussi la plus contraignante pour les participants, seuls quelques projets l'empruntent.

Notez que même si la propriété intellectuelle est centralisée, le code demeure libre car les licences Open Source ne donnent pas au détenteur des droits la possibilité de rendre rétroactivement propriétaires toutes les copies de ce code. Donc, même si le projet, en tant que personne morale, retourne soudainement sa veste, et décide de distribuer le code sous une licence plus restrictive, cela ne posera pas de problème à la communauté. Les autres développeurs n'auraient qu'à initier une fourche basée sur la dernière version libre du code, et continuer comme si de rien n'était. Cette possibilité existant, la plupart des participants coopèrent lorsqu'on leur demande de signer un ALP ou une attribution de droit d'auteur. »

Quelques exemples d'ALP :

ALP pour les participants individuels :

• http://apache.org/licenses/icla.txt
• http://code.google.com/legal/individual-cla-v1.0.html

ALP pour les entreprises participantes :

• http://apache.org/licenses/cla-corporate.txt
• http://code.google.com/legal/corporate-cla-v1.0.html

La double licence

« Certains projets tentent de s'auto-financer en adoptant une double licence, c'est un système par lequel toute société peut payer le détenteur des droits d'auteur et obtenir son accord pour utiliser le code dans un programme propriétaire, le code restant libre pour les projets Open Source. Les librairies de code se prêtent évidemment mieux à cette double licence que des applications autonomes. Les termes exacts varient d'un cas à l'autre. La licence pour l'aspect libre est la GNU GPL, puisqu'elle empêche déjà n'importe qui d'ajouter le code protégé dans un produit propriétaire sans l'autorisation du détenteur des droits, parfois, c'est une licence personnalisée ayant les mêmes effets. Ainsi la licence MySQL utilise la licence GNU GPL, on peut aussi citer comme exemple de licence personnalisée le système de licence de Sleepycat Software.

Vous vous demandez sûrement comment le détenteur des droits peut proposer une licence propriétaire contre rémunération si les termes de la GNU GPL stipulent que le code doit être mis à disposition sous des conditions moins restrictives. Les termes de la GPL sont imposés par le détenteur des droits à tout le monde sauf aux logiciels propriétaires, l'auteur est libre de décider de ne pas s'imposer les mêmes termes. Imaginez que le détenteur des droits possède un nombre infini de copies du logiciel rangées dans un seau, à chaque fois qu'il sort une copie du seau pour la donner au monde, il peut décider quelle licence appliquer : GPL, propriétaire ou autre. Ce n'est pas la GPL ou une quelconque autre licence Open Source qui lui donne ce droit, ce sont les lois du droit d'auteur.

Dans le meilleur des cas, la double licence permet ainsi au projet de logiciel libre de s'assurer une source de revenus stable. Malheureusement, la dynamique normale d'un projet Open Source peut s'en retrouver altérée. Le problème est que chaque volontaire apportant sa contribution au code participe maintenant aux deux entités : la fois à la version libre et à la version propriétaire du code. Contribuer à la version libre ne lui posera certainement pas problème, c'est la norme dans les projets Open Source, mais par contre, participer à la création de revenus semi-propriétaires au bénéfice de tiers lui conviendra peut-être moins. C'est d'autant plus vrai que, pour une double licence, les participants doivent céder leurs droits au projet par une déclaration écrite. Le projet doit se couvrir au cas où un participant mécontent prétendrait à un pourcentage sur les revenus propriétaires. À partir du moment où les participants signent cette attribution des droits, ils ne peuvent plus ignorer que leur production enrichira une autre personne.

Tous les volontaires ne se soucieront pas de cela, après tout, leur contribution participe également au développement de l'édition Open Source, et c'est bien là leur intérêt. Néanmoins, la double licence est un exemple où le propriétaire des droits d'auteur se donne à lui-même un droit particulier que les autres personnes du projet n'ont pas, ce qui conduira tôt ou tard à des tensions, du moins avec quelques volontaires.

En pratique, il semble que les entreprises développant des logiciels à double licence n'ont pas une communauté de développement vraiment égalitaire. Ils profitent de correctifs de bogues mineurs ou de petits travaux de bénévoles, mais font le gros du travail en interne. Par exemple, Zack Urlocker, vice président du marketing chez MySQL, m'a confié que l'entreprise finit souvent pas employer les volontaires les plus actifs de toute façon. Ainsi, le produit en lui même est Open Source, sous licence GPL. Son développement est plus ou moins contrôlé par une entreprise, même si la possibilité d'initier une fourche en cas de profond désaccord existe (elle reste extrêmement faible cependant). Je ne sais pas comment cette menace affecte la politique de l'entreprise, mais en tout cas, MySQL ne semble pas avoir de problème d'acceptation, que ce soit dans le monde de l'Open Source ou ailleurs. »