3. Hors du labo, au grand air

La croissance des communautés open source autour des projets universitaires

par Markus Kroëtzsch

Markus Kroëtzsch est post-doctorant au Département des Sciences Informatiques de l’Université d’Oxford. Il a soutenu son doctorat en 2010 à l’Institut d’Informatique Appliquée et Méthodes Formelles de description du Karlsruhe Institute of Technology. Ses recherches portent sur le traitement automatique de l’information, depuis les fondements de la représentation de la connaissance formelle jusqu’à leurs domaines d’application, tel le Web Sémantique. Il est le développeur principal de la plate-forme Semantic MediaWiki, application de Web sémantique, co-éditeur des spécifications W3C OWL2, administrateur principal du portail communautaire semanticweb.org, et co-auteur de l’ouvrage Foundations of Semantic Web Technologies. 

Au sein des universités, les chercheurs développent de grandes quantités de logiciels, que ce soit pour valider une hypothèse, pour illustrer une nouvelle approche, ou tout simplement comme outil en appui à une étude. Dans la plupart des cas, un petit prototype dédié fait le travail, et il est déployé rapidement tandis que l’enjeu de la recherche évolue. Cependant, de temps à autres, une nouvelle approche ou une technologie émergente a le potentiel de changer complétement la manière de résoudre un problème. Ce faisant, cela génère de la réputation professionnelle, du succès commercial, et la gratification personnelle d’amener une nouvelle idée à son plein potentiel. Le chercheur qui a fait une découverte de ce genre est alors tenté d’aller au-delà du prototype vers un produit qui sera réellement utilisé. Il est alors confronté à une toute nouvelle série de problèmes pratiques.

La peur de l’utilisateur

Dans l’un de ses célèbres essais sur l’ingénierie logicielle, Frederick P. Brooks, Jr. permet de se faire une bonne idée des efforts liés à la maintenance d’un vrai logiciel et nous met en garde contre l’utilisateur :

« Le coût total de la maintenance d’un programme largement utilisé est habituellement de 40% ou plus de son coût de développement. De façon surprenante, ce coût est fortement influencé par le nombre d’utilisateurs. Plus il y a d’utilisateurs, plus il y a de bugs » [1]

Bien que les chiffres soient probablement différents dans le contexte actuel, la remarque reste fondamentalement vraie. Elle pourrait même avoir été confirmée par l’usage généralisé de la communication instantanée. Pire encore : davantage d’utilisateurs ne produit pas seulement davantage de bugs ; en général, ils expriment aussi plus de demandes. Qu’il s’agisse d’une véritable erreur, d’une demande de fonctionnalité, ou tout simplement d’une mauvaise compréhension du fonctionnement du logiciel, les demandes de l’utilisateur lambda ne ressemblent en rien à un rapport de bug précis et technique. Et chaque demande requiert l’attention des développeurs et occupe un temps précieux qui n’est plus disponible pour écrire du code.

Avec son esprit d’analyse, le chercheur anticipe sur ce problème. Dans sa lutte naturelle pour éviter un avenir sombre dans le service client, il peut carrément développer de la peur envers l’utilisateur. Dans le pire des cas, cela peut le mener à prendre des décisions qui vont à l’encontre du projet dans son ensemble ; sous des formes plus légères, cela peut tout de même mener le chercheur à cacher des produits logiciels brillants à ses utilisateurs potentiels. Plus d’une fois, j’ai entendu des chercheurs dire : « Nous n’avons pas besoin de plus de visibilité : nous recevons déjà suffisamment d’emails ! ». Il est vrai que parfois la communication pour un outil logiciel nécessite un effort supérieur à celui que peut fournir un chercheur sans laisser tomber son emploi principal.

Pourtant, cette issue tragique aurait bien souvent pu être évitée. Brooks pouvait difficilement l’anticiper. Quand il a écrit ses essais, le fait est que les utilisateurs étaient des clients et que la maintenance logicielle faisait partie du produit qu’ils achetaient. Il fallait trouver un équilibre entre l’effort de développement, la demande du marché, et le prix. C’est toujours le cas pour de nombreux produits logiciels commerciaux de nos  jours, mais ça a peu de choses à voir avec la réalité du développement à petite échelle de l’open source. Les utilisateurs habituels de l’open source ne paient pas pour le service qu’ils reçoivent. Leur attitude n’est donc pas celle d’un client exigeant, mais bien plus souvent celle d’un partisan enthousiaste et reconnaissant. Transformer cet enthousiasme en un soutien plus que nécessaire n’est pas négligeable pour réussir dans l’art de la maintenance d’un logiciel open source : l’intérêt croissant de l’utilisateur doit aller de pair avec une contribution croissante.

Reconnaitre que les utilisateurs de logiciels open source ne sont pas que « des consommateurs qui ne paient pas » est une notion importante. Mais cela ne doit pas mener à surestimer leur potentiel. Le contre-pied optimiste de la peur irrationnelle de l’utilisateur est la croyance que des communautés actives croissent naturellement avec pour seule base la licence choisie pour publier le code. Cette grave erreur de jugement est bizarrement toujours aussi commune, et a scellé le destin de bien des tentatives de création de communautés ouvertes.

Semer et récolter

Le pluriel d’ « utilisateur » n’est pas « communauté ». Si l’un peut s’accroître en nombre, l’autre ne grandit pas d’elle-même, ou alors elle grandit sans direction et surtout sans fournir le soutien espéré au projet. La mission du responsable de projet qui cherche à profiter de l’énergie brute des utilisateurs ressemble à celle d’un jardinier qui doit préparer un terrain fertile, planter et arroser les semis, et peut-être élaguer les pousses non désirées avant de pouvoir récolter les fruits. Par rapport aux récompenses, l’investissement global est minime, mais il est essentiel de faire les bonnes choses, au bon moment.

Préparer le support technologique

Créer une communauté commence avant même que le premier utilisateur n’apparaisse. D’emblée, le choix du langage de programmation va déterminer le nombre de personnes qui pourront déployer et déboguer notre code. Objective Caml est sans doute un beau langage, mais si l’on utilise plutôt Java, la quantité d’utilisateurs et de contributeurs potentiels augmentera de plusieurs ordres de grandeur. Les développeurs doivent donc faire des compromis puisque la technologie la plus répandue est rarement la plus performante ou la plus élégante. Cela peut être une démarche particulièrement difficile pour des chercheurs qui privilégient souvent la supériorité formelle du langage. Quand je travaillais sur Semantic MediaWiki, on m’a souvent demandé pourquoi nous utilisions PHP alors que Java côté serveur serait tellement plus propre et performant. Comparons la taille de la communauté de Semantic MediaWiki et les efforts que demanderait le même développement basé sur du Java : voilà peut-être un début de réponse. Cet exemple illustre aussi que l’audience ciblée détermine le meilleur choix de la technologie de base. Le développeur lui-même devrait avoir le recul nécessaire pour prendre la décision la plus opportune.

Préparer minutieusement le terrain

Dans le même ordre d’idées, il faut créer un code lisible et bien documenté dès le début. Dans un environnement universitaire, certains projets logiciels rassemblent de nombreux contributeurs temporaires. Les changements dans les plannings et les projets des étudiants peuvent nuire à la qualité du code. Je me souviens d’un petit projet de logiciel à l’Université technique de Dresde qui avait été très bien maintenu par un assistant étudiant. Après son départ, on a constaté que le code était minutieusement documenté… en turc. Un chercheur ne peut être programmeur qu’à temps partiel, une discipline particulière est donc nécessaire pour mettre en œuvre le travail supplémentaire indispensable à l’élaboration d’un code accessible. En retour il y aura de bien meilleures chances par la suite d’avoir de bons rapports de bogues, des patchs utiles ou même des développeurs extérieurs.

Semer les graines des communautés

Les développeurs open source inexpérimentés considèrent souvent comme un grand moment la publication ouverte de leur code. En réalité, personne d’autre qu’eux ne la remarquera. Pour attirer aussi bien des utilisateurs que des contributeurs, il faut faire passer le mot. La communication publique d’un vrai projet devrait au moins inclure des annonces à chaque nouvelle version. Les listes de diffusion sont probablement le meilleur canal pour cela. Il faut un certain talent social pour trouver le juste équilibre entre le spam indésirable et la litote timide. Si un projet est motivé par la conviction sincère qu’il aidera les utilisateurs à résoudre de vrais problèmes, ce devrait être facile de lui faire une publicité convenable. Les utilisateurs feront vite la différence entre publicité éhontée et information utile. Bien évidemment, les annonces actives devront attendre que le projet soit finalisé. Cela ne concerne pas seulement le code, mais aussi la page d’accueil et la documentation d’utilisation basique.

Au cours de sa vie, le projet devrait être mentionné dans tous les endroits adéquats, y compris des sites web — à commencer par votre page d’accueil ! — des conférences, des papiers scientifiques, des discussions en ligne. On ne dira jamais assez le pouvoir du simple lien qui conduira un futur contributeur important sur le site du projet dès sa première visite. Les chercheurs ne doivent pas non plus oublier de publier leur logiciel en dehors de leur communauté universitaire proche. Les autres chercheurs sont rarement la meilleure base pour une communauté active.

Fournir des espaces pour grandir

Banal mais souvent négligé, le devoir des personnes qui maintiennent le projet est de fournir des espaces de communication afin que la communauté puisse se développer. Si un projet n’a pas de liste de discussion dédiée, alors toutes les demandes d’aide seront envoyées en message privé à la maintenance. S’il n’y a pas de bugtracker (NdT : logiciel de suivi de problèmes), les rapports de bogues seront moins nombreux et moins utiles. Sans un wiki éditable par tout un chacun pour la documentation utilisateur, le développeur est condamné à étendre et à réécrire la documentation en permanence. Si la version de développement du code source n’est pas accessible, alors les utilisateurs ne seront pas dans la capacité de tester la dernière version avant de se plaindre de problèmes. Si le dépôt de code est intrinsèquement fermé, il n’est alors pas possible d’accueillir des contributeurs externes. Toute cette infrastructure est disponible gratuitement par l’intermédiaire d’un certain nombre de fournisseurs de service. Toutes les formes d’interaction ne sont pas forcément désirées, par exemple, il y a des raisons de garder fermé le cercle des développeurs. Mais il serait inconscient d’espérer le soutien d’une communauté sans même préparer des espaces de base pour celle-ci.

Encourager et contrôler la croissance

Les développeurs inexpérimentés sont souvent préoccupés par le fait que l’ouverture de listes de diffusions, de forums et de wikis pour les utilisateurs nécessitera une maintenance supplémentaire. C’est rarement le cas, mais certaines activités de base sont bien entendu indispensables. Cela commence par la mise en œuvre rigoureuse des usages de communication publique. Les utilisateurs ont besoin d’apprendre à poser des questions publiquement, à consulter la documentation avant de poser des questions, et à rapporter les bogues à l’aide du bugtracker plutôt que par e-mail. J’ai tendance à rejeter toutes les demandes d’aide privées, ou à répondre via des listes publiques. Cela garantit au passage que les solutions sont disponibles sur le web pour les futurs utilisateurs qui les chercheront. Dans tous les cas, les utilisateurs doivent être remerciés explicitement pour toutes les formes de contributions : il faut beaucoup d’enthousiasme et des gens bien intentionnés pour construire une communauté solide.

Quand on atteint un certain nombre d’utilisateurs, une aide mutuelle commence à se mettre en place entre eux. C’est toujours un moment magique pour un projet et c’est un signe évident qu’il est sur la bonne voie. Dans l’idéal, les responsables du projet devraient continuer d’apporter leur aide pour les questions délicates, mais à un moment donné certains utilisateurs vont faire preuve d’initiative dans les discussions. Il est important de les remercier (personnellement) et de les impliquer d’avantage dans le projet. À l’inverse, les évolutions malsaines doivent être stoppées dès que possible, en particulier les comportements agressifs qui peuvent être un véritable danger pour le développement de la communauté. De même, l’enthousiasme le mieux intentionné n’est pas toujours productif et il faut parfois savoir dire non — gentiment mais clairement – pour éviter les dérapages possibles.

Le futur est ouvert

Construire une communauté initiale autour d’un projet contribue fortement à transformer un prototype de recherche en un logiciel open source. Si ça porte ses fruits, il existe de nombreuses options pour le développer en fonction des buts fixés par le mainteneur du projet et la communauté. Voici quelques indications :

Persévérer dans l’expansion du projet et de sa communauté open source, augmenter le nombre de personnes ayant des droits de contributions « directs », en réduisant la dépendance à son origine universitaire. Par ce biais, vous impliquez plus fortement la communauté – notamment au travers d’événements dédiés –;et vous pourrez établir un soutien organisationnel.

Créer une entreprise commerciale pour exploiter le projet, basée, par exemple, sur une double licence ou un business model de consultant. Des outils ayant fait leurs preuves et une communauté active sont des atouts majeurs dès le lancement d’une entreprise, et peuvent être bénéfiques dans chacune de vos stratégies d’entreprise sans abandonner le produit original open source.

Se retirer du projet. Il y a de nombreuses raisons pour qu’on ne puisse plus maintenir de lien avec le projet. Le fait d’avoir établi une communauté saine et ouverte maximise les chances pour que le projet continue de voler de ses propres ailes. Dans tous les cas, il est plus correct de faire une coupure nette que d’abandonner silencieusement le projet, en le tuant par une activité en chute libre au point qu’on ne trouve plus personne pour le maintenir.

Le profil de la communauté sera différent selon qu’on opte pour telle ou telle stratégie de développement. Mais dans tous les cas, le rôle du chercheur évolue en fonction des objectifs du projet. Le scientifique initial et le programmeur pourront prendre le rôle de gestionnaire ou de directeur technique. En ce sens, la différence principale entre un projet de logiciel open source d’importance et la recherche perpétuelle d’un prototype n’est pas tant la quantité de travail mais le type de travail nécessaire pour y arriver. Cela compte pour beaucoup dans sa réussite. Une fois qu’on l’a compris, il ne reste plus qu’à réaliser un super logiciel.

[1] Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on  Software Engineering. Anniversary Edition. Addison-Wesley, 1995.

3. Hors du labo, au grand air

La croissance des communautés open source autour des projets universitaires

par Markus Kroëtzsch

Markus Kroëtzsch est post-doctorant au Département des Sciences Informatiques de l’Université d’Oxford. Il a soutenu son doctorat en 2010 à l’Institut d’Informatique Appliquée et Méthodes Formelles de description du Karlsruhe Institute of Technology. Ses recherches portent sur le traitement automatique de l’information, depuis les fondements de la représentation de la connaissance formelle jusqu’à leurs domaines d’application, tel le Web Sémantique. Il est le développeur principal de la plate-forme Semantic MediaWiki, application de Web sémantique, co-éditeur des spécifications W3C OWL2, administrateur principal du portail communautaire semanticweb.org, et co-auteur de l’ouvrage Foundations of Semantic Web Technologies. 

Au sein des universités, les chercheurs développent de grandes quantités de logiciels, que ce soit pour valider une hypothèse, pour illustrer une nouvelle approche, ou tout simplement comme outil en appui à une étude. Dans la plupart des cas, un petit prototype dédié fait le travail, et il est déployé rapidement tandis que l’enjeu de la recherche évolue. Cependant, de temps à autres, une nouvelle approche ou une technologie émergente a le potentiel de changer complétement la manière de résoudre un problème. Ce faisant, cela génère de la réputation professionnelle, du succès commercial, et la gratification personnelle d’amener une nouvelle idée à son plein potentiel. Le chercheur qui a fait une découverte de ce genre est alors tenté d’aller au-delà du prototype vers un produit qui sera réellement utilisé. Il est alors confronté à une toute nouvelle série de problèmes pratiques.

La peur de l’utilisateur

Dans l’un de ses célèbres essais sur l’ingénierie logicielle, Frederick P. Brooks, Jr. permet de se faire une bonne idée des efforts liés à la maintenance d’un vrai logiciel et nous met en garde contre l’utilisateur :

« Le coût total de la maintenance d’un programme largement utilisé est habituellement de 40% ou plus de son coût de développement. De façon surprenante, ce coût est fortement influencé par le nombre d’utilisateurs. Plus il y a d’utilisateurs, plus il y a de bugs » [1]

Bien que les chiffres soient probablement différents dans le contexte actuel, la remarque reste fondamentalement vraie. Elle pourrait même avoir été confirmée par l’usage généralisé de la communication instantanée. Pire encore : davantage d’utilisateurs ne produit pas seulement davantage de bugs ; en général, ils expriment aussi plus de demandes. Qu’il s’agisse d’une véritable erreur, d’une demande de fonctionnalité, ou tout simplement d’une mauvaise compréhension du fonctionnement du logiciel, les demandes de l’utilisateur lambda ne ressemblent en rien à un rapport de bug précis et technique. Et chaque demande requiert l’attention des développeurs et occupe un temps précieux qui n’est plus disponible pour écrire du code.

Avec son esprit d’analyse, le chercheur anticipe sur ce problème. Dans sa lutte naturelle pour éviter un avenir sombre dans le service client, il peut carrément développer de la peur envers l’utilisateur. Dans le pire des cas, cela peut le mener à prendre des décisions qui vont à l’encontre du projet dans son ensemble ; sous des formes plus légères, cela peut tout de même mener le chercheur à cacher des produits logiciels brillants à ses utilisateurs potentiels. Plus d’une fois, j’ai entendu des chercheurs dire : « Nous n’avons pas besoin de plus de visibilité : nous recevons déjà suffisamment d’emails ! ». Il est vrai que parfois la communication pour un outil logiciel nécessite un effort supérieur à celui que peut fournir un chercheur sans laisser tomber son emploi principal.

Pourtant, cette issue tragique aurait bien souvent pu être évitée. Brooks pouvait difficilement l’anticiper. Quand il a écrit ses essais, le fait est que les utilisateurs étaient des clients et que la maintenance logicielle faisait partie du produit qu’ils achetaient. Il fallait trouver un équilibre entre l’effort de développement, la demande du marché, et le prix. C’est toujours le cas pour de nombreux produits logiciels commerciaux de nos  jours, mais ça a peu de choses à voir avec la réalité du développement à petite échelle de l’open source. Les utilisateurs habituels de l’open source ne paient pas pour le service qu’ils reçoivent. Leur attitude n’est donc pas celle d’un client exigeant, mais bien plus souvent celle d’un partisan enthousiaste et reconnaissant. Transformer cet enthousiasme en un soutien plus que nécessaire n’est pas négligeable pour réussir dans l’art de la maintenance d’un logiciel open source : l’intérêt croissant de l’utilisateur doit aller de pair avec une contribution croissante.

Reconnaitre que les utilisateurs de logiciels open source ne sont pas que « des consommateurs qui ne paient pas » est une notion importante. Mais cela ne doit pas mener à surestimer leur potentiel. Le contre-pied optimiste de la peur irrationnelle de l’utilisateur est la croyance que des communautés actives croissent naturellement avec pour seule base la licence choisie pour publier le code. Cette grave erreur de jugement est bizarrement toujours aussi commune, et a scellé le destin de bien des tentatives de création de communautés ouvertes.

Semer et récolter

Le pluriel d’ « utilisateur » n’est pas « communauté ». Si l’un peut s’accroître en nombre, l’autre ne grandit pas d’elle-même, ou alors elle grandit sans direction et surtout sans fournir le soutien espéré au projet. La mission du responsable de projet qui cherche à profiter de l’énergie brute des utilisateurs ressemble à celle d’un jardinier qui doit préparer un terrain fertile, planter et arroser les semis, et peut-être élaguer les pousses non désirées avant de pouvoir récolter les fruits. Par rapport aux récompenses, l’investissement global est minime, mais il est essentiel de faire les bonnes choses, au bon moment.

Préparer le support technologique

Créer une communauté commence avant même que le premier utilisateur n’apparaisse. D’emblée, le choix du langage de programmation va déterminer le nombre de personnes qui pourront déployer et déboguer notre code. Objective Caml est sans doute un beau langage, mais si l’on utilise plutôt Java, la quantité d’utilisateurs et de contributeurs potentiels augmentera de plusieurs ordres de grandeur. Les développeurs doivent donc faire des compromis puisque la technologie la plus répandue est rarement la plus performante ou la plus élégante. Cela peut être une démarche particulièrement difficile pour des chercheurs qui privilégient souvent la supériorité formelle du langage. Quand je travaillais sur Semantic MediaWiki, on m’a souvent demandé pourquoi nous utilisions PHP alors que Java côté serveur serait tellement plus propre et performant. Comparons la taille de la communauté de Semantic MediaWiki et les efforts que demanderait le même développement basé sur du Java : voilà peut-être un début de réponse. Cet exemple illustre aussi que l’audience ciblée détermine le meilleur choix de la technologie de base. Le développeur lui-même devrait avoir le recul nécessaire pour prendre la décision la plus opportune.

Préparer minutieusement le terrain

Dans le même ordre d’idées, il faut créer un code lisible et bien documenté dès le début. Dans un environnement universitaire, certains projets logiciels rassemblent de nombreux contributeurs temporaires. Les changements dans les plannings et les projets des étudiants peuvent nuire à la qualité du code. Je me souviens d’un petit projet de logiciel à l’Université technique de Dresde qui avait été très bien maintenu par un assistant étudiant. Après son départ, on a constaté que le code était minutieusement documenté… en turc. Un chercheur ne peut être programmeur qu’à temps partiel, une discipline particulière est donc nécessaire pour mettre en œuvre le travail supplémentaire indispensable à l’élaboration d’un code accessible. En retour il y aura de bien meilleures chances par la suite d’avoir de bons rapports de bogues, des patchs utiles ou même des développeurs extérieurs.

Semer les graines des communautés

Les développeurs open source inexpérimentés considèrent souvent comme un grand moment la publication ouverte de leur code. En réalité, personne d’autre qu’eux ne la remarquera. Pour attirer aussi bien des utilisateurs que des contributeurs, il faut faire passer le mot. La communication publique d’un vrai projet devrait au moins inclure des annonces à chaque nouvelle version. Les listes de diffusion sont probablement le meilleur canal pour cela. Il faut un certain talent social pour trouver le juste équilibre entre le spam indésirable et la litote timide. Si un projet est motivé par la conviction sincère qu’il aidera les utilisateurs à résoudre de vrais problèmes, ce devrait être facile de lui faire une publicité convenable. Les utilisateurs feront vite la différence entre publicité éhontée et information utile. Bien évidemment, les annonces actives devront attendre que le projet soit finalisé. Cela ne concerne pas seulement le code, mais aussi la page d’accueil et la documentation d’utilisation basique.

Au cours de sa vie, le projet devrait être mentionné dans tous les endroits adéquats, y compris des sites web — à commencer par votre page d’accueil ! — des conférences, des papiers scientifiques, des discussions en ligne. On ne dira jamais assez le pouvoir du simple lien qui conduira un futur contributeur important sur le site du projet dès sa première visite. Les chercheurs ne doivent pas non plus oublier de publier leur logiciel en dehors de leur communauté universitaire proche. Les autres chercheurs sont rarement la meilleure base pour une communauté active.

Fournir des espaces pour grandir

Banal mais souvent négligé, le devoir des personnes qui maintiennent le projet est de fournir des espaces de communication afin que la communauté puisse se développer. Si un projet n’a pas de liste de discussion dédiée, alors toutes les demandes d’aide seront envoyées en message privé à la maintenance. S’il n’y a pas de bugtracker (NdT : logiciel de suivi de problèmes), les rapports de bogues seront moins nombreux et moins utiles. Sans un wiki éditable par tout un chacun pour la documentation utilisateur, le développeur est condamné à étendre et à réécrire la documentation en permanence. Si la version de développement du code source n’est pas accessible, alors les utilisateurs ne seront pas dans la capacité de tester la dernière version avant de se plaindre de problèmes. Si le dépôt de code est intrinsèquement fermé, il n’est alors pas possible d’accueillir des contributeurs externes. Toute cette infrastructure est disponible gratuitement par l’intermédiaire d’un certain nombre de fournisseurs de service. Toutes les formes d’interaction ne sont pas forcément désirées, par exemple, il y a des raisons de garder fermé le cercle des développeurs. Mais il serait inconscient d’espérer le soutien d’une communauté sans même préparer des espaces de base pour celle-ci.

Encourager et contrôler la croissance

Les développeurs inexpérimentés sont souvent préoccupés par le fait que l’ouverture de listes de diffusions, de forums et de wikis pour les utilisateurs nécessitera une maintenance supplémentaire. C’est rarement le cas, mais certaines activités de base sont bien entendu indispensables. Cela commence par la mise en œuvre rigoureuse des usages de communication publique. Les utilisateurs ont besoin d’apprendre à poser des questions publiquement, à consulter la documentation avant de poser des questions, et à rapporter les bogues à l’aide du bugtracker plutôt que par e-mail. J’ai tendance à rejeter toutes les demandes d’aide privées, ou à répondre via des listes publiques. Cela garantit au passage que les solutions sont disponibles sur le web pour les futurs utilisateurs qui les chercheront. Dans tous les cas, les utilisateurs doivent être remerciés explicitement pour toutes les formes de contributions : il faut beaucoup d’enthousiasme et des gens bien intentionnés pour construire une communauté solide.

Quand on atteint un certain nombre d’utilisateurs, une aide mutuelle commence à se mettre en place entre eux. C’est toujours un moment magique pour un projet et c’est un signe évident qu’il est sur la bonne voie. Dans l’idéal, les responsables du projet devraient continuer d’apporter leur aide pour les questions délicates, mais à un moment donné certains utilisateurs vont faire preuve d’initiative dans les discussions. Il est important de les remercier (personnellement) et de les impliquer d’avantage dans le projet. À l’inverse, les évolutions malsaines doivent être stoppées dès que possible, en particulier les comportements agressifs qui peuvent être un véritable danger pour le développement de la communauté. De même, l’enthousiasme le mieux intentionné n’est pas toujours productif et il faut parfois savoir dire non — gentiment mais clairement – pour éviter les dérapages possibles.

Le futur est ouvert

Construire une communauté initiale autour d’un projet contribue fortement à transformer un prototype de recherche en un logiciel open source. Si ça porte ses fruits, il existe de nombreuses options pour le développer en fonction des buts fixés par le mainteneur du projet et la communauté. Voici quelques indications :

Persévérer dans l’expansion du projet et de sa communauté open source, augmenter le nombre de personnes ayant des droits de contributions « directs », en réduisant la dépendance à son origine universitaire. Par ce biais, vous impliquez plus fortement la communauté – notamment au travers d’événements dédiés –;et vous pourrez établir un soutien organisationnel.

Créer une entreprise commerciale pour exploiter le projet, basée, par exemple, sur une double licence ou un business model de consultant. Des outils ayant fait leurs preuves et une communauté active sont des atouts majeurs dès le lancement d’une entreprise, et peuvent être bénéfiques dans chacune de vos stratégies d’entreprise sans abandonner le produit original open source.

Se retirer du projet. Il y a de nombreuses raisons pour qu’on ne puisse plus maintenir de lien avec le projet. Le fait d’avoir établi une communauté saine et ouverte maximise les chances pour que le projet continue de voler de ses propres ailes. Dans tous les cas, il est plus correct de faire une coupure nette que d’abandonner silencieusement le projet, en le tuant par une activité en chute libre au point qu’on ne trouve plus personne pour le maintenir.

Le profil de la communauté sera différent selon qu’on opte pour telle ou telle stratégie de développement. Mais dans tous les cas, le rôle du chercheur évolue en fonction des objectifs du projet. Le scientifique initial et le programmeur pourront prendre le rôle de gestionnaire ou de directeur technique. En ce sens, la différence principale entre un projet de logiciel open source d’importance et la recherche perpétuelle d’un prototype n’est pas tant la quantité de travail mais le type de travail nécessaire pour y arriver. Cela compte pour beaucoup dans sa réussite. Une fois qu’on l’a compris, il ne reste plus qu’à réaliser un super logiciel.

[1] Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on  Software Engineering. Anniversary Edition. Addison-Wesley, 1995.

Tous les autres pourraient avoir tort, mais c’est peu probable

par Evan Prodromou

Evan Prodromou est le fondateur de Wikitravel, StatusNet et du réseau social Open Source Identi.ca. Il participe aux logiciels Open Source depuis 15 ans en tant que développeur, écrit de la documentation et se distingue à l’occasion comme agitateur. Il vit au Québec, à Montréal. 

La plus importante caractéristique du fondateur d’un projet Open Source, dans les premières semaines ou premiers mois avant de lancer son logiciel dans le monde, c’est une obstination de tête de mule face à l’écrasante évidence des faits. Si votre logiciel est si important, pourquoi personne ne l’a-t-il déjà écrit ? Peut-être que ce n’est même pas possible. Peut-être que personne d’autre que vous ne veut ce que vous êtes en train de faire. Peut-être que vous n’êtes pas assez bon pour le faire. Peut-être que quelqu’un l’a déjà fait et que vous n’êtes simplement pas assez malin pour le trouver avec Google. 

Garder la foi à travers cette longue et sombre nuit est difficile ; seules les têtes de cochons opiniâtres et bornées peuvent y parvenir. Et nous arrivons à l’application de nos opinions de programmeur les plus fortement défendues. Quel est le meilleur langage de programmation à utiliser ? L’architecture de l’application ? Les standards d’écriture du code ? La licence logicielle ? Le système de gestion de version ? Si vous êtes le seul à travailler (ou à connaître !)  le projet, vous devez décider, de façon unilatérale.

Quand vous vous lancez finalement, malgré tout, cette détermination bornée et cette forte opinion sont devenus préjudiciables, pas bénéfiques. Une fois que vous vous êtes lancé, vous aurez besoin de compétences tout à fait à l’opposé pour faire des compromis afin que votre logiciel soit davantage utile aux autres. Et beaucoup de ces compromis vous sembleront vraiment mauvais.

Il est difficile de recevoir des avis d’« étrangers » (c.à.d. des personnes qui ne sont pas vous). D’abord parce qu’ils se focalisent sur des choses si triviales, sans importance (votre convention de nommage des variables par exemple, ou l’emplacement de certain boutons). Ensuite parce qu’ils ont invariablement tort . Après tout, si ce que vous avez fait n’est pas la bonne manière de faire, vous ne l’auriez pas fait ainsi dès le départ. Si votre façon de faire n’était pas la bonne, pourquoi votre code serait si populaire ? 

Mais « mauvais » est relatif. Si faire un mauvais choix rend votre logiciel plus accessible aux utilisateurs finaux, ou aux « développeurs en aval » ou aux administrateurs ou les empaqueteurs, est-ce que ce n’est pas finalement juste ? 

Et la nature de ce genre de commentaires et de contributions est généralement négative. Les retours de la communauté sont principalement des réactions, ce qui implique qu’elles sont critiques. Avez vous déjà rapporté un bug qui disait « J’aime beaucoup l’organisation du module hashtable.c » ou « Bravo d’avoir supprimé ce sous-sous-sous-menu » ? Les gens font un retour d’expérience car ils n’aiment pas la façon dont fonctionne votre logiciel à un instant T.  Et ils ne sont pas toujours très diplomates à ce moment-là.

Il est difficile de répondre de façon positive à ce genre de retour. Nous engueulons parfois les expéditeurs sur nos listes des discussions de développement, ou fermons les rapports d’anomalies avec un rictus et un WONTFIX (NdT : NESERAPASRESOLU, employé dans les rapports de bug). Pire encore, nous nous retirons dans notre cocon, ignorant les suggestions externes ou les retours d’expérience, câlinant notre confortable code qui sied parfaitement à nos idées préconçues et à nos marottes.

Si le logiciel n’est que pour vous-même, vous pouvez garder le code source et les infrastructures qui l’entourent comme terrain de jeu personnel. Mais si vous voulez que votre logiciel soit utilisé, qu’il compte pour les autres personnes, qu’il change (peut-être) le monde, alors vous allez devoir construire une saine et solide communauté d’utilisateurs, de contributeurs principaux, d’administrateurs et de développeurs de modules. Les utilisateurs ont besoin d’avoir l’impression de posséder le logiciel, de la même façon que vous.

Il est difficile de se rappeler que chacune de ces voix dissidentes ne représente qu’une infime minorité. Imaginez tous les gens qui entendent parler de votre logiciel qui ne prennent jamais le temps de l’essayer. Ceux qui le téléchargent mais ne l’installent jamais. Ceux qui l’installent, restent bloqués, et l’abandonnent en silence. Et ceux qui veulent vous faire un retour, mais qui ne trouvent pas votre système de rapport de bugs, listes de mails de développeurs, canaux IRC ou adresses mails personnelles. Étant donné les difficultés à faire passer leur message, il y a probablement une centaine de personnes qui veulent que des modifications soient faites pour une seule qui parvient à transmettre le message. Donc, être à l’écoute de ces voix, quand elle parviennent à vous atteindre, est essentiel. 

Le responsable de projet est chargé de maintenir la vision et la finalité du logiciel. Nous ne pouvons vaciller, en faisant des allers et retours basés sur tel ou tel courriel d’utilisateur pris au hasard. Et s’il y a un principe de base en jeu, alors, bien sûr, il est important de garder cette base stable. Personne d’autre que le responsable de projet ne peut le faire. 

Mais nous devons réfléchir : y a-t-il des questions non fondamentales qui puissent rendre le logiciel plus accessible, plus facile d’utilisation ? Finalement, la mesure de notre travail est dans la façon dont nous touchons les utilisateurs, comment notre logiciel est utilisé, et ce pourquoi il est utilisé. À quel point notre idée personnelle importe-t-elle « vraiment » pour le projet et pour la communauté ? Quelle part est uniquement ce que le responsable aime, personnellement ? Si ces problèmes non essentiels existent, alors il faut réduire les désaccords, répondre aux demandes, et faire les changements. Le projet n’en sera que meilleur pour tout le monde.  

Tous les autres pourraient avoir tort, mais c’est peu probable

par Evan Prodromou

Evan Prodromou est le fondateur de Wikitravel, StatusNet et du réseau social Open Source Identi.ca. Il participe aux logiciels Open Source depuis 15 ans en tant que développeur, écrit de la documentation et se distingue à l’occasion comme agitateur. Il vit au Québec, à Montréal. 

La plus importante caractéristique du fondateur d’un projet Open Source, dans les premières semaines ou premiers mois avant de lancer son logiciel dans le monde, c’est une obstination de tête de mule face à l’écrasante évidence des faits. Si votre logiciel est si important, pourquoi personne ne l’a-t-il déjà écrit ? Peut-être que ce n’est même pas possible. Peut-être que personne d’autre que vous ne veut ce que vous êtes en train de faire. Peut-être que vous n’êtes pas assez bon pour le faire. Peut-être que quelqu’un l’a déjà fait et que vous n’êtes simplement pas assez malin pour le trouver avec Google. 

Garder la foi à travers cette longue et sombre nuit est difficile ; seules les têtes de cochons opiniâtres et bornées peuvent y parvenir. Et nous arrivons à l’application de nos opinions de programmeur les plus fortement défendues. Quel est le meilleur langage de programmation à utiliser ? L’architecture de l’application ? Les standards d’écriture du code ? La licence logicielle ? Le système de gestion de version ? Si vous êtes le seul à travailler (ou à connaître !)  le projet, vous devez décider, de façon unilatérale.

Quand vous vous lancez finalement, malgré tout, cette détermination bornée et cette forte opinion sont devenus préjudiciables, pas bénéfiques. Une fois que vous vous êtes lancé, vous aurez besoin de compétences tout à fait à l’opposé pour faire des compromis afin que votre logiciel soit davantage utile aux autres. Et beaucoup de ces compromis vous sembleront vraiment mauvais.

Il est difficile de recevoir des avis d’« étrangers » (c.à.d. des personnes qui ne sont pas vous). D’abord parce qu’ils se focalisent sur des choses si triviales, sans importance (votre convention de nommage des variables par exemple, ou l’emplacement de certain boutons). Ensuite parce qu’ils ont invariablement tort . Après tout, si ce que vous avez fait n’est pas la bonne manière de faire, vous ne l’auriez pas fait ainsi dès le départ. Si votre façon de faire n’était pas la bonne, pourquoi votre code serait si populaire ? 

Mais « mauvais » est relatif. Si faire un mauvais choix rend votre logiciel plus accessible aux utilisateurs finaux, ou aux « développeurs en aval » ou aux administrateurs ou les empaqueteurs, est-ce que ce n’est pas finalement juste ? 

Et la nature de ce genre de commentaires et de contributions est généralement négative. Les retours de la communauté sont principalement des réactions, ce qui implique qu’elles sont critiques. Avez vous déjà rapporté un bug qui disait « J’aime beaucoup l’organisation du module hashtable.c » ou « Bravo d’avoir supprimé ce sous-sous-sous-menu » ? Les gens font un retour d’expérience car ils n’aiment pas la façon dont fonctionne votre logiciel à un instant T.  Et ils ne sont pas toujours très diplomates à ce moment-là.

Il est difficile de répondre de façon positive à ce genre de retour. Nous engueulons parfois les expéditeurs sur nos listes des discussions de développement, ou fermons les rapports d’anomalies avec un rictus et un WONTFIX (NdT : NESERAPASRESOLU, employé dans les rapports de bug). Pire encore, nous nous retirons dans notre cocon, ignorant les suggestions externes ou les retours d’expérience, câlinant notre confortable code qui sied parfaitement à nos idées préconçues et à nos marottes.

Si le logiciel n’est que pour vous-même, vous pouvez garder le code source et les infrastructures qui l’entourent comme terrain de jeu personnel. Mais si vous voulez que votre logiciel soit utilisé, qu’il compte pour les autres personnes, qu’il change (peut-être) le monde, alors vous allez devoir construire une saine et solide communauté d’utilisateurs, de contributeurs principaux, d’administrateurs et de développeurs de modules. Les utilisateurs ont besoin d’avoir l’impression de posséder le logiciel, de la même façon que vous.

Il est difficile de se rappeler que chacune de ces voix dissidentes ne représente qu’une infime minorité. Imaginez tous les gens qui entendent parler de votre logiciel qui ne prennent jamais le temps de l’essayer. Ceux qui le téléchargent mais ne l’installent jamais. Ceux qui l’installent, restent bloqués, et l’abandonnent en silence. Et ceux qui veulent vous faire un retour, mais qui ne trouvent pas votre système de rapport de bugs, listes de mails de développeurs, canaux IRC ou adresses mails personnelles. Étant donné les difficultés à faire passer leur message, il y a probablement une centaine de personnes qui veulent que des modifications soient faites pour une seule qui parvient à transmettre le message. Donc, être à l’écoute de ces voix, quand elle parviennent à vous atteindre, est essentiel. 

Le responsable de projet est chargé de maintenir la vision et la finalité du logiciel. Nous ne pouvons vaciller, en faisant des allers et retours basés sur tel ou tel courriel d’utilisateur pris au hasard. Et s’il y a un principe de base en jeu, alors, bien sûr, il est important de garder cette base stable. Personne d’autre que le responsable de projet ne peut le faire. 

Mais nous devons réfléchir : y a-t-il des questions non fondamentales qui puissent rendre le logiciel plus accessible, plus facile d’utilisation ? Finalement, la mesure de notre travail est dans la façon dont nous touchons les utilisateurs, comment notre logiciel est utilisé, et ce pourquoi il est utilisé. À quel point notre idée personnelle importe-t-elle « vraiment » pour le projet et pour la communauté ? Quelle part est uniquement ce que le responsable aime, personnellement ? Si ces problèmes non essentiels existent, alors il faut réduire les désaccords, répondre aux demandes, et faire les changements. Le projet n’en sera que meilleur pour tout le monde.  

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Libres conseils (1/42)

Traduction framalang peupleLa, tibs, Astalaseven, aKa, lerouge, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, jcr83, Goofy, Gatien Bovyn, Antoine, lamessen, AlBahtaar + 2 anonymes

Première Partie, Idées et innovations

1. Du code avant toute chose

Armijn Hemel a utilisé des logiciels libres depuis 1994, lorsque son frère est revenu à la maison avec une pile de disquettes contenant l’une des premières versions de FreeBSD. Un an après, il migrait vers GNU/Linux, et depuis il n’utilise plus que des systèmes de type Unix, que ce soit chez lui, pour ses études à l’université d’Utrecht ou au travail. Depuis 2005, Armijn est membre du noyau dur de l’équipe de gpl-violations.org tout en possédant son propre cabinet de conseil (Tjaldur Software Governance Solutions) spécialisé dans la détection et la résolution de litiges nés de violations de licences GPL.

En 1999, je faisais tout juste mes premiers pas dans l’activisme du logiciel libre et Open Source. J’utilisais déjà Linux et FreeBSD depuis un certain nombre d’années, mais je n’étais encore qu’un simple utilisateur et je souhaitais apporter une contribution en retour. De mon point de vue, la meilleure manière de le faire était d’écrire du code. Étant donné que je ne trouvais aucun projet existant dans lequel j’aurais été à l’aise pour travailler, j’ai décidé de commencer mon propre projet. Avec le recul, je constate que plusieurs raisons m’ont poussé à débuter ce projet. L’une tenait à mes doutes sur le fait que mon code était d’une qualité suffisante pour être accepté dans un projet existant (je n’étais pas un programmeur brillant et d’ailleurs je ne le suis toujours pas), alors que pour un projet personnel, la question ne se pose pas. La seconde raison est certainement l’arrogance de la jeunesse.

Mon idée était de créer un logiciel de présentation, qui pourrait imiter la plupart des fonctionnalités les plus avancées (ou si vous préférez, les plus pénibles) de PowerPoint. À ce moment-là, OpenOffice.org n’existait pas et le choix était relativement limité : LaTeX et MagicPoint, qui sont davantage orientés vers le contenu textuel que sur les effets d’animation. Je voulais créer un logiciel multi-plateforme, et j’ai pensé que pour remplir cet objectif Java serait le meilleur choix.

Le concept était de faire un logiciel de présentation, écrit en Java, qui aurait intégré tous ces effets animés. Je me suis décidé et j’ai commencé le projet.

Toute l’infrastructure nécessaire était déjà disponible : une liste de diffusion, un site web, un système de gestion de versions (CVS). Mais il n’existait aucun code source qui aurait permis à des contributeurs potentiels de travailler directement . La seule chose en ma possession, c’était quelques idées de ce que je voulais faire, une démangeaison à soulager, et des slogans publicitaires séduisants. Je voulais en fait que beaucoup de gens rejoignent le projet pour que celui-ci devienne réellement un projet collaboratif.

J’ai commencé par faire des plans (avec mes nouvelles connaissances en UML) et à les faire circuler. Rien ne s’est passé. J’ai essayé d’impliquer des contributeurs, mais créer une architecture de manière collaborative est très difficile (sans compter qu’a priori, ce n’est sûrement pas le meilleur moyen de créer un logiciel). Après un certain temps, j’ai laissé tomber et le projet est mort en silence, sans qu’une seule ligne de code ait été écrite. Chaque mois je recevais des messages par la liste de diffusion qui me rappelaient que ce projet avait un jour existé, j’ai donc demandé sa mise hors-ligne.

J’en ai tiré une leçon précieuse, quoiqu’un peu douloureuse : dès lors que vous annoncez quelque chose et que vous souhaitez que les gens s’impliquent dans votre projet, assurez-vous au moins qu’il y ait un minimum de code disponible. Peu importe qu’il ne soit pas complètement terminé ; il est acceptable même s’il est mal dégrossi (au début en tout cas). Mais au moins cela démontre l’existence d’une base sur laquelle des contributeurs peuvent travailler et ainsi l’améliorer. Dans le cas contraire, votre projet finira de la même manière que tant d’autres, dont le mien : aux oubliettes.

Finalement, j’ai trouvé mon créneau pour contribuer au progrès du logiciel libre et open source, en m’assurant que les fondements légaux de ceux-ci restent protégés par l’intermédiaire du projet gpl-violations.org. Rétrospectivement, je n’ai jamais utilisé — sans en éprouver de frustration d’ailleurs — les effets animés dans les logiciels de présentation. En fait, je les trouve de plus en plus irritants, ils nous distraient trop du contenu. Pour faire mes présentations, je suis un utilisateur heureux de LaTeX Beamer et occasionnellement — mais avec moins de plaisir — d’OpenOffice.org/LibreOffice.

Crédit photo vampir 42 (CC-BY-SA)

Qui n’a pas son projet libre ?

Plus qu’une mode ou un engouement passager, c’est un véritable mouvement de fond depuis quelques années : toute une communauté qui crée, échange, élabore, donne et reçoit des contributions, enfourche de nouveaux projets…

Fort bien, mais…

SourceForge récemment et Github aujourd’hui sont de véritables cimetières de projets libres et open source qui n’ont jamais trouvé d’audience, d’équipe de développement, de communauté active. Rien de bien tragique là-dedans. On peut estimer que ces plateformes sont pour beaucoup de libristes une sorte de terrain de jeu, de laboratoire, d’incubateur où le code et sa documentation s’expérimentent par à-coups, avec l’enthousiasme et l’énergie de ceux qui s’emparent d’un outil pour le mettre au service de leur créativité. Un excellent moyen d’apprendre en faisant finalement, à code ouvert. Et qu’importe alors l’absence d’aboutissement dans 80% des cas puisque c’est la démarche qui a été formatrice.

Cependant vous pouvez avoir envie de dépasser le stade du hobbyiste sympathique qui va bricoler son génial projet dans son coin. Vous pouvez avoir le désir de mettre toutes le chances de votre côté pour que le projet libre aboutisse vraiment, gagne en notoriété, entre dans une logique commerciale, vous procure amour, gloire et beauté.

C’est précisément l’intérêt du feuilleton dont vous allez déguster les épisodes semaine après semaine.

42 auteurs vous feront partager leur expérience, avec sérieux et humour, vous raconteront leurs ratages et leurs succès, vous diront comment éviter les uns et atteindre les autres. Des principes, des recommandations mais aussi des trucs et des ficelles, bref une ribambelle chatoyante de libres conseils.

Chaque semaine ou presque, l’équipe framalang vous proposera un nouvel épisode traduit du livre électronique en anglais Open Advice.

Chaque semaine — top départ chaque jeudi soir à 21h — une ou deux tranches du gâteau seront proposées à la traduction collaborative sur un framapad, donc en libre accès pour tous ceux qui souhaitent y contribuer. Participez à l’aventure !

La version que nous publierons ensuite ici même, comme dans le premier échantillon ci-dessous qui est une sorte de préambule, est un premier état de la traduction (donc évidemment perfectible), l’étape suivante sera une révision générale de tous les articles pour les joindre en un Framabook à venir.

Eh oui ça se passe comme ça chez Frama !

Les traducteurs de ce premier round d’échauffement :

peupleLa, Astalaseven, Hideki, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, Slystone, schap2, 4nti7rust, Goofy, Antoine, lamessen + 4 anonymes

Libres Conseils

Logiciels libres et open source : ce que nous aurions aimé savoir avant de commencer

Open Advice est une base de connaissances provenant d’une grande variété de projets de logiciels libres. Elle répond à des questions dont 42 contributeurs majeurs auraient aimé connaître les réponses lorsqu’ils ont débuté. Vous aurez ainsi une longueur d’avance quelle que soit la façon dont vous contribuez et quel que soit le projet que vous avez choisi.

Les projets de logiciels libres modifient le paysage du logiciel de façon impressionnante grâce à des utilisateurs dévoués et une gestion innovante. Chacun apporte quelque chose au mouvement à sa façon, avec ses capacités et ses connaissances. Cet engagement personnel et la puissance du travail collaboratif sur Internet donnent toute leur force aux logiciels libres et c’est ce qui a rassemblé les auteurs de ce livre.

Ce livre est la réponse à la question « Qu’auriez-vous aimé savoir avant de commencer à contribuer ? » Les auteurs offrent un aperçu de la grande variété de talents qu’il faut rassembler pour réussir un projet de logiciel : le codage bien sûr, mais aussi le design, la traduction, le marketing et bien d’autres compétences. Nous sommes là pour vous donner une longueur d’avance si vous êtes nouveau. Et si ça fait déjà un moment que vous contribuez, nous sommes là pour vous donner un aperçu d’autres domaines et projets.

pour les géants et ceux qui se tiendront sur leurs épaules [1] 

Avant-propos

Ce livre parle de communauté et de technologies. Il est le fruit d’un travail collectif, un peu comme la technologie que nous construisons ensemble. Si c’est votre première rencontre avec notre communauté, vous pourrez trouver étrange de penser qu’une communauté puisse être le moteur qui propulse la technologie. La technologie n’est-elle pas l’œuvre des grands groupes industriels ? En fait, pour nous c’est presque l’inverse. Les auteurs de ce livre sont tous membres de ce que vous pourriez appeler la communauté du logiciel libre. Un groupe de personnes qui partagent l’idée fondatrice que les logiciels sont plus puissants, plus utiles, plus flexibles, mieux contrôlables, plus justes, plus englobants, plus durables, plus efficaces, plus sûrs et finalement simplement meilleurs quand ils sont fournis avec les quatre libertés fondamentales : la liberté d’utiliser, la liberté d’étudier, la liberté de partager et la liberté d’améliorer le logiciel.

Et bien qu’il y ait maintenant un nombre croissant de communautés qui ont appris à se passer de la proximité géographique grâce aux moyens de communication virtuels, c’est cette communauté qui en a été le précurseur.

En fait, Internet et la communauté du logiciel libre[2] suivaient des développements mutuellement dépendants. Au fur et à mesure qu’Internet grandissait, notre communauté pouvait grandir en même temps. Mais sans les valeurs ni la technologie qu’apportait notre communauté, il ne fait aucun doute à mes yeux que jamais Internet n’aurait pu devenir ce réseau global reliant les personnes et les groupes du monde entier.

À ce jour, nos logiciels font fonctionner la majeure partie d’Internet, et vous devez en connaitre au moins quelques-uns, comme Mozilla Firefox, OpenOffice.org, Linux, et peut-être même Gnome ou KDE. Mais notre technologie peut aussi se cacher dans votre téléviseur, votre routeur sans fil, votre distributeur automatique de billets, et même votre radio, système de sécurité ou bataille navale. Elle est littéralement omniprésente.

Ils ont été essentiels dans l’émergence de quelques-unes des plus grandes sociétés que vous connaissez, comme Google, Facebook, Twitter et bien d’autres. Aucune d’entre elles n’aurait pu accomplir autant en si peu de temps sans le pouvoir du logiciel libre qui leur a permis de monter sur les épaules de ceux qui étaient là avant eux. Mais il existe également de nombreuses petites entreprises qui vivent de, avec, et pour le logiciel libre, dont la mienne, Kolab Systems. Le fait d’agir activement avec la communauté et dans un bon esprit est devenu un élément de succès essentiel pour nous tous. Et c’est aussi vrai pour les plus grosses, comme Oracle nous l’a involontairement démontré durant et après sa prise de contrôle de Sun Microsystems. Il est important de comprendre que notre communauté n’est pas opposée au commerce. Nous aimons notre travail, et beaucoup d’entre nous en ont fait leur métier pour gagner leur vie et rembourser leurs crédits. Donc quand nous parlons de communauté, nous voulons dire des étudiants, des entrepreneurs, des développeurs, des artistes, des documentalistes, des professeurs, des bricoleurs, des hommes d’affaires, des commerciaux, des bénévoles et des utilisateurs. Oui, des utilisateurs. Même si vous ne vous en êtes pas encore rendu compte ou n’avez jamais appartenu à une communauté, vous faites en réalité déjà partie de la nôtre. La question est de savoir si vous allez y participer activement. Et c’est cela qui nous différencie des poids lourds de la monoculture, des communautés fermées, des jardins clôturés de sociétés telles qu’Apple, Microsoft et d’autres. Nos portes sont ouvertes. Tout comme nos conseils. Et également notre potentiel. Il n’y a pas de limite à ce que vous pouvez devenir — cela dépend uniquement de votre choix personnel comme cela a été le cas pour chacun d’entre nous.

Donc si vous ne faites pas encore partie de notre communauté, ou si vous êtes simplement curieux, ce livre offre un bon point de départ. Et si vous êtes déjà un participant actif, ce livre pourrait vous offrir un aperçu de quelques facettes et de quelques perspectives qui seront nouvelles pour vous.

En effet, ce livre contient d’importantes graines de ce savoir implicite que nous avons l’habitude de construire et de transférer à l’intérieur de nos sous-communautés qui travaillent sur diverses technologies. Ce savoir circule généralement des contributeurs les plus expérimentés vers les moins expérimentés. C’est pourquoi il semble tellement évident et naturel à ceux qui fréquentent notre communauté. Ce savoir et cette culture de la collaboration nous permettent de créer d’extraordinaires technologies avec de petites équipes du monde entier au-delà des différences culturelles, linguistiques et de nationalité. Cette manière de fonctionner permet de surpasser des équipes de développement bien plus grandes de certaines des plus grosses sociétés au monde. Tous les contributeurs de ce livre ont une expérience solide dans au moins un domaine, parfois plusieurs. Ils sont devenus des enseignants et des mentors. Au cours des quinze dernières années, j’ai eu le plaisir d’apprendre à connaître la plupart d’entre eux, de travailler avec beaucoup, et j’ai le privilège de compter certains parmi mes amis.

Comme l’a dit judicieusement Kévin Ottens pendant le Desktop Summit 2011 à Berlin, « construire une communauté, c’est construire de la famille et de l’amitié ».

C’est donc en réalité avec un profond sentiment de gratitude que je peux dire qu’il n’y a aucune autre communauté dont je préférerais faire partie, et je suis impatient de vous rencontrer à l’une ou l’autre des conférences à venir.

— Georg Greve

Zürich, Suisse, le 20 août 2011

Georg Greve a fondé la Free Software Foundation Europe (FSFE) en 2000 et en a été le président fondateur jusqu’en 2009. Durant cette période, il a été responsable du lancement et du développement de nombreuses activités de la FSFE, telles que les alliances, la politique ou les travaux juridiques. Il a intensivement travaillé avec de nombreuses communautés. Aujourd’hui, il poursuit ce travail en tant qu’actionnaire et PDG de Kolab Systems AG, une société qui se consacre entièrement aux logiciels libres. Pour ses actions en faveur du logiciel libre et des standards ouverts, Georg Greve a été décoré de la croix fédérale du mérite (Bundesverdienstkreuz am Bande) par la République Fédérale d’Allemagne le 18 décembre 2009. Thank You! Merci !

Ce livre n’aurait pu voir le jour sans la participation de chaque auteur et des personnes suivantes, qui ont aidé à sa réalisation :

Anne Gentle (relecture)

Bernhard Reiter (relecture)

Celeste Lyn Paul (relecture)

Daniel Molkentin (mise en page)

Debajyoti Datta (site internet)

Irina Rempt (relecture)

Jeff Mitchell (relecture)

Mans Rullgard (relecture)

Noirin Plunkett (relecture)

Oregon State University Open Source Lab (hébergement du site internet)

Stuart Jarvis (relecture)

Supet Pal Singh (site internet)

Saransh Sinha (site internet)

Vivek Prakash (site internet)

Will Kahn-Greene (relecture)

* * * * * *

[1] Note des traducteurs : dédicace par allusion à « Nous sommes des nains juchés sur les épaules de géants. » Bernard de Chartres, XIIe siècle

[2] Note de l’auteur : pour moi, l’Open Source n’est que l’un des aspects de cette communauté. Cet aspect particulier a trouvé son articulation en 1998, c’est-à-dire quelque temps après l’arrivée d’Internet. Mais n’hésitez pas à dire « Open Source » au lieu de « logiciel libre » si vous préférez ce terme.

Crédits photo hellojenuine (CC-BY-SA)

Il est rare que Framasoft s’évade d’Internet et encore plus rare qu’il organise lui-même des évènements sur le terrain de la vraie vie. Alors autant que ça sorte un peu de l’ordinaire, comme ce fut le cas vendredi 7 décembre à la Rockette Libre et samedi 8 décembre à la librairie « À Livr’Ouvert ».

Framathon à la Rockette Libre

C’est temps libre chaque vendredi soir à la Petite Rockette. Et c’était au tour de Framasoft d’investir le lieu le 7 décembre dernier.

Il s’agissait de lancer le top départ d’un ambitieux projet en partenariat avec LinuxFr : traduire dans son intégralité le livre Open Advice: what we wish we had known when we started (avec le recul, qu’auriez-vous voulu savoir quand vous avez commencé à contribuer à la communauté du libre ?)

Or nous manquions d’ordinateurs, nous étions un peu fatigués en cette fin de semaine, et nous avions plein de choses à nous dire car certains ne s’étaient pas vus depuis bien longtemps (parfois depuis leur naissance). Donc rares étaient ceux qui travaillaient effectivement sur la traduction : trois, quatre personnes tout au plus au maximum de l’activité. Il faut aussi vous avouer que le slogan détourné par Pouhiou à cette occasion ne nous a pas vraiment motivés : « Boire ou traduire, il faut choisir ! » 😉

Et pourtant le travail proposé fut réalisé « vite fait bien fait » ! Pourquoi ? Parce que nous avions déposé les deux premiers articles du livre sur Framapad et sollicité dans le même temps la participation d’Internet. Pour ce qui nous concerne, nous avions projeté sur le mur les pads en question et jetions un oeil de temps en temps sur le texte et les couleurs qui défilaient à l’écran.

L’originalité est là.

La majorité des lecteurs de ce blog est désormais habituée à un tel l’outil et une telle manière de procéder ensemble. Mais pour quelqu’un qui découvre, cela a quelques chose de magique ! Et il n’est pas au bout de sa surprise car quand il arrive (enfin) à comprendre que derrière chaque couleur en mouvement se cache quelque part une personne connectée, il lui est tout aussi suprenant d’apprendre que tout ce petit monde n’a pas été « sélectionné » et surtout travaille « pour rien ». Pour la beauté du geste, pour la beauté du Libre…

Cette dernière phrase valait bien une danse 😉

Framabook chez « À Livr’Ouvert »

Comment donc ? Tous les livres de notre libre collection Framabook dans une librairie parisienne ! En vitrine même !

Il fallait marquer le coup en invitant les lecteurs à rencontrer les auteurs.

C’est ainsi que fut organisée une très conviviale mais somme toute classique séance de dédicaces avec trois de nos auteurs : le gendre idéal Benjamin Jean, le plus célèbre auteur vivant du domaine public Pouhiou et l’homme qui gratte plus vite son ukulélé que son ombre Simon Gee Giraudot.

Un petit ordinateur se trouvait au milieu d’eux. Il contenait les versions numériques intégrales de toute la collection.

L’originalité est là.

Les gens étaient évidemment cordialement invités à acheter et repartir avec des livres, c’est normal nous sommes dans une librairie. Mais ils pouvaient aussi sortir leur clé USB que nous nous faisions un plaisir de remplir avec la version numérique du ou des livre(s) de leur choix.

C’est gratuit, mais c’est surtout libre. C’est à notre connaissance une grande première que de proposer, dans un tel lieu, un tel service libre en libre service. Et c’est tout à l’honneur de l’audacieuse librairie qui porte décidément bien son nom. Nous sommes tout d’un coup très loin d’Hadopi.

Ah, et sinon nous avons vendu une trentaine de livres papiers Framabook ce jour-là.

Nous remercions toutes celles et ceux qui sont venus et ont participé à ces deux singuliers évènements et plus particulièrement Olive (Rockette Libre) et Bookynette (À Livr’Ouvert) pour leur invitation, accueil, disponibilité et bonne humeur.

C’est quand vous voulez pour recommencer 😉

Crédit photo : aKa (Creative Commons By)

Un logiciel espion dans Ubuntu ! Que faire ?

par Richard Stallman

L’un des principaux avantages du logiciel libre est que la communauté protège les utilisateurs des logiciels malveillants. Aujourd’hui Ubuntu GNU/Linux est devenu un contre-exemple. Que devons-nous faire ?

Le logiciel privateur est associé à la malveillance envers l’utilisateur : code de surveillance, menottes numériques (gestion numérique des restrictions, ou DRM) destinées à imposer des limites aux utilisateurs, et portes dérobées qui peuvent faire des choses déplaisantes sous contrôle à distance. Les programmes qui effectuent l’une quelconque de ces opérations sont des logiciels malveillants et devraient être considérés comme tels. Les exemples les plus communs sont Windows, les iTrucs, ou encore le « Kindle » d’Amazon (connu pour son autodafé de livres virtualisés^[1] ), qui font ces trois choses ; Macintosh et la Playstation III qui imposent des menottes numériques ; la plupart des téléphones portables, qui espionnent et possèdent des portes dérobées ; Adobe Flash Player, qui espionne et fait respecter les menottes numériques ; ainsi que de nombreuses applications iTrucs ou Android, qui intègrent une ou plusieurs de ces pratiques néfastes.

Le logiciel libre donne aux utilisateurs la possibilité de se protéger contre les comportements malveillants des logiciels. Encore mieux, la communauté protège en général tout le monde et la majorité des utilisateurs n’a pas à bouger le petit doigt. Voici comment.

De temps à autre, des utilisateurs sachant programmer trouvent du code malveillant dans un programme libre. Généralement, ce qu’ils font ensuite c’est de publier une version corrigée du programme : les quatre libertés (voir http://www.gnu.org/philosophy/free-sw.html) qui définissent le logiciel libre le permettent. On appelle cela un fork du programme. Rapidement, la communauté bascule sur la version corrigée, et la version infectée est rejetée. La perspective d’un rejet ignominieux n’est pas vraiment tentante : donc, la plupart du temps, même ceux qui ne sont pas arrêtés par leur conscience ou par la pression sociale s’abstiennent de glisser des malfaçons dans les logiciels libres.

Mais pas toujours. Ubuntu, distribution influente et largement utilisée, a installé du code de surveillance. Lorsque l’utilisateur effectue une recherche dans ses propres fichiers en utilisant le système de recherche d’Ubuntu desktop, Ubuntu envoie cette recherche à l’un des serveurs de Canonical (Canonical étant la société qui développe Ubuntu).

C’est exactement comme le premier cas de surveillance dont j’aie appris l’existence, dans Windows. Mon vieil ami Fravia m’avait expliqué qu’un jour, alors qu’il recherchait une phrase dans ses fichiers avec Windows, un paquet – détecté par son pare-feu – avait été émis vers un serveur. À compter de cet exemple, je suis devenu attentif et n’ai pas oublié la propension à la malveillance qu’ont les logiciels privateurs « réputés ». Ce n’est peut-être pas par hasard qu’Ubuntu émet la même information.

Ubuntu se sert de ces informations sur leurs recherches pour afficher aux utilisateurs des publicités pour des produits vendus par Amazon. Cette société cause beaucoup de tort (voir http://stallman.org/amazon.html) ; en promouvant Amazon, Canonical y contribue. Cependant, les publicités ne sont pas le cœur du problème. Le véritable problème est l’espionnage des utilisateurs. Canonical affirme qu’Amazon ne sait rien de l’origine des recherches. Toutefois, il est tout aussi déplorable de la part de Canonical de collecter vos informations personnelles que cela ne l’aurait été de la part d’Amazon.

Certains feront sûrement des versions modifiées d’Ubuntu dépourvues de cette fonctionnalité espionne. De fait, plusieurs distributions GNU/Linux sont des versions modifiées d’Ubuntu. Lorsqu’elles se mettront à niveau avec la dernière version d’Ubuntu, je m’attends à ce que cette fonctionnalité soit enlevée. Canonical s’y attend également, sans aucun doute.

La plupart des développeurs de logiciel libre laisseraient tomber un tel projet, étant donné la perspective d’une migration en masse vers la version corrigée de quelqu’un d’autre. Mais Canonical n’a pas abandonné le logiciel espion d’Ubuntu. Peut-être Canonical pense-t-il que le nom « Ubuntu » a assez de poids et d’influence pour éviter les conséquences habituelles et s’en tirer avec cette surveillance.

Canonical dit que cette fonctionnalité permet de faire des recherches sur Internet « autrement ». Selon les détails de la méthode, cela pourrait, ou non, aggraver problème, mais cela ne l’atténuerait pas.

Ubuntu permet aux utilisateurs de désactiver la surveillance. Évidemment, Canonical pense que beaucoup d’utilisateurs d’Ubuntu vont laisser cette fonctionnalité à son état par défaut, c’est-à-dire active. Et c’est ce que beaucoup font probablement, car il ne leur vient pas à l’esprit d’essayer d’y changer quoi que ce soit. Ainsi, l’existence de cette option ne rend pas pour autant la fonctionnalité de surveillance acceptable.

Même si elle était désactivée par défaut, cette fonctionnalité resterait dangereuse : « activer une fois pour toutes » une pratique risquée, dont le risque varie selon les spécificités du système, invite au laisser-faire. Pour protéger la vie privée de l’utilisateur, les systèmes doivent simplifier l’usage de la prudence : quand un programme de recherche locale a une option de recherche sur le réseau, ce devrait être à l’utilisateur de choisir la recherche sur le réseau explicitement à chaque fois. C’est simple : il suffit de boutons séparés pour la recherche sur le réseau ou la recherche locale, comme c’était le cas dans les anciennes versions d’Ubuntu. Une fonctionnalité de recherche sur le réseau devrait aussi informer l’utilisateur clairement et concrètement sur la nature et la destination précise des données personnelles collectées, lorsqu’il utilise cette fonctionnalité.

Si une proportion suffisante des faiseurs d’opinion de la communauté voient cette question d’un point de vue uniquement personnel, s’ils désactivent la surveillance pour eux-mêmes et continuent à promouvoir Ubuntu, Canonical pourrait s’en tirer. Ce serait une grande perte pour la communauté du logiciel libre.

Nous, qui présentons le logiciel libre comme une défense contre les logiciels malveillants, n’affirmons pas qu’il s’agit d’une défense parfaite. Il n’existe pas de défense parfaite. Nous ne disons pas que la communauté va à coup sûr dissuader les gens d’implanter des logiciels espions. Donc, à proprement parler, ce n’est pas parce qu’il y a un logiciel malveillant dans Ubuntu que nous devons manger notre chapeau.

Mais ce qui est en jeu ici dépasse le fait de savoir si quelques-uns d’entre nous vont devoir avaler leur chapeau. La question est ici de savoir si notre communauté peut efficacement utiliser l’argument des logiciels espions privateurs. Si nous pouvons seulement dire « les logiciels libres ne vous espionnent pas, sauf si c’est Ubuntu », c’est bien moins percutant que de dire « les logiciels libres ne vous espionnent pas ».

Il nous appartient d’exprimer notre réprobation à Canonical avec suffisamment de force pour qu’il arrête cela. Canonical peut donner toutes les excuses qu’il veut, elles seront insuffisantes ; même s’il affectait tout l’argent que lui donne Amazon au développement de logiciel libre, cela pourrait difficilement contrebalancer ce que le logiciel libre a à perdre s’il cesse d’être un moyen efficace d’éviter aux utilisateurs de se faire flouer.

Si jamais vous recommandez ou redistribuez GNU/Linux, merci de retirer Ubuntu des distributions que vous recommandez ou redistribuez. Si la pratique d’installer et recommander des logiciels non libres ne vous convainc pas d’arrêter, ceci le fera. Dans vos install parties, dans vos « Journées du Libre », au FLISOL, n’installez pas et ne recommandez pas Ubuntu. À la place, dites qu’Ubuntu est mis à l’index pour espionnage.

Pendant que vous y êtes, vous pouvez aussi leur dire qu’Ubuntu contient des programmes non libres et suggère l’installation d’autres programmes non libres (voir http://www.gnu.org/distros/common-distros.html). Cela contrecarrera l’autre forme d’influence négative qu’exerce Ubuntu dans la communauté du logiciel libre : la légitimation des logiciels non libres.

Matériels incompatibles, absence d’interopérabilité, formats fermés, logiciels propriétaires… des motifs de colère et de combats familiers de la communauté libriste. Ces problématiques sont cependant un peu désincarnées aux yeux de la majeure partie de nos concitoyens du Net tant qu’ils n’ont pas été personnellement confrontés à des blocages fort irritants.

Une situation concrète est le point de départ du coup de gueule de Terence Eden. Quant à la véhémence de ses propos, elle est à la mesure de l’urgence. Car dans la guerre en cours, celle de notre liberté de choix, Apple, Amazon, Google et quelques autres ont plusieurs longueurs d’avance : des millions d’utilisateurs sont déjà entrés de leur plein gré dans des prisons numériques dorées.

Dans cet environnement, nous ne sommes plus propriétaires des fichiers médias que nous avons pourtant achetés, nous n’en sommes que les usagers à titre révocable et temporaire ! Autant dire que nous perdons la possibilité de réutiliser nos biens dès lors que nous changeons de support matériel. Du disque vinyle au CD-ROM et du DVD au fichier numérique, nous avons déjà vu comment un saut technologique nous contraint à acheter de nouveau. Eh bien cette farce au goût amer se joue maintenant sur la scène des médias numériques.

Parviendrons-nous à libérer nos médias captifs du matériel ? Il faudra certes bien plus qu’un coup de gueule comme celui qui suit, mais il n’est pas mauvais qu’un cri de colère agite un peu nos esprits de consommateurs endormis.

Je ne veux pas faire partie de votre putain d’écosystème

I Don’t Want To Be Part of Your Fucking Ecosystem

Terence Eden – 23 novembre 2012 – Blog personnel
(Traduction framalang & les twittos : Gatitac, Zii, ga3lig, Stan, Isdf, Slystone, Quartz, Coyau, Goofy, Exirel, greygjhart)

Je discutais avec un ami qui exprimait une opinion que je trouve assez répandue :

— Alors oui, j’aimerais bien passer à Android, mais tous mes données sont dans iTunes.

J’ai découvert que le problème, ce ne sont pas les applications : les racheter est pénible, mais la plupart sont gratuites. Le problème, ce sont les données qui emprisonnent les utilisateurs avec des services dont ils ne veulent plus.

Les musiques, les films, les séries TV, les abonnements et les podcasts. Tout est fermé à double tour dans l’étroit écosystème d’Apple. C’est une façon bien pensée d’enchaîner les gens à leur matériel.

Imaginez, ne serait-ce qu’un instant, que votre lecteur de DVD Sony ne puisse lire que des films de chez Sony. Si vous décidiez d’acheter un nouveau lecteur de marque Samsung par exemple, aucun de ces contenus ne serait lisible sur votre nouvel appareil sans un sérieux bidouillage.

Voilà les hauts murs derrière lesquels tant de grandes entreprises voudraient bien nous enfermer. Et je trouve que ça pue.

Sur un réseau de téléphonie mobile au Royaume-Uni, on peut utiliser le téléphone de son choix. Le matériel et les services sont complètement indépendants les uns des autres. Cela suscite de la concurrence parce que les consommateurs savent que s’ils sont mécontents de HTC, ils peuvent passer à Nokia et que tout fonctionnera comme avant.

Mais si tous vos contacts, vos services de divertissement et sauvegardes sont enchaînés à HTC, eh bien, vous êtes juste dans la merde si vous voulez changer.

Je veux assister à une séparation complète de l’Église et de l’État. Le matériel devrait être séparé du logiciel. Le logiciel devrait être séparé des services. Je veux pouvoir regarder des films achetés chez Nokia sur un système Google Android tournant sur un appareil Samsung, et ensuite sauvegarder le tout sur Dropbox.

C’est comme cela que ça fonctionne, plus ou moins, dans le monde du PC. Je ne comprends pas pourquoi cela n’est pas pareil dans le monde des tablettes et des smartphones. Pourquoi est-ce que j’achèterais une tablette qui ne fonctionnerait qu’avec le contenu d’un seul fournisseur ? Que ce soit Amazon, Microsoft ou Apple, ils constituent un dangereux petit monopole qui fera augmenter les prix et diminuer la qualité.

Bon, je sais. Le mantra du « It just works » (« Ça marche, tout simplement » ). Je suis légèrement dégoûté de devoir configurer ma tablette pour qu’elle parle à mon NAS, puis de faire en sorte que mon téléviseur fonctionne avec les deux à la fois. Cette situation n’est pas due à mes équipements multimédias qui viennent de différents fabricants, elle est plutôt due à ces différents fabricants qui n’utilisent pas de standards ouverts.

J’ai peur de ce qui arrivera lorsqu’un fournisseur mettra fin à un service. Je rigole à l’idée d’une éventuelle faillite d’Apple : même s’ils restent solvables, qu’est-ce qui les empêchera de supprimer tous vos achats de films et de musiques ? Après tout, ils ont fermé leur service Mobile Me quasiment sans avertissement et détruit toutes les données que leurs clients payants hébergeaient chez eux.

Adobe a fermé ses serveurs de DRM après un court préavis de 9 mois, en empêchant de fait quiconque de lire les livres pourtant achetés (Amazon peut vider votre Kindle).

Google a emmené Google Video au bûcher et lui a tiré une balle dans la tête — tout comme Buzz, Wave et qui sait combien d’autres produits.

Microsoft a mis en place PlaysForSure, puis l’a laissé mourir, piégeant ainsi des millions de fichiers musicaux sur des appareils qui ne sont plus pris en charge.

Donc peut-être vais-je m’en tenir à Google et espérer que mon téléviseur Google communiquera avec mon téléphone Google pendant que je regarderai des vidéos Google Play et que j’écouterai des musiques Google Play sur mon ChromeBook Google que je partagerai sur Google+ et que j’achèterai avec Google Wallet. Et je leur enverrai la prière du geek : « S’il vous plaît, ne décidez pas que ce service bien pratique n’est pas rentable ».

Je veux simplement que l’on s’entende tous. Je veux que mes équipements disparates se parlent. Je ne veux pas vivre dans une maison où chaque composant doit être fabriqué par une unique entreprise sous peine de ne rien voir marcher correctement. Je ne veux pas être bloqué ni devoir utiliser un mauvais produit parce que c’est le seul à offrir un certain service.

Je ne veux pas de vos jouets qui ne fonctionnent qu’avec les piles de votre marque.

Je ne veux pas faire partie de votre putain d’écosystème.

Crédit photo : Luke Addison (Creative Commons By-Sa)

Souvent accusés — non sans raison — de pousser à la surconsommation médicamenteuse en tirant un profit maximal de nos besoins en thérapies, les grands laboratoires pharmaceutiques gardent jalousement le secret de leurs données. Celles des recherches menant aux médicaments mis sur le marché, en particulier.

Cory Doctorow, nous fait part ici de ses convictions : suivant le principe récemment institué outre-Manche qui consiste à ouvrir les données de recherches financées par l’état, il considère que celles de l’industrie pharmaceutiques doivent être elles aussi ouvertes.

Découvrez pourquoi sous la plume d’un blogueur influent et avocat du libre et de l’open source (tous ses billets déjà traduits sur notre blog). Idéalisme et optimisme démesuré ou revendication légitime et combat à mener ? À vous d’en juger.

Pourquoi toutes les recherches pharmaceutiques devraient être en libre accès

Why all pharmaceutical research should be made open access

Cory Doctorow – 20 novembre – The Guardian
(Traduction Framalang : Slystone, Amine Brikci-N, goofy, peupleLa, Antoine, ga3lig)

Le gouvernement du Royaume-Uni veut que toute recherche financée par des fonds publics soit accessible — mais on devrait en exiger autant des industries pharmaceutiques.

Je déjeunais récemment avec le plus loyal défenseur du libre accès que vous puissiez rencontrer (je ne le nommerai pas, car ce serait grossier de lui attribuer des remarques fortuites sans sa permission). Nous parlions du projet de rendre obligatoire la publication libre et gratuite des recherches scientifiques financées par l’État. Aux États-Unis, il existe le Federal Public Research Act, et au Royaume-Uni il y a la déclaration du gouvernement de coalition selon laquelle la recherche financée par l’État devrait être disponible sans frais, sous une licence Creative Commons qui permette la copie illimitée.

Nous avons parlé de l’excellent nouveau livre de Ben Goldacre, intitulé Bad Pharma, dans lequel l’auteur documente le problème des « données manquantes » dans la recherche pharmaceutique (il dit que près de la moitié des essais cliniques réalisés par l’industrie pharmaceutique ne sont jamais publiés). Les essais non publiés sont, bien entendu, ceux qui montrent les nouveaux produits des labos pharmaceutiques sous un jour peu flatteur – ceux qui suggèrent que leurs médicaments ne sont pas très efficaces ou n’ont aucun effet, voire sont activement nocifs.

La pratique des industries qui consiste à éliminer les preuves scientifiques date de plusieurs décennies — et certains chercheurs indépendants le font également. Ce constat a conduit Goldacre à déclarer qu’aucune de nos connaissances en matière de médecine moderne ne peut être considérée comme valide, et il estime qu’il est urgent de contraindre les industries pharmaceutiques à publier toutes ces données laissées dans l’ombre, afin que les scientifiques puissent recalculer les résultats et déterminer ce qui fait vraiment effet.

J’ai mentionné tout cela à mon compagnon de déjeuner, en concluant par : « et c’est pourquoi toute la recherche pharmaceutique devrait être en libre accès ».

« Toute la recherche pharmaceutique financée par l’État, a-t-il rectifié, comme s’il corrigeait une erreur de calcul élémentaire. Si le public paie pour cela, il doit pouvoir la voir, mais si les entreprises pharmaceutiques veulent payer pour leur propre recherche, alors… »

Je savais d’où il tenait cette position. L’un des arguments les plus solides en faveur de l’accès au public des publications universitaires et scientifiques est celui de la « dette envers la population » : si le contribuable paie pour vos recherches, alors vos recherches doivent lui appartenir. C’est un bon argument, mais il n’est pas entièrement convaincant pour une raison. Il est vulnérable au contre-argument du « partenariat public/privé », qui dit: « ah, oui, mais pourquoi ne pas faire en sorte que le public bénéficie d’un retour sur investissement maximal en faisant payer très cher l’accès à la recherche financée par l’État et en renvoyant le profit au secteur de la recherche ? ». Je pense que cet argument est absurde, et c’est l’avis de la majorité des économistes qui se sont penchés sur la question.

La recherche sans entraves et librement accessible constitue un bien commun qui génère bien plus de valeur ajoutée au profit de tous que le profit rapide qu’on extorque des consommateurs en les faisant payer à l’entrée comme à la sortie. Cela s’est confirmé dans de multiples domaines, même si l’exemple-type est le succès massif des cartes géologiques des États-Unis librement disponibles, qui ont dégagé un profit tel qu’en comparaison, les bénéfices réalisés sur la vente des cartes d’État-major au Royaume-Uni semblent une misère.

Voilà pourquoi le travail de Goldacre est aussi important à ce point du débat. La raison pour laquelle on devrait exiger que les laboratoires pharmaceutiques publient leurs résultats, ce n’est pas qu’ils ont reçu des subventions sur fonds publics. C’est plutôt parce qu’ils demandent une certification de l’état qui garantisse que leurs produits sont propres à la consommation, et qu’ils demandent aux organismes de régulation d’autoriser les docteurs à rédiger des ordonnances prescrivant ces produits-là. Nous avons besoin qu’ils publient leurs recherches, même si cette action induit des pertes de profit, car sans cette recherche, nous ne pouvons pas savoir si ces produits sont propres à la consommation.

On emploie un argument analogue en faveur de l’utilisation de logiciels libres ou open source pour les applications dans l’industrie ou dans le domaine de la santé, comme le système OpenEyes conçu par le centre hospitalier d’ophtalmologie de Moorfields et d’autres institutions dans le monde, après l’effondrement du système électronique de suivi de santé de la National Health Service (NdT : le NHS est l’équivalent de la Sécurité Sociale). Ils n’ont pas préféré un système à accès libre à un système propriétaire pour des raisons idéologiques, mais plutôt pour des raisons qui sont avant tout pratiques. Aucun hôpital n’autoriserait jamais une société d’ingénierie à construire la nouvelle aile d’un hôpital en utilisant des méthodes propriétaires pour calculer la répartition du poids. Ils n’accepteraient pas une nouvelle aile dont les plans de construction seraient secrets, dont seul l’entrepreneur connaîtrait les emplacements des canalisations et des conduits de ventilation.

Il est certainement vrai que les sociétés d’ingénierie et les architectes pourraient gagner davantage si leurs méthodes étaient propriétaires. Mais on exige un accès ouvert, car on doit pouvoir entretenir les hôpitaux quels que soient les aléas que peut connaître toute société d’ingénierie, et parce qu’on veut la garantie que l’on obtient avec la possibilité de vérifier plusieurs fois les calculs de charge par nous-mêmes. Les systèmes informatiques qui sont utilisés dans les hôpitaux pour gérer les patients sont tout autant vitaux que l’emplacement des câbles ethernet dans les murs. Et donc Moorfields s’attend à ce qu’ils soient autant libres d’accès que les plans du bâtiment.

Et c’est pourquoi les grands labos pharmaceutiques doivent montrer leur travail. Sans tenir compte de ce qu’ils pourraient rapporter, leurs produits ne doivent pas être autorisés sur le marché sans cette exposition. Il est important de placer la recherche financée par l’état entre les mains du public, mais l’histoire de l’accès libre ne va pas s’arrêter là, elle ne fait que commencer.

Crédit photo : epSos.de (Creative Commons By)