« Logiciels Publics Logiciels Libres » : différence entre les versions
De April MediaWiki
Aller à la navigationAller à la recherche
(création de la page) |
m (style) |
||
(5 versions intermédiaires par 3 utilisateurs non affichées) | |||
Ligne 8 : | Ligne 8 : | ||
===Les arguments contre=== | ===Les arguments contre=== | ||
*Énormément de logiciels sont des logiciels | *Énormément de logiciels sont des logiciels métier spécifiques et n'ont aucune vocation à être utilisés hors de leur environnement d'origine, pour lequel ils sont souvent développés a façon. Pour rappel, une feuille de tableur, la page d'un intranet, un script shell, etc. sont des logiciels... | ||
*Un certain nombre de logiciels n' | *Un certain nombre de logiciels n'a vocation à être utilisé qu'entre des services de l’État. Pourquoi seraient-ils libres puisque ils ne sont même pas distribués ? | ||
*Certes, le fait qu'un logiciel soit libre permet de l'adapter mais dans un état colbertiste tel que le nôtre, certains « services » ont bien d'autres moyens d'imposer leur volonté aux autres. Par exemple, alors qu'on parle toujours plus de décentralisation, un mouvement inverse se dessine au sein des administrations : les ministères concentrent de plus en plus les pouvoirs, les outils et les données et contraignent les services des régions à utiliser les services centralisés. Cela se fait au nom de la rationalisation et de l'économie d'échelle mais derrière ce discours de façade, une vraie lutte de pouvoir est engagée et il s'agit bien de tenir les régions en laisse. | *Certes, le fait qu'un logiciel soit libre permet de l'adapter mais dans un état colbertiste tel que le nôtre, certains « services » ont bien d'autres moyens d'imposer leur volonté aux autres. Par exemple, alors qu'on parle toujours plus de décentralisation, un mouvement inverse se dessine au sein des administrations : les ministères concentrent de plus en plus les pouvoirs, les outils et les données et contraignent les services des régions à utiliser les services centralisés. Cela se fait au nom de la rationalisation et de l'économie d'échelle mais derrière ce discours de façade, une vraie lutte de pouvoir est engagée et il s'agit bien de tenir les régions en laisse. | ||
===Les arguments pour=== | ===Les arguments pour=== | ||
* Un logiciel libre ne doit pas forcement être distribué au grand public. Voir la positions formalisée de l'April | * Un logiciel libre ne doit pas forcement être distribué au grand public. Voir la positions formalisée de l'April à ce sujet : [http://www.april.org/position-sur-lutilisation-de-larticle-3a-de-la-gnu-gpl Position sur l'utilisation de l'article 3a de la GNU GPL] | ||
*A partir du moment | *A partir du moment où des utilisateurs ne sont pas les développeurs du logiciel qu'ils utilisent, il semble souhaitable que ces utilisateurs bénéficient des quatre libertés. Et cela que l'on raisonne sur des individus ou sur des structures. | ||
*Par exemple dans le cas d'un logiciel utilisés par plusieurs services de | *Par exemple dans le cas d'un logiciel utilisés par plusieurs services de l’État, il faut que chaque service puisse rester maitre de son informatique, pour ne pas se retrouver à dépendre d'un autre service. Si les logiciels sont libres, il est possible d'adapter le code localement. Sinon cela devient un moyen de pression d'un service sur un autre. | ||
*Un des problèmes rencontrés dans les grosses organisations et notamment dans les organisations publiques est la pérennisation des développements à façon. Ça devient un tel problème que dans certaines organisations, ils préfèrent investir dans des solutions propriétaires plutôt que d'avoir à potentiellement maintenir des solutions faites maison alors que ces dernières coûtent notablement moins chers en développement, déploiement, ... | |||
**Publier son code source impose au développeur un cadre de travail et l'application de bonnes pratiques qu'il n'est pas encouragé à faire si son code n'est pas publié. De même, on gagne beaucoup de temps en administration système sur une application dont le code a été pensé pour être publié (même lorsqu'on est le seul utilisateur). On a moins de chance de retrouver des fichiers de configuration dans tous les sens, des mots de passe dans le code, ... | |||
**Enfin, ça oblige les développeurs à archiver leurs codes et à utiliser des serveurs de version. Chose bien utile dans un projet même petit mais si peu utilisé pour ce type de projet. | |||
**D'un simple point de vue « génie logiciel », c'est terriblement efficace pour une organisation de publier le code de ses applications. | |||
*L'innovation fonctionne de manière tout à fait surprenante. Il est difficile de dire qu'un élément n'intéresse personne à part l'État. Si les outils développés spécifiquement pour certains services de l'état étaient rendus publiques, ça intéresserait beaucoup de monde. | |||
**Il existe par exemple l'histoire du logiciel qui réalisait la codification des nos lois et décrets (Magicode). C'est un petit logiciel fait de macros VB qui n'avait vocation à n'être utilisé que par le service de la codification du Premier ministre. Il se trouve que même si il est techniquement inintéressant et propriétaire, il répond bien aux besoins et ses utilisateurs en ont fait la publicité au sein de l'état. Il est maintenant utilisé jusque dans l'administration japonaise et nombre de préfecture souhaitent l'acquérir à prix d'or. Un exemple de développement qui n'intéresse à priori personne mis à part l'utilisateur final à qui il est destiné. Si ce développement avait été un développement libre, des investissements auraient pu être fait sur les fonctionnalités de codification qui est une problématique où l'informatique a encore beaucoup de service à rendre aux juristes. | |||
**Enfin, le libre (logiciel, informatique ou données) a beaucoup à apporter pour réduire les silos/orgues administratifs. L’État comme toute grosse structure a beaucoup de problèmes pour organiser sa communication interne. En matière de logiciel, rendre plus populaire les initiatives de développement de logiciel libre permettrait de rendre les investissements informatiques plus visibles des autres "services" (par les contributions) et donc inciter à la mutualisation informatique. Les contributions de la gendarmerie aux projets GLPI/OSC/Fusion est un exemple : OCS-inventory (et les versions qui en ont découlé) est né d'un projet interne à la gendarmerie. C'est donc un bon exemple de besoin spécifique d'avoir un outil d'inventaire et de télédistribution de soft qui est devenu un projet libre. | |||
*Pour les collectivités territoriales, le logiciel libre serait un bon moyen de mutualiser sans monter des usines à gaz organisationnelles. Par exemple dans le domaine de l'information transport public, des collectivités se sont tourné autour pendant 10 ans avant de parvenir à s'entendre sur un projet commun pas très impressionnants au final. | |||
Vous pouvez noter vos remarques sur la page de discussion. | ==Remarques== | ||
Vous pouvez noter vos remarques sur la [[Discuter:Logiciels Publics Logiciels Libres|page de discussion]]. |
Dernière version du 26 mars 2011 à 21:13
![]() |
Bienvenue sur un argumentaire | ![]() |
du groupe de travail Sensibilisation |
Cette page présente un argumentaire en cours de réalisation.
Si vous souhaitez participer, n'hésitez pas à laisser votre avis sur la page de discussion en suivant au mieux ces recommandations.
Est-il souhaitable que tout logiciel développé avec de l'argent public soit un logiciel libre ?
Présentation[modifier]
Cette page propose un argumentaire, en cours de rédaction, pour définir s'il serait souhaitable que tout logiciel développé avec de l'argent public soit un logiciel libre.
Les arguments contre[modifier]
- Énormément de logiciels sont des logiciels métier spécifiques et n'ont aucune vocation à être utilisés hors de leur environnement d'origine, pour lequel ils sont souvent développés a façon. Pour rappel, une feuille de tableur, la page d'un intranet, un script shell, etc. sont des logiciels...
- Un certain nombre de logiciels n'a vocation à être utilisé qu'entre des services de l’État. Pourquoi seraient-ils libres puisque ils ne sont même pas distribués ?
- Certes, le fait qu'un logiciel soit libre permet de l'adapter mais dans un état colbertiste tel que le nôtre, certains « services » ont bien d'autres moyens d'imposer leur volonté aux autres. Par exemple, alors qu'on parle toujours plus de décentralisation, un mouvement inverse se dessine au sein des administrations : les ministères concentrent de plus en plus les pouvoirs, les outils et les données et contraignent les services des régions à utiliser les services centralisés. Cela se fait au nom de la rationalisation et de l'économie d'échelle mais derrière ce discours de façade, une vraie lutte de pouvoir est engagée et il s'agit bien de tenir les régions en laisse.
Les arguments pour[modifier]
- Un logiciel libre ne doit pas forcement être distribué au grand public. Voir la positions formalisée de l'April à ce sujet : Position sur l'utilisation de l'article 3a de la GNU GPL
- A partir du moment où des utilisateurs ne sont pas les développeurs du logiciel qu'ils utilisent, il semble souhaitable que ces utilisateurs bénéficient des quatre libertés. Et cela que l'on raisonne sur des individus ou sur des structures.
- Par exemple dans le cas d'un logiciel utilisés par plusieurs services de l’État, il faut que chaque service puisse rester maitre de son informatique, pour ne pas se retrouver à dépendre d'un autre service. Si les logiciels sont libres, il est possible d'adapter le code localement. Sinon cela devient un moyen de pression d'un service sur un autre.
- Un des problèmes rencontrés dans les grosses organisations et notamment dans les organisations publiques est la pérennisation des développements à façon. Ça devient un tel problème que dans certaines organisations, ils préfèrent investir dans des solutions propriétaires plutôt que d'avoir à potentiellement maintenir des solutions faites maison alors que ces dernières coûtent notablement moins chers en développement, déploiement, ...
- Publier son code source impose au développeur un cadre de travail et l'application de bonnes pratiques qu'il n'est pas encouragé à faire si son code n'est pas publié. De même, on gagne beaucoup de temps en administration système sur une application dont le code a été pensé pour être publié (même lorsqu'on est le seul utilisateur). On a moins de chance de retrouver des fichiers de configuration dans tous les sens, des mots de passe dans le code, ...
- Enfin, ça oblige les développeurs à archiver leurs codes et à utiliser des serveurs de version. Chose bien utile dans un projet même petit mais si peu utilisé pour ce type de projet.
- D'un simple point de vue « génie logiciel », c'est terriblement efficace pour une organisation de publier le code de ses applications.
- L'innovation fonctionne de manière tout à fait surprenante. Il est difficile de dire qu'un élément n'intéresse personne à part l'État. Si les outils développés spécifiquement pour certains services de l'état étaient rendus publiques, ça intéresserait beaucoup de monde.
- Il existe par exemple l'histoire du logiciel qui réalisait la codification des nos lois et décrets (Magicode). C'est un petit logiciel fait de macros VB qui n'avait vocation à n'être utilisé que par le service de la codification du Premier ministre. Il se trouve que même si il est techniquement inintéressant et propriétaire, il répond bien aux besoins et ses utilisateurs en ont fait la publicité au sein de l'état. Il est maintenant utilisé jusque dans l'administration japonaise et nombre de préfecture souhaitent l'acquérir à prix d'or. Un exemple de développement qui n'intéresse à priori personne mis à part l'utilisateur final à qui il est destiné. Si ce développement avait été un développement libre, des investissements auraient pu être fait sur les fonctionnalités de codification qui est une problématique où l'informatique a encore beaucoup de service à rendre aux juristes.
- Enfin, le libre (logiciel, informatique ou données) a beaucoup à apporter pour réduire les silos/orgues administratifs. L’État comme toute grosse structure a beaucoup de problèmes pour organiser sa communication interne. En matière de logiciel, rendre plus populaire les initiatives de développement de logiciel libre permettrait de rendre les investissements informatiques plus visibles des autres "services" (par les contributions) et donc inciter à la mutualisation informatique. Les contributions de la gendarmerie aux projets GLPI/OSC/Fusion est un exemple : OCS-inventory (et les versions qui en ont découlé) est né d'un projet interne à la gendarmerie. C'est donc un bon exemple de besoin spécifique d'avoir un outil d'inventaire et de télédistribution de soft qui est devenu un projet libre.
- Pour les collectivités territoriales, le logiciel libre serait un bon moyen de mutualiser sans monter des usines à gaz organisationnelles. Par exemple dans le domaine de l'information transport public, des collectivités se sont tourné autour pendant 10 ans avant de parvenir à s'entendre sur un projet commun pas très impressionnants au final.
Remarques[modifier]
Vous pouvez noter vos remarques sur la page de discussion.