Y aurait-il moins de 5000 développeurs libres sur tout le continent africain (4527 pour être plus précis) ?

C’est ce qu’on peut lire sur cette intéressante carte interactive intitulée GitHub Africa Users. Leur auteurs (non africains) ont en effet collecté, en mars dernier, les données des utilisateurs de la plateforme qui avaient renseigné leur localisation (et uniquement ceux-ci) en nous présentant cela à l’aide de MapBox.

A partir de là un certain nombre de questions se posent pour nuancer ce chiffre :

• Est-ce les utilisateurs africains de GitHub se localisent moins que les autres ?
• Est-ce qu’un utilisateur de GitHub est nécessairement un développeur qui fait du libre ?
• Est-ce que les développeurs libres africains utilisent GitHub ?
• Est-ce que les développeurs libres africains voudraient utiliser GitHub mais en sont empêchés à cause de la faiblesse de leur connexion à Internet ?
• Combien y a-t-il de développeurs non libres en Afrique ?

Il n’empêche que cela reste tout de même inquiétant.

Qu’en pensez-vous ?

Le témoignage d’un développeur qui considère qu’à partir du moment où vous vivez bien il est moralement important de rendre à la communauté un peu de ce qu’elle vous a donnée.

L’open source, une responsabilité civique

Open Source as a Civic Duty

Jeremy Kahn – 13 juillet 2013 – Blog personnel
(Traduction : Asta, r0u, aKa, GregR, regularuser, Tentate, dig, Fol, Maijin + anonymes)

On me demande parfois la raison pour laquelle je passe autant de mon temps libre à écrire des logiciels et à les mettre à disposition librement et gratuitement. Il y a un certain nombre de raisons à cela. J’aime construire des choses et cela me sert de prétexte pour pratiquer et m’améliorer, mais une de mes principales motivations est que je vois dans les contributions open source un devoir civique, une obligation morale envers le reste du monde.

Étant donné que je suis un programmeur actif travaillant dans la Silicon Valley, et qu’on me considère généralement comme pas trop incompétent, vous vous doutez bien que je ne me soucie pas trop de comment j’arriverai à payer mon prochain repas. Je ne suis pas « riche », mais j’ai un style de vie plutôt confortable, et c’est tout ce que j’ai toujours voulu. Après tout, un programmeur a-t-il besoin d’autre chose qu’un ordinateur portable et d’une tasse de café pour être heureux ? Ceci étant, je n’ai pas à m’inquiéter de savoir si je vais avoir, ou non, un endroit pour vivre et à manger le mois prochain, je suis parmi les gens les plus heureux du monde. Et si vous avez toute la technologie nécessaire à la lecture de cet article, vous l’êtes sûrement tout autant.

La morale est un sujet sensible qui dépend des individus et de leurs cultures, et ce texte ne suggère pas que ma conception de la moralité soit nécessairement correcte. Cependant, je pense que les gens assez chanceux pour parvenir à vivre par leurs propres moyens ont une obligation de rendre quelque chose à leur communauté. Je crois qu’un certain niveau de sacrifice personnel et de devoir civique est nécessaire afin de bâtir et de maintenir un collectif au sein duquel nous souhaitons tous vivre. Cela peut prendre plusieurs formes, des dons, du travail bénévole ou, dans mon cas, la conception et le développement de logiciels libres. La manière dont vous tentez de contribuer à la communauté n’est pas vraiment importante, ce qui compte est que vous le fassiez.

Bien sûr, je ne code pas des logiciels qui permettront de fournir de l’eau à des pays pauvres en Afrique ou à soigner la malaria. Je me focalise plutôt sur des outils d’animations pour le Web et d’autres utilitaires pour les interfaces utilisateurs. Cependant, je travaille dessus afin que d’autres n’aient pas à le faire. Mon but à mon niveau est de faire gagner du temps à d’autres personnes, et leur permettre de résoudre des problèmes qui n’ont pas encore de solutions. Pour prendre un exemple significatif, considérons le projet GNU. Au final, GNU a permis de faire gagner à l’humanité des siècles en temps de travail. De nos jours, on ne passe plus beaucoup de temps à développer des systèmes d’exploitation et autres outils basiques, car c’est une tâche quasiment résolue. À la place nous utilisons des outils GNU que d’autres ont laborieusement développé, nous permettant alors ainsi de poursuivre et nous concentrer vers d’autres défis comme la modélisation statistique ou la lutte contre le SIDA. Si vous avez des doutes sur l’intérêt du logiciel libre, il vous suffit de regarder le projet GNU.

L’altruisme n’est malheureusement pas très répandu dans la Silicon Valley. Au mieux, les grandes firmes ont une division s’occupant de responsabilité sociale et environnementale, et les plus petites organisent une collecte de fonds à but solidaire de temps en temps. Mais il semble qu’une grande partie des entreprises technologiques de la Silicon Valley se concentrent sur une vision autocentrée et des problèmes « de niche », spécifiques à leur fondateur et à ses amis. Je ne veux pas d’une culture dans laquelle les seuls problèmes résolus sont ceux que les techniciens rencontrent. Je pense que l’écriture de logiciels libres sur mon temps personnel est un petit pas dans la bonne direction, même indirect. Mon rêve est qu’un jour, un outil libre que j’aurai écrit soit utilisé à des fins vraiment utiles. N’importe qui peut accomplir cela, ça ne requiert que peu de temps ou d’argent — seulement de prendre un peu de recul.

Crédit photo : David Orban (Creative Commons By)

Bonjour Céline, peux-tu nous expliquer comment tu en es venue à utiliser le système d’exploitation Free BSD ? Tu l’as attrapé tout d’un coup ou bien c’est l’effet d’une lente incubation ?

Je suis arrivée sur FreeBSD un peu par hasard. En fait, quand j’ai décidé de passer à Linux (en 1999, je sais ça remonte), j’ai testé plusieurs distributions dont La Lycoris Desktop LX, Debian et Ubuntu 6.06. J’ai utilisé Ubuntu et Debian en parallèle pendant énormément de temps jusqu’à ce que je décide de tester OpenBSD (réputé pour sa sécurité) pour l’utiliser sur un serveur de développement. À cause de l’absence de Java et comme je suis développeuse C/Java, j’ai éprouvé de la frustration de ne pas pouvoir tout faire sur ma machine nouvellement acquise. J’ai donc cherché une alternative la plus proche possible : FreeBSD s’est avéré être mon choix final. Une installation sans fioriture, simple et qui n’installait que ce dont j’avais besoin sur mon serveur (seul ArchLinux m’avait satisfaite au même degré jusque-là), je ne demandais rien de plus. Donc pour en revenir à l’usage de ce système d’exploitation, c’est bien l’effet d’une incubation d’une bonne dizaine d’années.

Bon c’est bien joli FreeBSD mais son installation et son usage réclament un certain niveau de compétence technique, non ? est-ce que tu le conseillerais vraiment à des usagers qui comme moi choisissent Ubuntu parce que c’est la distribution la plus abordable ? Il n’existe pas une version plus simple avec une interface graphique qui simplifie la vie ?

C’est vrai que quand on arrive sur FreeBSD, il ne faut pas avoir peur de la console. C’est pareil pour certaines distributions Linux, il faut s’armer de patience, lire la documentation (très bien réalisée) et parfois galérer dans les pages man. L’installation ne se fait pas en quelques clics, une fois l’installation finie, on ne dispose vraiment que des outils de base. Mais c’est ce que j’adore sur OpenBSD et FreeBSD (bon et aussi ArchLinux), c’est que je sais ce qu’il y a sur mon poste, ce qui démarre quand j’allume mon ordinateur, alors qu’au fil de temps je trouve que le fonctionnement des distributions Linux, pour se rendre facile d’accès au grand public, devient de plus en plus opaque. Il suffit de taper un petit ps aux sur Ubuntu pour voir tout ce qui peut tourner (des fois pour rien)… Pour ce qui est d’une version plus facile d’accès, j’ai entendu parler de PC-BSD qui a justement pour objectif de rendre FreeBSD accessible à tous : installation aisée en quelques clics, KDE est fourni en bureau par défaut… Je testerai peut-être un jour sur un autre PC ou avec VirtualBox 😉

Tu en fais un usage dans ta vie professionnelle ou bien c’est choix de passionnée pour ton usage personnel ?

Dans ma vie professionnelle, je travaille sur RedHat, Debian et Solaris, hélas pas encore de FreeBSD en vue, mais ça viendra ! 😉

Merci, je te laisse le soin de présenter l’article…

Il y a de cela 20 ans, le 19 juin 1993, David Greenman, Jordan Hubbard et Rod Grimes annonçaient la création d’un nouveau logiciel basé sur le code source de BSD (Berkeley Software Distribution, voyez cette page Wikipédia) : FreeBSD était né. Peu connu du grand public, ce système d’exploitation est pourtant utilisé partout : en tant que solution d’hébergement pour des sociétés telles que Yahoo!, ou comme solution de sécurité pour la mise en place de firewall. Deux systèmes d’exploitation reposent sur son noyau : FreeNAS et MacOS. FreeNAS est une solution libre grand public pour héberger du contenu à travers un réseau, tandis que MacOS est le système d’exploitation propriétaire que nous connaissons tous au moins de nom. Pour fêter ce cap des 20 ans, voici un petit article qui vous fera découvrir une partie du monde BSD.

— Céline

FreeBSD fête ses 20 ans et met toute sa puissance à votre service.

Traduction Framalang : lamessen, Céline, Garburst, Asta, audionuma d’après l’article original de Lawrence Latif

Le système d’exploitation open source FreeBSD vient de fêter son vingtième anniversaire.

FreeBSD a vu au fil des années sa popularité auprès du grand public diminuer alors que le noyau Linux et les nombreuses distributions qui l’utilisent ont connu un développement rapide. Cependant, FreeBSD a eu 20 ans le 19 juin et continue de faire fonctionner des infrastructures réseaux vitales.

FreeBSD a introduit de nombreuses innovations qui ont été adoptées par certaines distributions Linux. Par exemple, la collection de ports FreeBSD, qui compile des logiciels à partir du code source plutôt qu’à partir de binaires pré-assemblés, a été copiée par Gentoo Linux pour son système Portage.

FreeBSD est également connu pour avoir l’une des piles réseau les plus robustes. Il est fréquemment utilisé par les chercheurs et les industriels comme base pour la simulation et les systèmes de production. Monowall et Pfsense sont des distributions populaires basées sur FreeBSD destinées à être utilisées sur des périphériques réseaux qui embarquent tous les types de fonctionnalités, des firewalls aux réseaux privés virtuels en passant par les liaisons ADSL, sur un système facile à utiliser.

Alors que FreeBSD n’est pas la seule variante libre et largement distribuée de BSD Unix, il est différent de OpenBSD qui essaie d’être le système d’exploitation le plus sécurisé et de NetBSD qui tente de fonctionner sur n’importe quel appareil possédant un microprocesseur. Il est devenu la référence pour une utilisation générale de BSD.

Cependant, FreeBSD n’est pas que réseau et démons, puisque durant ces dernières années les distributions de bureau BSD Unix reposant sur FreeBSD sont apparues, notamment avec PC-BSD qui est la plus célèbre.

FreeBSD, grâce à ses performances et sa licence, est utilisé par des sociétés commerciales comme Citrix, Netapp et Juniper.

Ces dernières années, même la communauté Linux a commencé à reprendre des parties de FreeBSD, avec Debian qui propose une version de sa distribution utilisant le kernel FreeBSD. Malgré la blague récurrente sur le fait que BSD soit mort ou non, étant donné son support à l’industrie, il est probable qu’il continuera son combat dans les décennies à venir.

Qu’il s’agisse de son code ou de son utilisation, la faiblesse de la documentation d’un logiciel libre est souvent montrée du doigt.

Voici, selon Andy Lester, 13 défauts ou lacunes communément rencontrés, qui sont autant d’écueils que l’on peut contourner avec un minimum d’efforts aujourd’hui pour gagner demain un temps précieux.

13 choses que les gens détestent sur vos documentations open source

13 Things People Hate about Your Open Source Docs

Andy Lester – 10 janvier 2013 – SmartBear Blog
(Traduction : Lamessen, calou, Shanx, sinma, Asta + anonymes)

La plupart des développeurs open source aiment penser à la qualité du logiciel qu’ils développent, mais la qualité de la documentation est souvent laissée de côté. Il est rare de voir vanter la documentation d’un projet, et pourtant elle a un impact direct sur sa réussite. Sans une bonne documentation, les utilisateurs n’utiliseront pas votre projet, ou ils n’y prendront pas de plaisir. Les utilisateurs comblés sont ceux qui diffusent des infos à propos de votre projet – ce qu’ils ne font qu’après avoir compris comment il fonctionne. Et ils apprennent cela à partir de la documentation du projet.

Malgré tout, de trop nombreux projets ont une documentation décevante. Et cela peut être décevant de plusieurs manières.

Les exemples que je donne ci-dessous sont purement arbitraires, je ne veux pas cibler un projet en particulier. Ce sont seulement ceux que j’ai utilisés récemment, cela ne veut pas dire qu’ils représentent les pires atrocités. Chaque projet a commis au moins quelques-uns de ces péchés. Que vous soyez utilisateur ou développeur, à vous d’évaluer à quel point votre logiciel préféré est ou non coupable, et comment vous pouvez aider à y remédier le cas échéant.

1. Le manque d’une bonne introduction ou d’un README/LISEZ-MOI

Le README/LISEZ-MOI est la première impression que les utilisateurs potentiels ont de votre projet. Si le projet est sur GitHub, le README/LISEZ-MOI est automatiquement affiché sur la page d’accueil du projet. Si vous l’avez mal rédigé, ils peuvent ne jamais revenir.

Vous voulez capter l’attention du lecteur et l’encourager à continuer la découverte de votre projet ? Le README/LISEZ-MOI devrait alors au moins expliquer :

• ce que le projet fait
• pour qui il est fait
• sur quel matériel ou plateforme il tourne
• toutes les dépendances majeures, comme « Requiert Python 2.6 et libxml »
• comment l’installer, ou un accompagnement de chaque étape à la suivante.

Tout cela doit pouvoir être compris par quelqu’un qui n’a jamais entendu parler de votre projet, et peut-être même jamais imaginé un projet pouvant s’en rapprocher. Si le projet possède un module calculant la distance de Levenshtein, ne partez pas du principe que n’importe qui lisant votre README/LISEZ-MOI sait ce que c’est. Expliquez que la distance de Levenshtein est utilisée pour comparer deux chaînes de caractères, et ajoutez quelques renvois vers des explications plus poussées pour celui qui aimerait approfondir le sujet.

Ne décrivez pas votre projet par rapport à un autre projet, comme « NumberDoodle est comme BongoCalc, mais meilleur ! » Ça n’est d’aucune aide pour quelqu’un qui n’a jamais entendu parlé de BongoCalc.

2. La documentation non disponible en ligne

Bien que je n’ai pas lu d’études à ce sujet, je serais prêt à parier que 90% des recherches de documentation sont faites avec Google et un navigateur sur Internet. La documentation de votre projet doit être en ligne, et disponible. Partant de là, il serait embarrassant que la documentation de mon propre projet, ack, ne soit pas disponible à l’endroit où la majorité des gens vont la chercher. Mon hypothèse est basée sur ma propre expérience, à savoir que si je veux connaître le fonctionnement d’un outil en ligne de commande, je vais vérifier sa page man.

Comment je m’en suis aperçu ? Les utilisateurs m’écrivaient pour me poser des questions dont les réponses se trouvaient dans la FAQ. Ce qui m’a ennuyé : ils ne lisaient pas ma FAQ. Il se trouve qu’ils avaient cherché sur le site internet, mais je n’avais pas mis la FAQ à cet endroit. C’est une erreur facile à faire. Je suis proche du projet et je n’ai jamais eu besoin d’utiliser moi-même la FAQ, je n’avais donc pas remarqué qu’elle n’était pas présente en ligne. Beaucoup de problèmes sont dus à ce piège : les auteurs ne se mettent pas à la place des utilisateurs.

3. La documentation disponible uniquement en ligne

Le revers de ce problème est d’avoir la documentation disponible uniquement en ligne. Certains projets ne distribuent pas la documentation avec les livrables du projet, ou incluent une version médiocre de la documentation.

Le moteur de recherche Solr, par exemple, a un excellent wiki qui sert à la documentation du projet. Malheureusement, la documentation liée au téléchargement comporte 2200 pages de Javadoc d’API auto-générées. Au final, la seule documentation pour l’utilisateur est une unique page de tutoriel.

Le langage PHP n’est distribué avec aucune documentation. Si vous voulez la documentation, vous devez aller sur une page séparée pour les obtenir. Pire, seule la documentation du cœur est disponible au téléchargement, sans les annotations utiles des utilisateurs (voir « Ne pas accepter les remarques des utilisateurs » plus bas), et ce n’est pas le même format facile à parcourir que celui qui est disponible en ligne.

Les projets open source ne peuvent pas supposer que les utilisateurs ont accès à Internet quand ils ont besoin de la documentation. Le mode avion existe toujours. De toute façon, vous ne souhaitez pas que l’utilisateur dépende uniquement du fait que votre site web est disponible ou non. Au moins à deux reprises durant les derniers mois, le wiki de Solr était indisponible au beau milieu de ma journée de travail alors que je recherchais des informations sur un problème de configuration épineux.

Un projet qui fait les choses bien est Perl et son dépôt de module CPAN. La documentation pour chaque module est disponible soit à search.cpan.org ou metacpan.org dans un format hypertexte facile à lire. Pour la consultation hors-ligne, la documentation de chaque module est intégrée dans le code lui-même, et quand le module est installé sur le système d’un utilisateur, la documentation locale est créée sous forme de pages man. Les utilisateurs peuvent aussi utiliser « perldoc Module::Name » pour obtenir la documentation depuis le shell. En ligne ou hors-ligne : c’est votre choix.

4. La documentation non installée avec le paquet

Ce problème est généralement une erreur des paquageurs, pas des auteurs du projet. Par exemple, sur Ubuntu Linux, la documentation du langage Perl est séparée, ce sont des paquets optionnels pour le langage lui-même. L’utilisateur doit savoir qu’il doit explicitement installer la documentation de la même façon que le langage principal ou il n’y aura pas accès quand il en aura besoin. Ce compromis de quelques mégabites d’espace disque au détriment de la documentation à portée de main de l’utilisateur dessert tout le monde.

5. Le manque de captures d’écran

Il n’y a pas de meilleur moyen d’obtenir l’attention potentielle d’un utilisateur, ou d’illustrer un usage correct, qu’avec des captures d’écran judicieuses. Une image vaut mieux qu’un long discours, c’est encore plus important sur Internet parce que vous ne pouvez obtenir d’un lecteur de lire plus de quelques centaines de mots en tout.

Les captures d’écran accompagnant le texte sont inestimables pour guider l’utilisateur voulant faire les choses au mieux. Une capture d’écran lui permet de comparer visuellement ses résultats à ceux de la documentation et va le rassurer d’avoir exécutée la tâche correctement ou l’aidera à trouver facilement ce qui ne va pas.

Il est de plus en plus commun de trouver des vidéos sur le site internet d’un projet pour en donner un aperçu, et c’est génial. Tout autant que le fait d’avoir une vidéo pour chaque étape d’un processus complexe. Le projet Plone, par exemple, a un site entier dédié aux tutoriels vidéos. Cependant, les vidéos ne peuvent pas remplacer les captures d’écran. Un utilisateur veut voir rapidement l’allure des captures d’écran sans s’arrêter devant une vidéo. Les vidéos n’apparaissent également pas dans une recherche Google Image, à l’inverse des captures d’écran.

6. Le manque d’exemples réalistes

Pour les projets basés sur du code, l’analogue des captures d’écran sont de bons et solides exemples du code en action. Ces exemples ne devraient pas être abstraits, mais directement issus du monde réel. Ne créez pas d’exemples bateaux plein de « nom de la démo ici » et lorem ipsum. Prenez le temps de créer des exemples signifiants avec une histoire d’utilisateur qui représente la façon dont votre logiciel résout un problème.

Il y a de bonnes raisons de vous embêter avec des problèmes de maths en classe. Ils permettent d’appliquer ce que vous avez appris.

Disons que j’ai écrit un module d’un robot Web, et que j’explique la méthode follow_link. Je pourrais montrer la définition de la méthode ainsi :

$mech->follow_link( text_regex => $regex_object, n => $link_index );

Mais admirez à quel point cela devient évident en ajoutant de la réalité dans l’exemple.

# Suit le 2e lien où la chaîne de caractères « download » apparait
$mech->follow_link( text_regex => qr/download/, n => 2 );

Les noms des variables $regex_object et $link_index sont maintenant compréhensibles par le lecteur.

Bien entendu, vos exemples ne doivent pas être aussi brefs. Comme Rich Bowen du projet Apache le souligne, « Un exemple correct, fonctionnel, testé et commenté l’emporte sur une page de prose, à chaque fois. »

Montrez autant que possible. L’espace n’est pas cher. Créez une section dédiée aux exemples dans la documentation, ou même un livre de cuisine. Demandez aux utilisateurs d’envoyer du code qui fonctionne, et publiez leurs meilleurs exemples.

7. Liens et références inadéquats

Vous avez les hyperliens. Utilisez-les.

Ne pensez pas, parce que quelque chose est expliquée dans une certaine partie de la documentation, que le lecteur a déjà lu cette partie, ou bien qu’il sait où elle se trouve. Ne vous contentez pas de signaler que cette partie du code manipule des objets frobbitz. Expliquez brièvement lors du premier usage de ce terme ce qu’est un objet frobbitz, ou donnez le lien vers la section du manuel l’expliquant. Encore mieux, faites les deux !

8. Oublier les nouveaux utilisateurs

Il arrive trop souvent que l’écriture de la documentation soit rédigée à partir du point de vue de son auteur, alors que es nouveaux utilisateurs ont besoin de documentation d’introduction pour les aider.

L’introduction devrait être une page séparée de la documentation, idéalement avec des exemples qui permettent à l’utilisateur de réussir quelques manipulations avec le logiciel. Pensez à l’excitation que vous ressentez quand vous commencez à jouer avec un nouveau logiciel et qu’il vous permet de faire quelque chose de cool. Faites que ça arrive aux nouveaux utilisateurs également.

Par exemple, un package graphique pourrait présenter une série de captures d’écran qui montrent comment ajouter des données dans un fichier, comment faire intervenir le grapheur, et ensuite montrer les graphes obtenus. Une bibliothèque de codes pourrait montrer quelques exemples d’appels à la bibliothèque, et montrer le résultat obtenu. Pensez simplicité. Offrez une victoire facile. Le texte devrait introduire les termes aux endroits appropriés, avec des liens vers une documentation plus détaillée sur le long terme.

Un document de démarrage séparé donne à l’utilisateur une compréhension rapide du logiciel. Il garde aussi les explications d’introduction en dehors de la partie principale de votre documentation.

9. Ne pas écouter les utilisateurs

Les développeurs doivent écouter les utilisateurs de la documentation. La chose évidente est d’écouter les suggestions et requêtes des personne qui utilisent activement votre logiciel. Quand un utilisateur prend le temps d’écrire un mail ou de poster quelque chose comme « ça aurait pu m’aider à mieux installer le programme s’il y avait eu une explication ou des liens au sujet des pilotes de la base de données », prenez ce message au sérieux. Pour chaque utilisateur vous envoyant un mail pour un problème, vous devez vous attendre à ce que dix utilisateurs silencieux aient le même problème.

Il est important d’écouter les problèmes des utilisateurs et d’en chercher les causes. S’ils ont souvent des problèmes pour effectuer des mises à jour groupées de bases de données, la première chose à faire est d’ajouter une question à la FAQ (vous avez bien une FAQ, n’est-ce pas ?) qui traite de ces questions-là. Cependant, la question peut aussi indiquer que la section traitant des mises à jour de base de données n’est pas assez claire. Ou peut-être qu’il n’y a pas de référence à cette section depuis la vue d’ensemble introductive du document, avec pour conséquence que vos utilisateurs ne pensent jamais à lire le reste du manuel.

En plus d’aider plus de gens à découvrir à quel point votre projet est utile, ça diminuera aussi la frustration de la communauté déjà existante. Si votre liste de diffusion, forum ou canal IRC est remplie de personnes qui posent toutes les mêmes questions idiotes (ou pas si idiotes) au point que tout le monde devient lassé d’y répondre, sachez reconnaître que ce sont des questions récurrents pour la FAQ, et mettre les réponses à un endroit facile à trouver aidera tout le monde à se concentrer sur des choses plus amusantes.

Gardez aussi un œil sur les questions des forums externes. Consultez les sites comme StackOverflow régulièrement, et placez une Google Alert sur votre nom de projet pour être maintenu au courant des discussions concernant votre projet sur Internet.

10. Ne pas accepter les entrées des utilisateurs

Si votre projet a une base d’utilisateur assez grande, il peut être judicieux d’incorporer les commentaires des utilisateurs directement dans la documentation. Le meilleur exemple que j’ai pu voir est celui donné par PHP. Chaque page de la documentation permet aux utilisateurs authentifiés d’ajouter des commentaires sur la page, aidant ainsi à clarifier certains points ou ajoutant des exemples qui ne sont pas dans la documentation principale. L’équipe PHP laisse aussi le choix au lecteur de lire la doc avec ou sans les commentaires des autres utilisateurs.

Aussi pratique cela soit-il, cela nécessite de la maintenance. Les commentaires doivent être éliminés de temps en temps pour éviter la prolifération. Par exemple, la page de la documentation PHP sur comment lancer PHP depuis la ligne de commande inclut 43 commentaires d’utilisateurs qui remontent à 2001. Les commentaires écrasent la documentation principale. Les commentaires devraient être archivés ou supprimés, tout en incluant les points les plus importants dans la documentation principale.

Un wiki est également une bonne approche. Cependant, si votre wiki ne permet pas à l’utilisateur de télécharger toutes les pages en une seule grosse archive (cs. point n°3 ci-dessus), alors vos utilisateurs sont à la merci de votre connexion internet et du serveur hébergeant le projet.

11. Impossibilité de voir ce que fait le logiciel sans l’installer

Au minimum, chaque projet de logiciel nécessite une liste de fonctionnalités et une page de captures d’écran pour permettre au potentiel utilisateur intéressé de savoir pourquoi il devrait l’essayer. Aidez l’utilisateur, comparant les différents paquets à utiliser, à voir pourquoi cela vaut la peine de prendre le temps de le télécharger et de l’installer.

Les images sont un bon moyen de faire cela. Votre projet devrait avoir une page « Captures d’écran » qui montre des exemples de l’outil en action (cf. point n°5 ci-dessus). Si votre projet se résume uniquement à du code, comme une librairie, alors il devrait y avoir une page d’exemples montrant ce code utilisant le projet.

12. S’appuyer sur la technologie pour votre rédaction

Trop souvent, les auteurs de logiciels utilisent des systèmes de documentation automatisés pour faire leur travail. Ce système automatisé rend les choses plus facile à maintenir, mais il ne supprime pas la nécessité d’un travail d’écriture humain.

Le pire des cas concerne le changelog, qui n’est rien de plus qu’un dump des messages de commit du système de gestion de version, mais sans un résumé qui l’explique. Un changelog devrait lister les nouvelles fonctionnalités, les problèmes résolus et les incompatibilités potentielles. Sa cible est l’utilisateur final. Un log de commit est pratique et simple à générer pour les personnes travaillant sur le projet, mais ce n’est pas ce dont l’utilisateur a besoin.

Jetez un œil à cette page de la documentation de Solarium, une interface PHP pour le moteur de recherche Solr. Tout d’abord, l’avertisemment prend la moitié supérieure de l’écran, ne donnant aucune information au lecteur. Ensuite, il n’y a vraiment rien de véritablement descriptif sur la page que la liste des noms de fonctions. Il n’y a aucune explication sur les différentes méthodes, ni de liens indiquant où trouver l’explication. Les pages générées automatiquement sont jolies, et elles pourraient ressembler à de la documentation, mais elles n’en sont pas.

13. Arrogance et hostilité vis-à-vis de l’utilisateur

L’attitude du type RTFM (Read The Freaking Manual) est mauvaise pour votre projet et votre documentation.

C’est le summum de l’arrogance que de croire que tous les problèmes qui ont trait au fait que quelqu’un ne sache pas utiliser votre logiciel sont de la faute de l’utilisateur.

Même s’il est probablement vrai que les utilisateurs peuvent trouver leurs réponses dans votre documentation mais ne le font pas, il est stupide de penser que c’est la faute de l’utilisateur. Peut-être votre documentation est-elle mal écrite, ou difficile à lire, ou présente mal à l’écran. Peut-être avez-vous besoin d’améliorer la section « Mise en route » (lien #8 ci-dessus) qui explique ce que le logiciel a pour but de faire. Peut-être que certaines parties d’information nécessitent d’être répétées à de multiples endroits de la documentation.

N’oubliez pas que les nouveaux utilisateurs de votre logiciel peuvent arriver sur votre projet sans rien n’en savoir. Votre documentation doit faire de son mieux pour s’assurer que cette ignorance soit facilement résolue.

Synthèse

Je suis sûr que vous avez déjà eu affaire à quelques-uns de ces problèmes listés ci-dessous, et peut-être que pour d’autres vous n’y avez pas pensé. Faites-nous connaître les problèmes que vous avez rencontrés dans les commentaires ci-dessous, sachant qu’il ne s’agit pas de pointer du doigt certains projets en particulier.

Surtout, j’espère que si vous reconnaissez un problème dans la documentation de vos projets, vous prendrez la peine d’améliorer la situation. Heureusement, améliorer la documentation est une manière idéale de faire participer les nouveaux arrivants dans votre projet. On me demande souvent : « Comment puis-je commencer dans l’open source », et je recommande des améliorations dans la documentation comme une bonne manière de commencer.

Faites-en sorte que ce soit aussi facile que possible, pour les novices comme les plus anciens, de savoir où il est nécessaire de travailler la documentation. Créez une liste des tâches, par exemple dans votre système de suivi des bogues, qui explique ce qui a besoin d’être amélioré. Soyez précis dans ce que sont vos besoins. Ne vous contentez pas de dire que vous avez besoin d’exemples, sans plus de précision. Créez des tâches spécifiques, comme « ajoutez un code d’exemple sur le fonctionnement de la tâche X », « ajouter une capture d’écran du générateur de rapports » ou « ajouter des informations de dépendances au fichier README/LISEZ-MOI ». Les contributeurs souhaitent aider mais trop souvent ils ne savent pas par où commencer.

La documentation n’est pas la partie la plus glamour d’un projet open source, et pour la plupart d’entre nous ce n’est pas amusant. Mais sans une bonne documentation, les utilisateurs ne sont pas servis comme ils pourraient l’être, et votre projet en souffrira sur le long terme.

Crédit photo : Rosalux Stiftung (Creative Commons By)

Vous connaissiez la suite bureautique libre Joeffice ?

Nous, non ! Et quand nous avons appris qu’elle avait été conçue en 30 jours par un développeur (qui plus est français), nous avons évidemment eu envie d’en savoir plus…

Bonjour Anthony, peux-tu te présenter succinctement ? Quel a été ton parcours de développeur ?

Bonjour, je m’appelle Anthony Goubard, j’ai 40 ans et j’habite à Amsterdam. J’ai commencé Java durant ma dernière année d’ingénieur avec la version 1.0 alpha puis j’ai fait du détachement sur la région parisienne. Il y a 14 ans je suis allé travailler pour une start-up aux Pays-Bas puis pour Wanadoo Pays-Bas et il y a 5 ans je me suis mis à mon compte.

Alors Joeffice c’est quoi exactement ? Comment et pourquoi est né le projet ?

Joeffice est une suite bureautique open source écrite en Java. L’idée m’est venue il y a environ 2 ans lorsque je me suis aperçu que c’était galère d’avoir 10 documents d’ouverts avec Microsoft Office ou Libre Office alors que ce n’est pas un problème d’avoir 30 documents ouverts dans Eclipse ou NetBeans.

Dans quel sens évoques-tu une version « online » et « offline » ?

Les logiciels Java peuvent être installés sur un ordinateur comme un logiciel classique ou bien être lancé en ligne dans le navigateur avec l’aide du plugin Java. C’est ce qu’on appelle le mode Applet. Il suffit donc d’aller à l’URL et le logiciel s’installe et se lance dans le navigateur automatiquement. J’ai donc décidé d’offrir les deux possibilités. La version « online » est soumise à un abonnement.

Pourquoi le choix Java ?

Java offre beaucoup d’avantages. Il est portable sur plusieurs OS, il est relativement facile à lire, beaucoup d’étudiants apprennent Java et il est très utilisé dans le monde de l’entreprise. Beaucoup de projets open source utilisent Java. Joeffice offre aux étudiants et développeurs Java la possibilité de travailler sur un projet assez visuel et utile.

Pourquoi le choix de la licence libre ?

L’union fait la force.Tous les développeurs Java que je connais se servent de temps en temps d’une suite bureautique. Avoir un projet bien mené par un grand groupe de contributeurs permettra à long terme de créer un bien meilleur logiciel qu’avec une petite équipe. En plus, beaucoup d’entreprises et de pays en voix de développement sont attirés par l’open source et mon but est de toucher le plus de personnes possible.. Le premier groupe d’utilisateurs pour Joeffice est donc l’entreprise. Dans ce cas la licence Apache 2.0 donne beaucoup de liberté, plus que GPL et LGPL. Cette licence est par exemple utilisée pour le framework Spring.

Comment se positionne Joeffice, aujourd’hui et demain, par rapport à des « monstres » comme Google Docs, Microsoft Office ou LibreOffice ?

Joeffice est moins complet que ces autres offices mais il a aussi des atouts que d’autres n’ont pas. Il est donc open source sous licence Apache. Il est développé entièrement en Java. Il peut s’installer « offline » ou « online ». Il est facilement portable. Il n’a pas une fenêtre par document mais un système d’onglet et d’amarrage ou les documents peuvent être l’un à côté de l’autre ou détachés en groupe. Les mises à jour et plugins, même si pour l’instant non utilisés, peuvent se faire en ligne. Toutes les librairies Java peuvent être facilement utilisées pour créer des actions spéciales, afin par exemple de remplir un document.

La légende dit que tu l’aurais codé tout seul en moins d’un mois ? La légende dit vrai ?

Je l’ai codé en 30 jours. Mais ce sont 30 jours non consécutifs. Pour chaque journée j’ai fait une vidéo que j’ai postée sur YouTube. Il a fallu que je sois efficace sur le code et pragmatique sur certains choix.

En France, on vient d’introduire cette année l’informatique comme discipline à part entière au lycée (pour le moment en option de Terminale S). Bonne ou mauvaise idée ?

Bien sûr, je trouve ça une bonne idée. Même en n’étant pas informaticien, les gens ont de plus en plus besoin de savoir développer. Par exemple un plug-in, une macro ou un site Web.

Joeffice se présente en version alpha. Que lui manque-t-il exactement pour une première version ?

Je me sers de la librairie open source Apache POI pour lire les documents malheureusement il manque encore certaines parties. Chaque partie du logiciel doit être améliorée pour avoir quelque chose de plus utilisable pour l’utilisateur final. Cette version alpha est plus destinée aux développeurs et aux entreprises qui ont des besoins spécifiques. Le but pour la version 1.0 est de s’approcher de ce que peut faire Google Docs.

Et comment vois-tu le futur du projet ? Un appel à lancer ?

Tous les développeurs qui veulent participer à ce projet ou à une des librairies dont Joeffice se sert sont les bienvenus. Le code se trouve sur BitBucket.

Lorsque la distribution GNU/Linux Ubuntu est sortie en 2004, son père fondateur Mark Shuttleworth a signalé lui-même le premier « bug » : Microsoft détient la majorité du marché (Microsoft has a majority market share).

Il s’agissait symboliquement, et avec humour, de montrer le cap à suivre en désignant le principal concurrent.

Aujourd’hui la donne a changé et Shuttleworth a décidé hier de marquer ce bug comme résolu (fix released), quand bien même cela ne signifie pas, loin de là, qu’Ubuntu ait gagné comme il s’en explique ci-dessous.

Remarque : Nous en profitons pour signaler que Framasoft sera présent en masse à l’Ubuntu Party de Paris, avec stand et 3 mini-conférences le samedi 1er juin.

Bug #1 : Microsoft détient la majorité du marché

Bug #1 (liberation) : Microsoft has a majority market share

Mark Shuttleworth – 30 mai 2013 – Launchpad Ubuntu
(Traduction : Penguin, Mowee, Cryptie, quack1, @zessx, Asta, misc, MFolschette, Samusz + anonymes)

Aujourd’hui, l’utilisation de l’informatique dans la vie de tous les jours est beaucoup plus importante qu’elle ne l’était en 2004 : les téléphones, tablettes et autres appareils nomades sont devenus une part non négligeable de notre vie numérique. D’un point de vue compétitif, cet édifiant marché est une bénédiction pour la concurrence. Avec notamment iOS et Android, qui tous deux représentent une part significative du marché (Voir Windows en dessous de iOS et Android réunis avec ce graphique.

Android n’est peut-être pas mon premier choix de (noyau) Linux, ni le vôtre, mais c’est sans aucun doute une plateforme open source qui offre des avantages pratiques et économiques aux utilisateurs, comme à l’industrie. Ainsi, nous avons d’un côté de la concurrence et de l’autre une bonne représentation de l‘open source dans l’informatique personnelle.

Même si nous n’avons joué qu’un petit rôle dans ce changement, je pense qu’il est important pour nous de reconnaître qu’il a eu lieu. Du point de vue d’Ubuntu, le bug est maintenant clos.

Évidemment, ce bug a aussi un aspect social. Pour beaucoup, il a fait office de déclaration d’intention. Mais il est préférable pour nous de nous concentrer sur l’excellence de notre propre travail, plutôt que considérer notre impact sur le produit des autres. Depuis les (nombreuses) années que ce bug est référencé, nous avons trouvé comment être excellents dans le cloud, et j’espère que nous trouverons aussi bientôt comment l’être sur les postes de travail des développeurs, et peut-être même sur toute la quantité d’appareils que les utilisateurs réguliers peuvent utiliser. Je préférerais désormais que nous trouvions un cri de ralliement qui célébrerait ces idées et leur management.

Il est important de remarquer que de nos jours, si vous êtes dans le domaine de l’informatique dématérialisée (NdT : cloud computing), l’équipe de service d’infrastructure (NdT : IaaS) de Microsoft est très compétente et travaille dur pour que Linux soit parfaitement supporté par Azure, ce qui rend le travail avec eux très plaisant. Si l’évolution du marché a peut-être joué un rôle dans tout ça, les circonstances ont changé et les institutions se sont adaptées. Nous nous devons donc de le faire aussi.

Cela dit, il est bon de prendre du recul et de visualiser combien tout cela a changé depuis 2004, et à quelle vitesse ! Avec Ubuntu, notre but est de proposer à tous une expérience utilisateur formidable, que ce soit pour les développeurs, pour la production en entreprise ou tout simplement l’utilisateur final. Et tout cela avec un large support de matériel. Nous évoluons dans un environnement dynamique qui ne cesse de changer d’année en année. C’est donc pour cela que nous devons sans arrêt nous remettre en question, que ce soit au niveau de notre façon de faire, nos pratiques, les outils que nous utilisons ainsi que les relations que nous entretenons en interne et en externe. Corriger ce problème n’en est qu’un tout petit exemple.

C’est ce qui arrive à un développeur britannique.

Il s’en réjouit et nous avec 😉

Le gouvernement britannique me paye pour faire de l’open source toute la journée

The UK government pays me to write open source all day

Jake Benilov – 17 mai 2013 – QuickPeopleBlog
(Traduction : RyDroid, goofy, @zessx, Sylvain, MFolschette, Asta, Chuckman + anonymes)

Je suis développeur. Voici le graphique récapitulant mes contributions open source sur Github pour les 12 derniers mois (les carrés verts représentent les jours où j’ai fait des commits dans des dépôts open source) :

Bien que je fasse aussi de l’open source pendant mon temps libre, la plupart de ces points verts apparaissent pendant mes heures de travail au Government Digital Service (NdT. unité gouvernementale chargée de revoir le fonctionnement des services gouvernementaux en ligne), une équipe du Bureau du Cabinet britannique.

Je ne suis pas un cas isolé dans mon équipe. Si vous jetez un coup d’œil à la page Github du GDS, vous trouverez beaucoup de code. Mieux encore, notre travail ne se déroule pas seulement en marge des TIC gouvernementales : nous sommes responsables du site GOV.UK, la principale plateforme de publication du gouvernement britannique, et l’accès principal à toutes les opérations gouvernementales.

Un point où j’ai peut être exagéré : comme James Stewart (un des directeurs développement du GDS) le souligne, le GDS fait aujourd’hui du « code ouvert » plutôt que de « l’open source ». Cela signifie que le GDS rend les sources disponibles sous une licence de libre diffusion (LLD), mais ne soutient ou n’établit aucune communauté autour. Dans tous les cas, le « code ouvert » est génial pour de nombreuses raisons.

Équité envers le contribuable

Les sources gouvernementales devraient être ouvertes. Après tout, si le code a été écrit grâce aux impôts du contribuable, ce n’est que justice que le contribuable puisse l’avoir en retour. Fait intéressant, le critère n°15 du Digital by Default Service Standard (NdT. document explicitant les critères auxquels doivent répondre les services gouvernementaux en ligne) récemment publié devrait institutionnaliser cela et faire en sorte que tous les futurs projets du gouvernement britannique soient mandatés pour ouvrir leurs sources par défaut :

Rendez tout nouveau code source ouvert et réutilisable, et publiez-le sous les licences appropriées (ou fournissez une raison valable pour laquelle ce n’est pas possible pour certaines parties spécifiques du code source)

Équité envers la communauté de l’open source

Nous utilisons des langages et frameworks open source (la majorité de GOV.UK est écrite en Ruby et Scala), des serveurs web open source, nous gérons et configurons nos sources avec des outils open source (Git et Puppet), et nous déployons sur les systèmes d’exploitation open source (tournant sous Linux). Redistribuer n’est que justice.

Transparence

Disposer de mon code source GDS sur GitHub facilite ma vie de développeur au GDS. Si j’ai besoin d’intégrer, de réutiliser ou d’étendre un autre composant du GDS, j’ai juste à cliquer dans mon navigateur ou à cloner le dépôt.

La transparence bénéficie aussi à ceux en dehors du GDS. Besoin de connaître les règles pour calculer une pension d’État ? Regardez les sources. Vous avez trouvé un bug dans la page des jours fériés ? Vous pouvez soumettre une pull request pour le corriger.

Je connais des sociétés qui ont des programmes open source internes, et c’est certainement un pas dans la bonne direction, mais le fait de rendre presque tout disponible nous rapproche de l’idéal d’une propriété commune du code.

En bonus, puisque les bidouilles et les raccourcis sont visibles par tout le monde, il en résulte une diminution des bricolages hasardeux.

Réutilisation

Bien qu’une bonne partie du code que nous écrivons est spécifique à nos problématiques, une large part est générique, et pourrait facilement être adaptée à l’usage d’autres administrations centrales, régionales ou locales, ou dans le secteur privé. En fait, les gens commencent déjà à le faire. Vous voulez du bon code pour un front-end ? Le voici. Vous voulez un système de login unique de qualité gouvernementale ? Le voilà. Vous voulez construire vos propres réponses intelligentes ? Ne vous gênez pas.

Marketing

Le « code ouvert » est un bon argument marketing pour l’image de marque du GDS. Quand je dis à d’autres hackers que je fais de l’open source au travail, les sourcils se lèvent. J’ai entendu des gens extérieurs au GDS en parler en termes de « startup gouvernementale » ; il est évident que l’open source améliore l’image de la marque.

Pour le CV

Pour des raisons purement égoïstes, il est vraiment agréable d’avoir un portfolio de mon travail, un endroit où je peux apporter aux gens une preuve tangible de ma capacité (ou mon incapacité ?) à coder en Ruby.

J’aimerais que davantage d’employeurs fassent cela (et pas seulement le secteur public). Si le vôtre ne le fait pas, peut-être que les raisons évoquées ci-dessus pourront aider à le convaincre de changer d’avis ?

L’un des auteurs que l’on traduit le plus sur le Framablog, Glyn Moody, choisit ici de mettre les pieds dans le libre plat.

Et si on n’utilisait plus les licences libres, qui ne sont pas sans poser problèmes, en plaçant directement le code dans le domaine public ?

Les avantages pourraient finalement dépasser les inconvénients !

Remarque : Sur le même thème on pourra également lire (ou acheter) notre framabook Un monde sans copyright… et sans monopole. Sans oublier notre auteur Pouhiou qui place directement ses romans dans le domaine public et s’en explique ici dans un fort intéressant dialogue avec Lionel Maurel aka Calimaq.

Pourquoi il est temps d’arrêter d’utiliser les licences libres

Why it’s time to stop using open source licences by Glyn Moody

Glyn Moody – 13 février 2013 – The H Open
(Traduction : Tr4sK, aKa, Sphinx, Isdf, Penguin, ProgVal, lamessen, Shanx, Amargein, ronane, MFolschette, Isser)

Les logiciels libres reposent sur un paradoxe. Afin que les utilisateurs puissent être libres, les licences libres utilisent quelque chose remettant en cause la liberté : le copyright. Ce dernier est un monopole intellectuel se basant sur la restriction de la liberté des gens à partager, la liberté est donc restreinte et non pas étendue. Quand Richard Stallman, en 1985, a créé la GNU Emacs General Public License, cela représentait un bidouillage brillant, maintenant il est peut-être temps de passer à autre chose.

Nous y sommes déjà et des éléments le montrent. Il y a 18 mois, les gens ont commencé à remarquer le déclin des licences copyleft vers des licences plus permissives comme la licence Apache ou BSD. Plus récemment, la croissance de GitHub a attiré l’attention, montrant également que de plus en plus de gens n’utilisent plus de licences sur GitHub (ce qui peut s’avérer problématique d’une certaine manière).

Je ne pense pas que le déclin des licences copyleft soit la preuve d’un échec, bien au contraire ! Je l’écrivais dans mon édito précédent, le logiciel libre a au fond gagné, prenant le pouvoir dans la plupart des secteurs clés de l’informatique. De la même manière, le passage à des licences permissives n’a été rendu possible que grâce au succès du copyleft : les idées participant à la création collaborative et à la contribution à un projet que l’on utilise sont maintenant généralisées. Il n’y a donc plus besoin de licences copyleft « fortes » pour faire respecter ces valeurs, elles font désormais partie de l’ADN des codeurs. Ian Skerrett le déclarait ainsi en 2011 :

« On n’a plus besoin de s’assurer que les développeurs ou les entreprises soient honnêtes. Ils contribuent aux projets open source parce que cela les aide dans leur travail. S’il fallait s’assurer que les développeurs sont honnêtes, pourquoi y aurait-il autant de projets Apache réussis ? Prenons l’exemple du projet Eclipse qui utilise un copyleft faible. Je ne connais que très peu de contributions ayant été intégrées à Eclipse parce que le développeur avait été forcé de contribuer à cause des obligations de licence. Les gens contribuent aux projets qu’ils utilisent parce qu’ils ont saisi le bénéfice qu’ils pouvaient recevoir grâce à leur contribution. »

C’est aussi pourquoi nous ne devons pas nous n’inquiéter du cloud computing — parfois présentée comme la tueuses des licences libres — puisqu’il n’y a pas de distribution obligeant à publier les éventuelles modifications du code. Mais une fois de plus, nous n’avons pas besoin de cette obligation : si une entreprise d’informatique de cloud computing veut pleinement tirer les bénéfices du logiciel libre, elle y contribuera de toute façon. Si elle ne le fait pas, elle n’a rien compris.

Quelle licence devons-nous donc adopter si on n’utilise pas une licence copyleft ? Apache ? BSD ? Pourquoi pas aucune licence du tout , c’est à dire mettre le logiciel dans le domaine public ? Après tout, c’est la conclusion logique du mouvement vers des licences de plus en plus permissives — une qui permet tout.

Compte tenu des discussions passionnées qui ont tendance à se produire lorsqu’on émet l’idée qu’il y a un mouvement des licences copyleft traditionnelles vers des licences légèrement plus permissives, je soupçonne que l’idée d’évoluer vers une licence complètement permissive sera choquante pour certains. À l’évidence, cela semblerait impossible, car conduisant « certainement » à l’effondrement du logiciel libre lui-même si celle-ci était largement adopté.

Un article intéressant de Clark Asay, maître de conférences à la Penn State Univerity Dickinson School of Law (et aussi frère de Matt Asay, personnalité connue de tous dans le logiciel libre) étudie cette idée en profondeur et présente quelques arguments convaincants sur le fait que placer les logiciels libres dans le domaine public fonctionne et s’avère bénéfique.

Asay (Clark et non Matt) remarque qu’il y a un coût à utiliser des licences libres en termes de conformité. Les entreprises dépensent énormément d’argent en se préoccupant de faire les choses bien, mais les programmeurs, eux aussi, perdent du temps à s’occuper de détails légaux alors qu’ils pourraient être en train d’écrire davantage de lignes de code. En particulier, l’incompatibilité entre les nombreuses licences et leurs variantes est une barrière importante à de plus larges réutilisations et collaborations. Ces problèmes signifient que les logiciels libres ne sont pas utilisés aussi largement et efficacement qu’ils le pourraient, commercialement ou non. Ces difficultés peuvent expliquer en partie le glissement vers des licences plus « permissives », guidé par le désir d’éviter justement ces problèmes.

Asay se met alors à examiner les deux objections majeures à rendre le code disponible librement, sans aucune licence. La première tient au fait que les entreprises risquent de récupérer du code puis de l’enfermer, ce qui selon lui a peu de chance de se passer puisque, en faisant ainsi, elles écarteraient beaucoup des bénéfices que seuls les logiciels libres offrent :

« Si une société devait prendre la responsabilité d’un projet et le rendre fermé, elle n’obtiendrait certainement pas le travail bénévole que les contributeurs du monde entier ont envie d’offrir aux projets disposant de licences ouvertes. Sans ce travail bénévole, les sociétés perdraient un des avantages les plus significatifs des modèles ouverts d’innovation, et ce travail bénévole resterait probablement fidèle à la version ouverte du projet. C’est pourquoi les sociétés encouragent d’ores et déjà à ouvrir le plus de projets possibles et à y contribuer. Car en faisant ainsi, cela va attirer une force de travail bénévole et déclenchera une innovation correspondant mieux à à leurs besoins et stratégies.

Est-ce que la réciprocité (c’est-à-dire l’obligation de contribuer au projet en contre-partie) permet d’éviter la désertion des contributeurs individuels ? Il semble peu probable que, dans la plupart de cas, les contributeurs individuels aient le temps, l’intérêt et les ressources pour s’emparer d’un projet non-réciproque et d’en créer un équivalent fermé. La littérature suggère que les buts espérés par les individus qui contribuent à des projets aux licences ouvertes, ont peu à voir avoir avec un avantage financier direct. Leurs intérêts pour la contribution résident plutôt dans la créativité, l’amélioration de sa réputation, et les bénéfices financiers indirects. Bien qu’il soit toujours possible pour des contributeurs de s’emparer d’un projet ouvert et de le rendre fermé pour l’intégrer dans leurs propres produits (et ainsi contrevenir à ce modèle ouvert d’innovation), les mêmes raisons qui suggèrent que les sociétés ne le feront pas s’appliquent également aux contributeurs individuels. Les contributeurs individuels sont encore moins à même d’abandonner les buts qu’ils espèrent atteindre dans la contribution à des projets ouverts, en plus de n’avoir que des ressources limitées pour réussir à fermer et maintenir un projet. »

L’autre objection majeure qu’il met en avant est que si le logiciel est placé dans le domaine public, il n’existe aucune exigence pour que tous les programmeurs reçoivent la reconnaissance qu’ils méritent pour leur contribution à un projet. Cette reconnaissance peut être importante en raison de l’estime des pairs dont ils jouissent en retour et peut même aboutir à des compensations économiques sous la forme d’offres d’emploi et d’augmentations de salaire.

Attribution et réputation

Je suis d’accord pour dire qu’attribuer le mérite d’un projet est important, et cela de manière cruciale. En fait, je pense que cela représente la clé du problème concernant les produits numériques partagés sur Internet, étant donné que les bénéfices économiques dépendent de cela. Toutefois, forcer cette attribution grâce à des licences ne représente peut-être pas le meilleur moyen. Asay l’explique ainsi :

« Dans une large mesure, l’approche de la gestion de la propriété intellectuelle choisie par les modèles d’innovation ouverts (c’est-à-dire les licences classiques des projets open source) échoue à remplir ses missions. Par exemple, le respect des licences attribution-only (mention de l’auteur original du projet) provoque l’enfouissement d’une telle reconnaissance dans les documents légaux ; cela fait que la reconnaissance d’une telle paternité devient minime. Cette réalité montre que ceux qui contribuent en utilisant des licences attribution-only, bien qu’étant motivés par une certaine forme de reconnaissance, obtiendront un tout autre type de reconnaissance que celui engendré par la propriété intellectuelle. Dans le monde du logiciel libre et open source, des outils comme GitHub, utilisé largement comme outil social de développement, peuvent fournir plus efficacement la reconnaissance que cherchent les programmeurs. Le fait que de plus en plus de contributions à des logiciels effectuées via GitHub se font sans avertissement de non-respect de la propriété intellectuelle ou des clauses de licences montre que le « prix » d’un tel avertissement à cause d’une documentation légale obscure n’en est pas un, du moins pour ceux qui contribuent. »

En effet, les personnes et les entreprises ont déjà commencé à utiliser les profils GitHub comme un moyen d’afficher et de mesurer la capacité à coder. Je soupçonne que cela deviendra bientôt la norme, avec des moyens plus formels d’établir sa réputation dans le monde du développment, apparaissant aux côtés de ceux informellement dictés par les normes sociales au sein de la communauté du logiciel libre.

Après avoir abordé les deux principales objections de se passer de licences open source traditionnelles, Asay examine ensuite ce que le domaine public signifierait en pratique :

« Une approche du style domaine public devrait remplacer efficacement les droits d’auteurs automatiques, supprimer tous les droits liés aux brevets (les deux respectant les droits des brevets déjà obtenus ainsi que de façon prospective), et renoncer à tous les recours possibles venant avec eux. Les droits liés au secret commercial, le cas échéant, devraient êtres supprimés dès que le titulaire des droits a publié le logiciel ou le contenu au public. On peut dire que renoncer à tout droit de marques est non seulement inutile mais déconseillé, car les autres pourraient utiliser les marques pour embrouiller les consommateurs quant à la source du logiciel ou du contenu. En effet, c’est exactement pourquoi la licence CC (Creative Commons), qui inclut une licence dédiée au domaine public dans son répertoire légal, exclut expressément les droits de marque dans son outil. »

Ce dernier point sur les marques est important, bien qu’il puisse sembler étrange de prétendre que tous les monopoles intellectuels et marques doivent être conservés, parce qu’ils servent un but très différent de celui du droit d’auteur ou des brevets. Les marques sont conçues pour protéger les consommateurs contre la fraude, plutôt que de chercher à exclure les concurrents, même si c’est la façon dont elles sont souvent utilisées aujourd’hui.

Mais pour les projets open source, les marques sont purement une question de réputation — c’est à dire qu’elles deviennent des garanties de qualité lorsqu’elles sont appliquées à un programme. N’importe qui peut prendre le code et l’utiliser et l’adapter de différentes façons. Mais il ne pourra pas utiliser la marque du projet, car cela impliquerait qu’il s’agit d’une version officielle « approuvée ». Ce qui serait évidemment problématique pour une variété de raisons, à commencer par celle de la sécurité.

Asay aborde également une objection importante dans sa thèse selon laquelle placer un logiciel dans le domaine public serait la meilleure façon de le distribuer : si c’était le cas, pourquoi tout le monde s’en tiendrait à la licence GPL ou Apache ? Comme il le souligne :

« Dans le monde du logiciel libre et open source, par exemple, il n’existe aucun outil reconnu ou largement utilisé dévoué au domaine public. A la place, l’Open Source Initiative et la Free Software Foundation — les deux principales organisations de défense des logiciels libres dans le monde — refusent ou approuvent les licences ouvertes utilisées dans la communauté. S’il est vrai que divers projets pourraient tout simplement ignorer ces licences recommandées et d’adopter une approche par domaine public — certaines ayant essayé de faire exactement cela — cette approche suppose que les organisateurs de ces projets comprennent comment le faire. »

Le fait est qu’il est actuellement assez difficile de placer un logiciel dans le domaine public, premièrement parce qu’il y a un biais culturel contre une telle attitude, même au sein de la la communauté du logiciel libre, et deuxièmement parce que légalement c’est un processus délicat. En effet, Asay suggère que nous avons besoin d’une nouvelle législation — ce qu’il appelle Public Domain Act (NdT, en français : « Loi du Domaine Public ») — pour rendre ce processus plus facile. Il faudra évidemment prendre en compte les différents systèmes de copyright ayant cours dans le monde — par exemple, ceux qui mettent plus l’accent sur les « droits moraux ».

Il y a quelques années, j’ai demandé à Richard Stallman ses points de vue sur la manière dont le copyright devrait être réformé, particulièrement concernant l’aspect logiciel. Voici ce qu’il a répondu :

« Pour la plupart des types de travaux, je pense que le droit d’auteur serait acceptable si nous l’avions (1) fait plus court (je suggère 10 ans), (2) permis la redistribution de copies dans un but non commercial et sans modification, (3) défini comme fair use les réutilisations sous forme de remix. Cependant, je pense que les logiciels et autres œuvres d’usage pratique doivent être libres. »

Notez qu’il pense, lui aussi, que le logiciel devrait être exempt de tout copyright — en d’autres mots, dans le domaine public — mais il a ajouté quelques mises en garde :

« Je serais heureux de voir l’abolition du copyright dans le logiciel si c’était fait de façon à s’assurer que le logiciel est libre. Après tout, l’objectif du copyleft est d’atteindre ce but pour les dérivés de certains programmes. Si tous les logiciels étaient libres, le copyleft ne serait plus nécessaire.

Cependant, l’abolition du copyright peut aussi être faite de manière erronée et pourrait n’avoir aucun effet sur les logiciels propriétaires typiques (qui sont restreints par des CLUF, Contrats de Licence Utilisateur Final, et le secret du code source plus que par le copyright), et ne ferait que porter atteinte à l’utilisation du copyleft. J’y serais naturellement opposé. »

Placer les logiciels libres dans le domaine public serait équivalent à abolir le droit d’auteur pour ces programmes tout en laissant le code propriétaire intact. Est-ce vraiment un problème ? Personnellement, je ne le pense pas, pour les raisons que j’ai mentionnées : toute entreprise prenant du code dans le domaine public et se l’appropriant perd tous les avantages de son ouverture. Il est vrai qu’il reste des programmes hérités des maisons de logiciels à l’ancienne qui ont toujours été propriétaires, mais leurs existence n’affecte pas vraiment le monde plus large du logiciel libre, qui est maintenant arrivé à l’indépendance et à l’autosuffisance. Ce que Microsoft et ses semblables font en ce moment est quelque peu hors de propos.

Bien sûr, le passage au domaine public ne signifiera pas la disparition des licences libres actuelles — elles seront toujours là pour ceux qui souhaitent les utiliser. Comme toujours, le choix et la liberté personnelle sont capitaux. Mais j’espère que les gens y réfléchiront à deux fois avant d’introduire de nouvelles licences, ou même avant d’en mettre à jour d’anciennes. En particulier, j’espère qu’il n’y aura jamais de GNU GPL version 4. Au contraire, nous devons parachever la révolution que Richard Stallman a commencée il y a près de trois décennies en rendant le logiciel libre véritablement libre, en le plaçant dans le domaine public et en brisant les chaînes qui le lient encore à ce monopole vieux de trois cents ans nommé copyright.