Réflexion préalable

Pourquoi ouvrir son code ?

Les raisons sont propres à la stratégie de chaque entreprise.

Voici quelques motivations fréquentes :

• Pour contribuer aux biens communs numériques : tous les systèmes d'information reposent directement ou indirectement sur des logiciels libres : en ouvrant son code, l'entreprise participe à cette mise en commun du code.
• Pour trouver des testeurs : en ouvrant son code et en le rendant facile à installer, vous multipliez les possibilités de le tester.
• Pour attirer et impliquer des développeurs extérieurs : si vous allez au-delà de la simple mise à disposition du code sous licence libre et vous mobilisez pour construire une communauté, vous pourrez bénéficier de contributions extérieures.
• Pour améliorer votre code : développer « en public » est une façon de se contraindre à adopter des bonnes pratiques qui touchent à la fois la technique (structurer son code, le tester) et la communication (écrire une documentation, répondre aux questions des utilisateurs, etc.)

Image

Les réticences à surmonter pour l'ouverture

• « Nous allons montrer du code sale » : oui, cela vous incitera à le nettoyer.
• « Ouvrir le code va nous donner plus de travail » : non, si l'ouverture correspond au « degré zéro » de l'ouverture, à savoir la simple mise à disposition sous licence libre. Oui, si votre stratégie d'ouverture implique un degré supplémentaire, avec une maintenance active.
• « Nous allons exposer des problèmes de sécurité » : oui, cela permet de mieux les corriger.
• « Notre code est inutile sans certains paramètres » : dans ce cas, les utilisateurs pourront toujours vérifier que votre code fait bien ce qu'il est supposé faire, avec ou sans la connaissance des paramètres.
• « Nous allons exposer des données confidentielles » : au moment de publier le code source de votre application, veillez à ne pas y laisser traîner de mots de passe ou de clefs secrètes.
• « Nous ne pourrons plus exploiter commercialement notre code » : vous ne pourrez pas faire reposer votre modèle de financement sur la vente d'un logiciel fermé, mais il existe de nombreux modèles économiques autour du logiciel libre. Par exemple faire payer l’installation, l’hébergement, l’assistance, la formation, le développement de fonctionnalités supplémentaires, etc.

Choisir le degré d'ouverture

Classement des niveaux « d’ouverture » par Etalab :

• Contributif (A) : Le code source est publié, les contributions extérieures sont activement recherchées et traitées
• Ouvert (B) : Le code source est publié, les contributions extérieures sont traitées mais non activement recherchées
• Publié (C) : Le code source est publié mais les contributions extérieures ne sont pas traitées
• Fermé (D) : Le code source n’est pas publié

Impact sur les coûts

Les degrés d’ouverture d’un logiciel ont un impact sur les coûts à supporter :

Contributif (A)

Le code source est publié, les contributions extérieures sont activement recherchées et traitées.

Cela implique plusieurs actions et donc plusieurs postes de coûts :

• Animer la communauté
• Communiquer
• Valider les contributions (tester, dialoguer avec le contributeur, intégrer au code officiel…), etc.

Ouvert (B)

Le code source est publié, les contributions extérieures sont traitées mais non activement recherchées.

Cette option est un peu moins coûteuse que la précédente.

Il n’y a plus de dépenses d’animation ou de communication.

Publié (C)

Le code source est publié mais les contributions extérieures ne sont pas traitées.

Il n’y a dans ce cas qu’un minime coût associé à la publication du code. Si le dépôt du code libéré est aussi le dépôt servant au travail des développeurs, c’est même plus économique qu’une version fermée ; en effet, GitHub ne fait pas payer les dépôts des logiciels libres (par opposition aux dépôts non-publics, payants)

Image

Choisir une licence libre

Une licence libre permet à un utilisateur d'utiliser, étudier, copier et modifier le logiciel publié.

Définition d'un logiciel libre

Un logiciel libre est défini par quatre grandes libertés offertes aux utilisateurs :

• Liberté d’utilisation
• Liberté d’analyse et de modification
• Liberté de copie
• Liberté de redistribution des versions modifiées

Avoir accès au code source est un impératif pour pouvoir analyser le logiciel et le modifier.

Vocabulaire : le terme open source est à éviter, car il n’implique que la possibilité de consulter le code source. Un logiciel peut être open source sans donner la possibilité légale de copier, modifier ou redistribuer le logiciel.

Licence

Comme tous les logiciels, les logiciels libres sont protégés par le droit d’auteur.

La licence d’un logiciel libre définit ses conditions d’utilisation et utilise la législation pour garantir les libertés des utilisateurs.

Il existe deux grandes catégories de licences libres :

• Licences avec obligation de réciprocité (copyleft, « gauche d’auteur ») : GPL, CeCILL, LGPL, AGPL, etc.
• Licences permissives : MIT, BSD, Apache, etc.

Les logiciels incorporant du code copyleft doivent eux-mêmes être placés sous une licence copyleft équivalente. Les logiciels incorporant du code sous licence permissive peuvent avoir une licence privatrice (dite propriétaire ou non-libre).

Comment choisir entre ces deux types de licences ?

Les licences permissives permettent l’utilisation sans contrainte même pour une appropriation du bien commun. Les licences copyleft garantissent que les applications rendues possibles par le logiciel d’origine restent à la disposition de tous.

Si on souhaite qu’une bibliothèque soit diffusée le plus largement possible, y compris au sein d’applications fermées (propriétaires, privatrices), il faut utiliser une licence permissive. Ce pourrait être le cas d’une bibliothèque permettant la lecture d’un nouveau format (eg HDF5). Pour que le format s’impose, il est nécessaire d’en faciliter la lecture et donc de diffuser les bibliothèques de lecture le plus largement possible.

Si on souhaite qu’une application ne soit pas appropriée par une société commerciale, une licence copyleft est plus adaptée. Ce pourrait être le cas d’une application développée sur fonds publics : les améliorations qui lui sont apportées devraient bénéficier à tous, pas seulement à des structures bénéficiant gratuitement de l’application d’origine.

En savoir +

Retrouvez l'article sur les licences libres.

Voir aussi :

• Qu'est-ce que le logiciel libre ?

• Comprendre les licences libres

• Tableau de compatibilité entre licences

Publier un logiciel libre

Où publier le code ?

GitHub et Gitlab sont les deux dépôts principaux.

Choix par défaut pour disposer de la meilleure visibilité et d’outils maîtrisés par le plus grand nombre : GitHub

Choisir la forme https://github.com/organisation/logiciel ou https://github.com/logiciel

Exemple :

1. https://github.com/makinacorpus/django-leaflet/
2. https://github.com/Terralego/

Communiquer autour du code

Organiser le dépôt GitHub

https://github.com/18F/open-source-guide

Expliciter l'organisation de la maintenance

• Qui est mainteneur (le nom d'une personne et une adresse e-mail) ?
• Indiquer si la maintenance est «  passive » (vous répondez aux questions et aux demandes d'amélioration mais vous ne travaillez pas activement sur le code) ou « active » (vous travaillez activement sur le code).

Ajouter les informations essentielles au dépôt de code

• Une description claire en anglais ou en français (mieux, les deux)
• Des tags pertinents
• Un lien vers un site web s'il y en a un
• Un fichier README en anglais si votre logiciel a vocation à pouvoir être utilisés par des personnes ne parlant pas le français (comme une bibliothèque générique par exemple), en français sinon
• Un fichier LICENSE avec le texte de la licence
• Un fichier CONTRIBUTING en anglais qui explique comment contribuer

Contenu minimal du fichier README

• L'auteur et titulaire des droits
• Une façon de tester le logiciel
• Un point de contact avec le mainteneur
• Une indication des contributions acceptées
• La licence libre utilisée

Guider les contributeurs sur GitHub

Sur GitHub, vous pouvez ajouter un fichier `ISSUE_TEMPLATE` dont le contenu sera inséré dans les nouveaux tickets ("issues") ouverts, et `PULL_REQUEST_TEMPLATE` pour les *pull requests*.

Documentation sur https://help.github.com/articles/helping-people-contribute-to-your-project/. Gérer les pull requests, c’est-à-dire les propositions de contribution extérieures.

Rédiger une documentation utile

Il doit y avoir une documentation orientée utilisation et une documentation orientée développeur.

Démonstration

Proposer une démonstration du logiciel, par exemple sous forme d’une plate-forme permettant d’utiliser l’application et remettant à zéro les données toutes les nuits. Expliquer ce que fait le logiciel et comment utiliser la démo en quelques mots. Éventuellement, mettre en place une présentation pas à pas (walkthrough) à l’aide d’outils tels que https://github.com/usablica/intro.js, https://github.com/shipshapecode/shepherd, etc.

Impliquer les utilisateurs et les contributeurs

Il ne suffit pas de publier un logiciel sous licence libre pour en faire un « bien commun » : il faut aussi animer son développement et mobiliser une communauté de contributeurs.

Suivre activement les bugs

Offrir un système de remontée et de suivi de bugs public. Dans GitHub, c’est fait à travers les issues qui peuvent également servir pour documenter des évolutions de fonctionnalités ou des demandes d’évolutions.

Installation

Fournir des méthodes d’installation faciles (conteneur Docker, paquet…). Ne pas les fournir peut être un choix visant à éliminer les utilisateurs sans compétences techniques.

Tests

Fournir une suite de tests.

Gérer les versions du logiciel

Utiliser la gestion sémantique de version ou tout autre système permettant de bien communiquer vos progrès avec vos utilisateurs.

Organisation interne

S ‘assurer qu’à tout moment il y ait au moins trois personnes au sein de l’équipe qui comprennent le logiciel et puissent y contribuer. Ce nombre minimum permet de ne pas bloquer le développement du logiciel en cas d’indisponibilité, d’absence, de départ… Mettre en place une organisation et des méthodes pour gérer les issues et les pull requests.

Communiquer avec les clients / prospects

Objectif : mettre en valeur l’application et surtout le savoir-faire associé

Construire avec l’équipe marketing :

• Publier des articles sur votre site et ailleurs
• Tweeter
• Communiquer sur les release, etc.

Références

Une partie du texte est librement inspirée des sites suivants :

• https://github.com/etalab/ouverture-des-codes-sources-publics & https://guides.etalab.gouv.fr/pdf/guide-logiciels.pdf

• https://doc.eig-forever.org/opensource.html

Des guides sur l'open source en général : https://opensource.guide