Pourquoi ouvrir le code source d'un logiciel ?

Ce sujet est destiné à recenser les raisons pour lesquelles une administration devrait ouvrir le code source d’un logiciel, mais aussi les cas particuliers pour lesquels elle ne doit pas le faire au moins temporairement.

Un autre article s’intéresse lui aux pratiques à suivre pour ouvrir concrètement le code source d’un logiciel :

Les éléments fournis dans ces deux sujets pourraient constituer la matière d’un vade-mecum destiné aux services de l’État et aux collectivités territoriales.

1 J'aime

Première raison, inciter à la réutilisation de briques logicielles développées ailleurs.

Deuxième raison, favoriser l’interopérabilité de son logiciel.

Troisième raison, montrer l’exemple !

Quatrième raison, plus sociale, redonner ce qui a été payé par le contribuable.

3 J'aime

Parce que c’est beau :love_letter:

Parce que c’est la seule solution pour que l’utilisateur maîtrise son informatique.

En informatique, soit c’est le logiciel qui maîtrise l’utilisateur, soit c’est l’utilisateur qui maîtrise le logiciel. Et pour que l’utilisateur soit maître de son informatique, la seule solution est qu’il utilise du Logiciel Libre. Il n’y a pas d’alternative.

Sans accès aux sources, pas de sécurité, pas de garantie d’absence de mouchard, pas d’information sur ce qui est fait des données personnelles de l’utilisateur, etc.

Tout éditeur de logiciel ou tout éditeur d’un site web qui empêche les utilisateurs d’accéder aux sources des logiciels et donc de maîtriser leur informatique, ces éditeurs ne peuvent recevoir la confiance des utilisateurs.

3 J'aime

Parce que:

  • ça rend possible l’audibilité du code par tous:
    • découverte des failles au plus tôt => correction au plus tôt
    • aide à accepter que la sécurité n’est pas dans le secret d’un protocole mais dans sa robustesse (il vaut mieux discuter d’une faille et la corriger que de penser que le fait de la cacher la rende invisible)
  • ça autorise la contribution externe:
    • bug reports
    • bug fixes
    • features
    • documentation
  • ça permet la personnalisation sans dépendre de l’éditeur (pas toujours disponibles, pas toujours toujours enclin à répondre à votre besoin ultra spécifique)
  • ça décorrèle la durée de vie du logiciel de celle de son éditeur initial (le rendant la plupart du temps plus pérenne)
    • (merci à tous les éditeurs qui lors de leur dépôt de bilan ont eu l’amabilité de libérer le code de leurs solutions)
  • ça aide à être plus humble :slightly_smiling:
3 J'aime

Oui, c’est très bien tout ça. Mais pour maîtriser son informatique, (je suis utilisateur avancé), quel investissement dois-je consentir pour être en mesure non seulement de déchiffrer du code mais ensuite de pouvoir se metttre au service du bien commun pour servir le logiciel dit libre ?

Merci pour votre réponse qui éclairera non seulement ma lanterne mais celle de beaucoup d’autres qui n’ont pas encore oser poser la question !

Si le logiciel libre est une condition nécessaire à la maîtrise de son informatique, déchiffrer du code n’en est pas une. En effet, le fait de pouvoir exercer votre liberté en la déléguant est suffisant pour vous garantir la maîtrise indispensable.
Soit vous déléguez votre liberté octroyée par la licence libre, soit vous profitez du travail de vérification d’autres utilisateurs partageant la même liberté.

Pas besoin de savoir coder ou déchiffrer du code pour participer à des projets de logiciel libre. Il faut savoir que dans l’industrie, le codage d’un logiciel représente seulement 30 % d’un projet informatique. Le reste est consacré aux spécifications des besoins, à la définition de la solution, la rédaction des manuels, les tests, la formation, etc.

Ce dont manquent beaucoup de projet de logiciels libres, ce sont des utilisateurs avertis capables de décrire fonctionnellement ce qu’il faudrait comme résultat. Capable aussi de tester et d’accompagner les codeurs pour aller dans la bonne direction fonctionnelle.

Donc, ne vous sentez pas exclus ou impuissant si vous ne savez pas coder. Vous pouvez :

  • traduire les interfaces ;
  • faire des tests ;
  • remonter des rapports de bugs ;
  • proposer de nouvelles fonctionnalités ;
  • rédiger des manuels et des documentations ;
  • faire des formations ;
  • maîtriser une problématique métier ;
  • etc.

Participer à la gouvernance d’un logiciel libre est l’un des apports majeurs que tout le monde peut faire sans savoir coder. :slightly_smiling:

J’ai commencé un diagramme présentant les différents arguments sur l’ouverture du code source :

C’est une expérimentation du logiciel argüman. Vous pouvez y contribuer.

3 J'aime

Attention au vocabulaire employé.
La question est-elle:

  • Pourquoi ouvrir le code source d’un logiciel?
  • ou Pourquoi libérer le code source d’un logiciel?

Les deux questions ne sont pas équivalentes et appellent à des réponses différentes.

1 J'aime

@Charly Bonne remarque. L’argumentaire doit chercher à expliquer les deux : pourquoi ouvrir les codes sources des logiciels du secteur public et pourquoi les placer sous une licence libre.

Pour être en mesure de déchiffrer du code, il faut apprendre un ou plusieurs langages informatiques, ce n’est pas trop compliqué car la plupart des langages informatiques de haut niveau sont relativement proches du langage naturel - de l’anglais et on trouve aisément de nombreux cours gratuits et turtoriels sur internet, par contre il faut y investir du temps …
Quelques liens pour apprendre (je commence par France Université Numérique - FUN - qui est un GIP émanant de l’ensignement supérieur - CINES / RENATER / INRIA ) :

Il y a plusieurs façons de « se mettre au service du bien commun pour servir le logiciel libre » qu’on sache ou non programmer :

  • la plupart des logiciels libres ont des contraintes de fonctionnement aussi il est possible d’y participer financièrement ;
  • il est également possible de participer à leur développement en s’impliquant dans la traduction de leur interface utilisateur (il existe sous linux plusieurs logiciels d’aide à la traduction)
  • enfin on peut s’impliquer en tant que testeur en faisant remonter les bugs que l’on constate aux équipes de développement des logiciels