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.  

Châtons-nous de sauver internet ! En décembre, l’April, Framasoft et La Quadrature du Net lancent une nouvelle campagne commune de soutien : Pack Liberté 2.

Ce qui se joue actuellement est vraiment fondamental.

Internet et son esprit libre, ils ne l’ont pas vu venir. Ils n’y ont rien compris au début. Ça n’était pas sérieux, pas vraiment monétisable. Ça ne les intéressait pour ainsi dire pas, alors ils nous ont laissés tranquillement jouer avec.

Et les chatons ont pu s’épanouir, libres et heureux…

Or aujourd’hui la menace plane. Ils n’ont pas forcément mieux compris mais ont cependant compris que ça ne leur convient pas et sont en train de tout faire pour lui mettre une muselière.

Mettre une muselière à un chaton, quelle drôle d’idée ! Ça ne peut fonctionner ! Et pourtant ils s’entêtent et les chatons se retrouvent en grand danger.

C’est autour de cette symbolique que l’April, Framasoft et La Quadrature du Net vous proposent de les soutenir durant tout le mois de décembre. Il y a un message fort à travailler ainsi en synergie. Il y a surtout une urgence à poursuivre notre travail de promotion et de défense du logiciel libre ainsi que le respect des droits et libertés du citoyen sur internet.

Nous vous savons très sollicités, qui plus est dans un contexte économique difficile. Mais soit vous avez fixé votre calendrier sur celui des Mayas, et alors c’est le bon moment pour aborder la fin du monde les poches plus légères. Soit vous pensez qu’il y a une vie après le 21 décembre et ça vaut le coup de faire en sorte qu’ensemble elle soit la plus libre possible…

Et dans les deux cas mieux vaut être accompagné d’un adorable chaton qui ainsi sauvé vous en sera éternellement reconnaissant.

Merci de votre confiance et de votre soutien,

Alexis Kauffmann (pour Framasoft)

-> Pack Liberté 2

On l’appelle sysadmin, adminsys ou plus correctement administrateur systèmes. Il a la lourde charge de s’occuper des serveurs d’une organisation.

Si vous avez l’impression qu’il bulle toute la journée, ne le critiquez pas ! Vous êtes en réalité en face d’un excellent administrateur systèmes 🙂

12 raisons pour lesquelles tous les administrateurs système devraient être paresseux

12 Reasons Why Every Linux System Administrator Should be Lazy

Ramesh Natarajan – 12 juillet 2011 – GeekStuff.com
(Traduction : Husi10, Ag3m, Gatitac, Kathryl, Thur, M0tty, Ag3m, Dominique, minimoy)

Un administrateur systèmes fainéant est un bon administrateur systèmes
— Anonyme

Le travail d’un administrateur systèmes n’est généralement pas visible des autres services informatiques ou par les utilisateurs finaux. La plupart du temps, ils regardent les administrateurs systèmes en se demandant pourquoi ils n’ont pas l’air de faire grand chose.

Quand vous voyez un administrateur systèmes qui est tout le temps en train de courir dans tous les sens, à essayer d’éteindre le feu, en prise constante avec des problèmes de production, vous pourriez penser qu’il travaille dur et fait vraiment bien son boulot. Mais en réalité il ne fait pas bien son job.

Quand vous voyez un administrateur système (UNIX/Linux, base de données, réseau), qui apparemment n’a pas l’air de se fouler beaucoup au bureau, semble toujours relax et n’a pas l’air d’avoir une activité visible, vous pouvez être certain qu’il fait bien son job.

Voici 12 raisons qui font d’un administrateur systèmes paresseux le meilleur des administrateurs systèmes :

1. Qui est le chef ? La principale raison pour laquelle un administrateur systèmes paresseux est le meilleur administrateur système possible tient à son attitude. Ils ne voient pas tout à fait les machines comme les autres services informatiques. Il y a une différence entre les développeurs et les administrateurs systèmes. Les développeurs pensent qu’ils sont là pour servir les machines en écrivant du code. Il n’y a rien de mal dans cette démarche puisque les développeurs prennent beaucoup de plaisir à écrire du code. Mais les administrateurs systèmes pensent tout autrement. Ils pensent au contraire que les machines sont à leur service. Tout ce qu’ils ont à faire, c’est nourrir la machine, la rendre heureuse et laisser la machine faire tout le dur labeur pendant qu’ils se relaxent et paressent. La première étape pour devenir un administrateur systèmes paresseux demande parfois un léger changement d’attitude : il s’agit de faire savoir à la machine que vous êtes le patron.

2. Écrire des scripts pour des tâches récurrentes. Être fainéant, c’est être malin. Un administrateur systèmes intelligent est passé maître dans tous les langages de script (bash, awk, sed, etc.). Chaque fois qu’il sera obligé de faire une tâche, et s’il y a une vague possibilité qu’on puisse avoir besoin de ce même travail plus tard, il écrira un script pour faire le boulot. Ainsi, lorsqu’on lui demandera plus tard de refaire le même travail, il n’aura pas à réfléchir ; il aura simplement à exécuter le script puis à retourner paresser.

3. Tout sauvegarder. Être fainéant signifie tout sauvegarder. Un administrateur systèmes paresseux sait qu’il doit donner un peu de temps dans la création de processus de sauvegarde, et donc écrire des scripts de sauvegarde pour toutes les applications et tous les systèmes critiques. Quand l’espace disque n’est pas un problème, il planifie la sauvegarde pour toutes les applications même si elles ne sont pas critiques. Ainsi, dès que quelque chose se passe mal, il ne se met pas à transpirer de stress, il a simplement besoin de restaurer une sauvegarde pour pouvoir retourner aux trucs paisibles qu’il faisait juste avant.

4. Prévoir un plan de reprise d’activité. Les administrateurs systèmes n’aiment pas avoir à gesticuler dans tous les sens en cas d’urgence. Quand tout se passe bien, ils prennent un peu de temps pour créer un plan de reprise d’activité et de récupération de données.Comme ça, quand les choses tournent mal, ils peuvent le suivre, faire revenir rapidement les choses à la normale, puis retourner encore à leur rythme d’administrateur paresseux.

5. Configurer un sytème à haute redondance. Les administrateurs sysèmes fainéants n’aiment pas être réveillés au beau milieu de la nuit à cause d’une bête panne materielle. Ils font donc en sorte que les periphériques soient hautement redondants. Cela inclut à la fois le matériel et les logiciels : ils ont deux cartes réseaux configurées, une double alimentation, deux disques durs, bref tout en double. Comme ça, si l’un des équipements vient à flancher, le système fonctionnera toujours et notre fainéant d’administrateur pourra se concentrer à la réparation de l’équipement défaillant lorsqu’il se lèvera le matin, à la même heure que tous les autres matins.

6. Laisser de la place pour une croissance inattendue. Un administrateur systèmes paresseux ne permet jamais à son système de tourner à plein régime. Il garde toujours de la place libre en cas d’imprévus. Il s’assure que le système ait assez de CPU, ainsi que de l’espace disque et de la RAM disponibles. Lorsque le service commercial décide de larguer des tonnes de données pendant la nuit, il n’a pas besoin de réfléchir à la façon de gérer cette croissance inattendue.

7. Être proactif. Être paresseux ne veut pas dire que vous devez juste vous assoir et vous tourner les pouces. Être paresseux signifie être proactif. Les administrateurs systèmes paresseux détestent être réactifs. Ils anticipent toujours les difficultés et l’expansion. Lorsqu’ils ont du temps libre à disposition (et ils en ont donc beaucoup), ils gardent un œil attentif sur les projets afin de gérer la future croissance et éviter que des problèmes non prévus adviennent.

8. Adorer les raccourcis clavier. L’administrateur systèmes fainéants connaît tous les raccourcis clavier de toutes ses applications favorites. S’il passe quotidiennement un temps significatif sur une application, la première chose qu’il fait est de maîtriser les raccourcis clavier de cette application. Il tient à passer le moins de temps possible sur l’application pour parvenir à ses fins, et ainsi redevenir paresseux.

9. Passer maître de la ligne de commande. Tous les administrateurs systèmes paresseux sont des pros des lignes de commande. Cela s’applique aux administrateurs systèmes Linux, aux administrateurs de bases de données, aux administrateurs réseaux, etc. Si vous voyez un administrareur systèmes lancer une interface graphique alors que la même tâche peut être effectuée en ligne de commande, alors vous savez qu’il n’est pas un administrateur systèmes paresseux. Il y a deux raisons pour lesquelles les administrateurs systèmes paresseux adorent les lignes de commande. D’une, il peut faire les choses rapidement en ligne de commande. Et d’autre, ça lui donne l’impression que c’est lui le patron et non pas le système. Quand vous utilisez les lignes de commande, vous avez le contrôle, vous savez exactement ce que vous voulez faire. Quand vous utilisez une interface graphique, vous êtes à sa merci sans être sûr à 100% de ce qu’il va produire après votre clic.

10. Apprendre de ses erreurs. Les administrateurs systèmes fainéants n’aiment jamais faire les mêmes erreurs deux fois. Ils détestent travailler sur des problèmes imprévus, mais quand ils apparaissent, ils travaillent à le corriger, réfléchissent à comment cela est arrivé, et mettent immédiatement le nécessaire en place pour que cela n’arrive pas de nouveau. Travailler sur le même problème deux fois est considéré comme un véritable péché pour un administrateur système fainéant. Il aime travailler sur le problème une seule fois, faire ce qu’il faut pour prévenir l’apparition de la même erreur dans le futur, et retourner tranquillement paresser.

11. Se former en continu aux nouvelles technologies. Il n’y a rien de mal à apprendre de nouvelles technologies pour avoir un meilleur travail ou juste pour se tenir à jour des progrès dans le domaine. Mais un administrateur systèmes paresseux n’apprend pas de nouvelles technologies pour cette raison. Il s’y forme parce qu’il aime garder le contrôle sur les systèmes en permanence. Il sait que c’est lui le chef et non pas la machine. Ainsi, quand arrive une nouvelle technologie, il prend le temps de l’étudier. À présent, il a de nouveaux outils pour occuper le système tandis qu’il continue à paresser. C’est la paresse qui est la principale motivation de sa formation.

12. Tout documenter. C’est ce qui distingue les bons administrateurs systèmes des meilleurs administrateurs systèmes. Voyez-vous, l’administrateur systèmes paresseux déteste être dérangé lorsqu’il est sur la plage à profiter de ses vacances. Donc, que fait-il ? Il documente tout, de manière à ce que lorsqu’il n’est pas là, d’autres puissent faire le boulot de base à sa place, et fassent tourner les choses sans le déranger pendant ses vacances. Il y a une autre raison pour laquelle l’administrateur systèmes paresseux documente tout : parce qu’il oublie des choses. Comme il est fainéant, il a tendance à oublier ce qu’il a fait le mois précédent. Puisqu’il n’aime pas du tout réfléchir deux fois sur le même sujet, il documente tout, et quand il aura besoin de faire la même chose dans le futur, il reviendra à sa documentation pour comprendre ce qu’il avait fait la fois précédente.

Voilà. Être un administrateur systèmes fainéant, ce n’est pas si simple en fait, c’est même beaucoup de travail. Si vous n’en êtes pas, vous saurez désormais les reconnaître. Si vous en êtes et que vous courez toujours partout, vous savez maintenant ce qu’il vous reste à faire.

Crédit photo : Anita Hart (Creative Commons By-Sa)

Grande et bonne nouvelle, d’après Microsoft la prochaine version 2013 de la célèbre suite bureautique Office intégrera le format ouvert OpenDocument (ou ODF) dans sa version 1.2. Elle sera également capable d’ouvrir, enregistrer et même éditer du format PDF (voir le tableau comparatif issu de Microsoft en fin d’article).

Cela fait des années que les partisans d’une réelle interopérabilité le demandent. Et cela fait des années aussi que le format PDF est présent sur la suite bureautique libre OpenOffice.org / LibreOffice.

Du coup le journaliste Simon Phipps y voit clairement une victoire de l’open source. Et vous ?

Comment Microsoft été forcé d’ouvrir Office

How Microsoft was forced to open Office

Simon Phipps – 17 août 2012 – InfoWorld.com
(Traduction : Damz, ehsavoie, Patchidem, Calexo, Nek, Fe-lor, Grummfy, Sylvain, Gatitac, Skhaen, ProgVal, Bohio, joe, HgO, Cypher, Jimmy)

Dans Office 2013, la prochaine version de sa célèbre suite bureautique, Microsoft a été contraint de prendre en charge totalement le véritable format ODF, au même titre que le format PDF. Voici comment l’open source a gagné.

Plus tôt cette semaine dans un article de blog, le responsable des standards Office, Jim Thatcher, a décrit les changements à venir dans Office :

Dans la prochaine version d’Office, nous avons ajouté l’utilisation de deux formats supplémentaires : Strict Open XML et Open Document Format (ODF) 1.2. Nous avons aussi intégré la possibilité d’ouvrir des documents PDF afin de pouvoir les modifier dans Word et de les enregistrer dans n’importe quel format. En ajoutant la prise en charge de ces formats de document standardisés, Microsoft Office 2013 offre à ses utilisateurs de nouvelles possibilités quant à l’intéropérabilité des documents bureautiques.

Dans ces quelques mots arides, nous pouvons trouver les échos d’une leçon d’histoire qui nous démontre le pouvoir de l’open source pour garantir la concurrence et favoriser l’innovation, tous deux précieuses sur les marchés du logiciel. Les formats de fichiers ne sont manifestement pas le sujet le plus excitant, mais cette annonce apporte une lumière sur deux faits importants à propos de l’open source : dans un premier temps, le logiciel open source peut être celui qui impose son rythme à la concurrence. Puis, dans un second temps, l’innovation open source fournit les bases solides sur lesquelles d’autres peuvent s’appuyer.

Le triomphe de l’ODF

Au tout début de la dernière décennie, Microsoft Office a quasiment chassé toute concurrence des logiciels bureautiques. Dans ce quasi-monopole, Sun Microsystems a lancé un projet open source en 2000, basé sur la suite bureautique de niche « StarOffice ». Connue sous le nom d’OpenOffice.org, la suite a progressivement pris de l’ampleur pour devenir l’alternative open source à Microsoft (NdT : Cf cet article du Framablog De StarOffice à LibreOffice 28 années d’histoire).

Alors que certaines personnes ont été promptes à accuser OpenOffice.org d’être un dérivé d’Office, elle égale la première version de Word de Microsoft (en 1983 pour Xenix) puisqu’elle a été créée en 1984, visant les ordinateurs personnels populaires de cette époque : le Commodore 64 et l’Amstrad CPC sous CP/M. Elle a ensuite évolué en une suite bureautique pour DOS, OS/2 Warp d’IBM et Microsoft Windows. Quand Sun Microsystems a acquis OpenOffice.org en 1999, il s’agissait d’une application complète et multifonction disponible sur toutes les plates-formes populaires de l’époque.

À leur arrivée chez Sun, les développeurs de StarOffice/OpenOffice.org ont accéléré le projet de créer un format moderne, basé sur XML, pour leur suite. En utilisant un format basé sur XML, il était plus facile de promouvoir l’interopérabilité avec d’autres outils bureautique, ainsi que de maintenir la compatibilité d’une version à l’autre.

Ce problème de l’omniprésence du format .doc ou .xls était le fléau de tous les utilisateurs d’outils bureautique, aussi Sun a pris l’initiative d’aller voir l’OASIS et a proposé une solution : un format de fichier standardisé pour le travail bureautique. J’ai été impliqué dans cette activité et je sais de source sûre que Sun a approché d’autres membres de l’OASIS pour qu’ils contribuent au projet. Toutefois, Microsoft a refusé, en qualifiant cette proposition de « superflue », préférant garder son juteux marché captif d’utilisateurs conditionnés à ses propres formats propriétaires.

OASIS a accepté la proposition et le résultat fut le standard OpenDocument, l’ODF. Malgré un départ difficile, l’adoption de l’ODF a fait boule de neige ; aujourd’hui, le format est un standard ISO et est approuvé/homologué à travers le monde. La pression sur Microsoft est devenue suffisamment forte pour que l’entreprise manipule le monde des standards internationaux afin de créer un format de fichiers XML standard concurrent basé de très près sur les formats utilisés dans Microsoft Office. Il a finalement été accepté par l’ISO en 2008.

Il aura fallu presque 7 ans, mais Microsoft a cédé. En avril, la société a annoncé qu’elle implémenterait complètement dans Office 15 à la fois le standard basé sur Office qu’elle a fait passer en force à l’ISO (standard ISO/IEC 29500, communément appelé OOXML) et les standards poussés par la communauté qu’elle émulait (standard ISO IEC 26300, communément appelé ODF).

L’open source a changé le marché, forçant Microsoft à réagir et à mettre en place la compatibilité de version à version et le concept d’interopérabilité. Sans l’open source, rien de cela ne serait arrivé. Avec l’open source, même si vous n’utilisez pas vraiment le format ODF vous-même, vous bénéficiez d’un marché compétitif et revigoré.

PDF a « presque » son dû

Le second point que souligne le blog de Microsoft est le pouvoir de l’innovation ouverte. La communauté OpenOffice.org a majoritairement migré en 2010 – avec le code – vers un nouveau projet open source nommé LibreOffice. Les projets OpenOffice.org et LibreOffice ont longtemps pris en charge la création de fichiers de type Portable Document Format (PDF). Microsoft Office a fini par copier cette fonctionnalité, d’abord comme une extension à Office 2007, puis comme une fonctionnalité intégrée par défaut. Cependant, LibreOffice inclut aussi la possibilité intéressante de pouvoir créer des fichiers Hybrid PDF qui peuvent ensuite être ré-ouverts et réédités avec LibreOffice. Si vous souhaiteriez essayer vous-même d’éditer des Hybrid PDF, cette vidéo vous expliquera comment faire.

Il semblerait que cette fonctionnalité soit sur le point d’arriver également dans Office :

Avec cette version, Microsoft introduit l’option, que nous appelons « PDF Reflow », qui permet d’ouvrir des fichiers PDF en tant que documents de bureautique éditables. Comme Tristan Davis, responsable du développement de Word, l’expliquait : « avec cette fonctionnalité, vous pouvez retransformer vos PDF en documents Word entièrement éditables, rendant alors modifiables les titres, les listes à puces ou numérotées, les tableaux, les notes de bas de page, etc. en analysant les contenus des fichiers PDF ».

À l’heure actuelle, le seul problème éventuel est de voir Microsoft limiter l’interopérabilité et la compatibilité de la prise en charge de l’ODF et de sa version de PDF hybrides. Pour des raisons inexpliquées, la société ne va pas proposer la possibilité d’enregistrer les fichiers comme un fichier ODF rétro-compatible (la version prise en charge actuellement dans Office 2012, le format ODF 1.1), donc il sera plus difficile dans un environnement mixte d’utiliser l’ODF. De la même façon, j’ai été conforté dans l’idée que, malgré la prise en charge de l’ouverture de fichiers PDF pour édition, Microsoft ne prend pas en charge l’ouverture des fichiers hybrides PDF de LibreOffice. Peut-être que la menace concurrentielle des logiciels open source est encore trop grande ?

À l’instar de la gestion initiale de l’enregistrement au format PDF, l’ajout de l’édition de documents PDF est un signe de bienvenue à ce qui a été essayé et testé en tant qu’open source. Telle est la dynamique de l’innovation. Les idées créent des idées, et l’innovation est le résultat de l’innovation.

Ici, la différence est que les communautés open source diffusent librement leurs idées à tout le monde, il n’y aura donc pas de menaces juridiques, pas de procès pour violation de brevets, et pas de licence d’utilisation coercitive (et confidentielle). C’est la façon dont les choses doivent se passer si nous voulons voir l’innovation continuer à germer grâce à un marché sain et compétitif.

Crédit photo : Camknows (Creative Commons By-Nc-Sa)

Et n’hésitez pas à venir nous passer le bonjour sur notre stand Framasoft (mais pas trop tôt le matin quand même, surtout au lendemain du Repas du libre !).

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Le dimanche 10 juin prochain aura lieu le premier tour des élections législatives françaises.

Dans plus d’une centaine de circonscriptions, vous avez le choix entre aller à la pêche, voter pour un parti traditionnel ou, et c’est nouveau, apporter votre voix au Parti Pirate (PP) et ainsi donner de la voix aux thèmes qu’ils soutiennent et qui nous sont chers.

Rencontre avec Carole Fabre (candidate pour la 3ème circonscription de Haute-Garonne), Pierre Mounier et David Dufresne (respectivement candidat et suppléant pour la 15ème circonscription de Paris) que nous connaissions avant qu’ils ne se présentent et qui ont bien voulu répondre à quelques-unes de nos questions.

Espoir et énergie communicative. À force de pousser de tous les côtés, nous finirons bien par faire bouger les lignes 🙂

Bonjour à tous les trois, pouvez-vous vous présenter succinctement ?

Carole Fabre (CF) : Actuellement, je fais du conseil formation autour des usages du web, j’essaie d’amener le partage, la collaboration, la réciprocité, les liens, l’éthique, la responsabilité numérique, que ce soit pour la veille, pour l’identité numérique, pour les médias sociaux, pour le management, etc … Je donne aussi des cours ponctuellement.

David Dufresne (DD) : Punk un jour, punk toujours. Je suis aussi journaliste à l’ancienne, et réalisateur de webdocumentaires. Incapable de tenir une guitare, je pianote sur mon clavier toutes la journée. Ma première connexion remonte à 1994. Je passais par un prestataire américain, CompuServe. On payait en dollars. Et certains mois, la parité franc/dollar jouait de sales tours.

Pierre Mounier (PM) : Je suis professeur de lettres ; je travaille aujourd’hui dans l’édition numérique de sciences humaines et sociales en libre accès.

Qu’est-ce qui, dans votre CV, peut expliquer cet engagement ? Est-ce votre premier pas en politique ? Et dans la vie associative ?

CF : Dès la fin des années 80, j’ai eu un ordinateur personnel et je suis connectée à Internet depuis 1996. J’ai rapidement compris que le numérique allait changer considérablement nos façons de faire et qu’Internet nous ouvrait des voies inédites pour plus de partage et de collaboration.

Petit à petit, il s’est dessiné un chemin nouveau, une autre façon d’envisager les relations humaines, les liens sociaux; la puissance du réseau des réseaux est devenue incontournable. Elle nous a montré une autre voie possible en nous connectant aux autres dans le monde entier, un accès inépuisable aux connaissances, une entraide pour apprendre, l’autonomie pour publier, une voie plus libre, plus responsable !

Mais cette liberté fait peur, surtout à ceux qui dirigent, aux experts, aux enseignants, …, à tous ceux qui pensent avoir autorité sur d’autres. Alors ils reculent et je n’ai pas envie de reculer mais d’avancer. C’est pourquoi j’ai rejoint le Parti Pirate. Je n’avais jamais envisagé avant de rejoindre un parti politique, les trouvant tous à mille lieues des préoccupations essentielles, les regardant fonctionner avec leurs petits pouvoirs, leurs petites visions, leurs fonctions à privilégier.

Non, la politique ce n’était pas pour moi. Mais la virulence qui s’est accentuée, et cela dans le monde entier, contre les libertés acquises, numériques ou pas numériques, a fait que j’ai sauté le pas. Insidieusement, certains tentent de faire d’Internet une simple télévision pour consommateur, certains tentent de surveiller et de punir la liberté d’expression, certains tentent de nous mettre en fichiers, certains tentent d’empêcher le partage. Et toutes ces tentatives ricochent par effet induit dans la vie de tous les jours. Vidéosurveillance, vidéo-protection, fichage biométrique, scanners corporels dans les aéroports, brevetage du vivant … bientôt les marchandises seront plus libres que les humains.

Je ne peux cautionner cela et rester à attendre sans rien faire. La société qui advient est basée sur le numérique, que ce soit la création monétaire, les logiciels boursiers, le vote électronique, …, toute la communication, tous les échanges. Il est temps de décider ce que l’on désire vraiment comme société.

Une autre raison m’a poussée à me porter candidate. Je milite activement depuis 3 ans pour l’instauration d’un revenu de base pour tous. Et le Parti Pirate français le propose en mesure compatible avec le programme national.

DD : Il y a très longtemps, en 2000, l’un de mes livres était intitulé « Flics et Pirates du Net » (écrit avec Florent Latrive)… Autant dire que la question du « piratage » me travaille depuis un certain temps. A dire vrai, depuis 18 ans maintenant, mon travail se partage entre le Net et les questions liées aux libertés (individuelles, collectives).

La nuit, je milite pour un Net ouvert et non marchand; le jour, je réalise des films et écrit des enquêtes sur la police, la justice. Le Parti Pirate rejoint mes deux préoccupations, en quelque sorte. Oui, premier engagement au sens engagement-parti-politique; oui, première carte politique. Pour être franc: je suis le premier étonné, moi qui suis d’ordinaire si réfractaire à toute idée de hiérarchie. Mais le PP est assez foutraque, et plein d’énergie, pour être excitant.

PM : je me suis intéressé aux enjeux politiques et sociaux d’Internet et du numérique à partir de la fin des années 90. J’ai créé un site, Homo Numericus, qui m’a permis d’explorer la révolution numérique dans ses différentes dimensions. J’ai bien vu lors des premières lois qui ont été adoptées sur la sujet qu’il y avait un décalage considérable entre les usages réels des internautes et la manière dont la classe politique traditionnelle considère et prétende réguler ces usages.

J’ai été proche de plusieurs associations de défense des libertés sur Internet et j’ai participé à plusieurs des mobilisations à l’occasion du vote sur ces lois. Et à chaque fois, j’ai été déçu par la faiblesse et le manque de retentissement de ces mobilisations. Tout se passe encore comme si les questions politiques liées au numérique relevaient encore d’un autre monde virtuel sans prise avec la vie réelle. C’est pour cela que j’ai cherché une autre forme d’engagement, qui cherche à prendre pied dans le réel, sur le terrain même des politiques, en établissant un rapport de force, en présentant des candidats aux élections.

Pas n’importe quel engagement : le Parti Pirate. Alors pourquoi lui et pas un autre ? Où se situe son originalité et son espoir ?

CF : Comme une vague générationnelle, le Parti Pirate, présent dans 64 pays, déferle sur le monde ancien. Ce n’est pas un parti enfermé dans ses frontières, il y a quelque chose de beaucoup plus fort, beaucoup plus important que les vaines revendications des autres partis politiques complètement sclérosés, incapables de lever le nez hors de leurs privilèges; Je ressens un souffle de liberté avec le Parti Pirate, d’ailleurs les libertés sont au cœur du programme politique. Liberté, un mot, que l’on a très rarement entendu pendant les présidentielles…

DD : Comme Carole, parce que je crois que le PP peut déferler sur le monde ancien, le bousculer, le hacker et le hâcher menu. Il faudra du temps, il faudra même passer — peut-être ? — par une forme de durcissement du discours, mais c’est jouable. Et plus que tentant. Certains adhérents du PP revendiquent le ni droite ni gauche. Pas moi. Je comprends bien l’idée (« ni droite ni gauche, devant ! »), qui est séduisante sur bien des points, elle reste pour l’heure trop floue. Personnellement, je suis venu au PP pensant y trouver un levier pour hacker la gauche de gauche.

PM : j’ai été conquis par cette idée de démocratie directe qui est au cœur du Parti Pirate. Le Parti Pirate est né de l’Internet. Il en porte la culture politique : horizontal, peu de délégation, ouvert aux contributions de tous, se coordonnant de manière flexible et réactive.

Peut-on vous qualifier de « power user » d’Internet et si oui en quoi cela a pu faciliter le rapprochement avec le Parti Pirate et ses thèmes de prédilection ?

CF : Oui, je dois être « power user », c’est ça 🙂 (voir réponses plus haut)

DD : Je suis Interneto-dépendant, littéralement. C’est affreux, et délicieux. J’imagine que bien des lecteurs du Framablog ressentent la même chose. Ma grande (et bonne) surprise a été de voir, en arrivant au PP, que ce n’était pas, justement, les Internautes Anonymes. Tous les sympathisants ne sont pas forcément des « power users ». On est loin de l’image des réunions de Geeks parfois, et c’est très bien ainsi. Ça montre que le PP fédère large.

PM : Oui, c’est évident. Je travaille avec Internet, je vis sur Internet et je considère le cyberespace comme ma patrie d’adoption. Mais en même temps : n’est-ce pas le cas d’un très grand nombre de personnes ? Ne sommes-nous pas tous des power users ?

La plupart des enquêtes le montrent : les usages des nouvelles technologies sont très répandus et intensifs, souvent sur un mode de communication particulier. Tout le secteur tertiaire travaille en permanence sur ordinateur. Les services de communication en ligne ont des millions d’utilisateurs, les smartphones ont un taux de pénétration considérable.

Ce qui est caractéristique de nos trois profils en revanche, c’est que nous sommes des médiateurs : formateur, journaliste et enseignant. Nous ne sommes donc pas nécessairement plus « geeks » que d’autres, mais je crois que nous sommes dans des positions qui nous amènent à avoir une conscience plus aiguë de ces nouveaux usages et de leurs implications politiques.

La « grande presse » a consacré de nombreux articles à la présence du Parti Pirate lors de ces élections. Est-ce déjà un succès en soi et êtes-vous satisfait de la manière dont les journalistes ont parlé de vous ?

DD : La presse a besoin de nouveauté, et il ne faut pas s’y tromper: l’incroyable couverture récente du PP doit beaucoup à cet aspect des choses. Les résultats de dimanche, bien sûr, seront importants pour la suite que la presse voudra bien accorder, ou non, au PP. L’essentiel est que le nom ait circulé dans les rédactions, que le PP se soit fait une petite place, que nous ayons, par exemple, été repris du Figaro à TF1, du Monde à Europe 1, sur la question du vote par Internet des Français de l’étranger, au point que le Quai d’Orsay se soit senti contraint de nous répliquer. Ou que Marianne, en nous rangeant dans les « farfelus », se soit vu immédiatement contredit sur Twitter.

Malgré le retentissement récent, tout reste à faire. Je pense qu’on peut être plus inventifs, plus percutants, plus pirates. D’autant que nous butons sur un sacré conservatisme de la part des journalistes politiques. Ne pas comprendre que ce qui se joue aujourd’hui d’un point de vue technologique est aussi crucial que les combats écologiques lancés par les Verts est, au mieux, une preuve de cécité de leur part; au pire, une faute professionnelle.

CF : C’est un premier pas. Il est vrai que les succès électoraux en Allemagne nous ouvrent la voie. Localement, c’est assez amusant, la première fois que la Dépêche du Midi nous a cité, ils ont mis PP Parti Populaire… ils n’avaient jamais entendu parler du Parti Pirate !

En général, nous sommes encore trop qualifiés de geeks et d’informaticiens à lunettes, les journaliste ont du mal à voir que nos revendications dépassent largement Internet. Peu signalent par exemple que nous nous engageons à suivre la charte anti-corruption de Anticor. Dès qu’on parle de transparence politique ils sont assez surpris et tentent de nous faire revenir sur le téléchargement 😉

PM : Oui, et je dois avouer que c’est une surprise pour moi. La plupart des mouvements politiques et mouvements sociaux d’un type nouveau traversent une longue période à leurs débuts au cours de laquelle les médias ne leur donnent aucune visibilité et, pire, déforment leur positionnement et leurs propositions. Je trouve que cela n’a pas été trop le cas au cours de cette campagne. J’ai noté beaucoup de curiosité de la part des journalistes qui ont cherché à comprendre sincèrement ce qu’était ce mouvement.

Le meilleur exemple pour moi est l’article d’Yves Eudes dans le Monde qui établit une coupe sociologique objective du mouvement et qui a appris, je crois, beaucoup aux adhérents du Parti Pirate eux-mêmes… Par contre, cet article a été classé dans la rubrique…. Technologies. C’est caractéristique.L’engouement médiatique a beaucoup été le fait des secteurs culture et technologies de la presse, mais n’a pas encore touché le cœur du cœur du système médiatique : les journalistes politiques de la presse nationale qui ne nous ont pas encore repérés dans leur radar.

Le Parti Pirate a été très actif pour dénoncer le vote électronique des français de l’étranger. En quoi est-ce une affaire importante pragmatiquement et symboliquement parlant ?

CF : Encore une fois, nous comprenons et maîtrisons le numérique et savons que le numérique c’est piratable 🙂 … A partir de ce constat, il y a des choses que nous ne pouvons pas faire. Le vote électronique est incontrôlable. Peut-être un jour arriverons nous à sécuriser le vote électronique mais pas actuellement. Au-delà des problèmes techniques et de la non vérification possible par les citoyens, l’ironie est que c’est une entreprise privée d’Espagne qui s’occupe de gérer ce vote …

DD : À mes yeux, cette affaire constitue un enjeu majeur dans le sens où c’est un peu de la démocratie qu’on confisque, avec des dysfonctionnements patents, une privatisation partielle du vote, une opacité réelle. C’est bien parce que nous défendons Internet que nous nous devons de traquer les abus des pouvoirs publics et des sociétés privées. Le vote électronique des français de l’étranger est apparu au fil des jours pour ce qu’il est : un cheval de Troie.

Les Partis Pirates suédois et allemand ont une longueur d’avance. De plus lors des récentes manifestations contre ACTA on a pu voir l’Est de l’Europe beaucoup plus mobilisée que l’Ouest, France incluse. Y a-t-il une raison à cela et n’est-ce pas un indicateur défavorable quant à ces prochaines élections ?

CF : Même si nous parlons beaucoup d’ACTA entre acteurs du numérique sur Internet et que l’on sent tout de même un revirement positif de la situation au niveau européen, le problème est que la plupart des citoyens n’en ont jamais entendu parler ! Il faut expliquer encore et encore. En tout cas ce n’est vraiment pas au cœur des débats des autres partis politiques pour ces élections, que dis-je au cœur, c’est complètement absent. Et oui, c’est défavorable, car le grand public ne comprend pas encore l’importance de ces enjeux.

DD : La France est un pays terriblement passéiste et passablement frileux. Avec un Front National si fort, et une gauche parlementaire qui a si peur de son ombre, tout semble bloqué. Depuis déjà un paquet de temps, et pour longtemps. Nos voisins, moins auto-centrés, ont compris bien avant nous l’importance de la… révolution numérique. Sincèrement, oui, la bataille ne fait que commencer de ce côté_-ci du Rhin. C’est ce qui en fait, aussi, sa beauté: tout est à faire.

PM : Nous sommes un pays technophobe et c’est une malédiction qui nous frappe de manière renouvelée. Beaucoup de gens pensent que la politique s’arrête aux déclarations de principe (le « fétichisme des principes » est une autre de nos malédictions) et ne voient pas du tout comment il peut y avoir des enjeux politiques dans ce qu’ils considèrent comme des « affaires de garagistes » (sic, citation réelle).

Il y a bien une tradition intellectuelle française qui s’intéresse à la chose technique et à ses enjeux sociaux et politiques ; les encyclopédistes, Saint Simon, Simondon, Latour, Serres. Mais elle est isolée et minoritaire, rarement dominante à chacune des époques considérées. Or, c’est un vrai handicap, alors que nous vivons à une époque complètement dominée par des enjeux techno-scientifiques. Peut-on faire évoluer les mentalités et intéresser les français aux enjeux politiques des choix technologiques ? Je pense que la montée en puissance d’un Parti Pirate en France peut y contribuer.

Cory Doctorow a pu dire qu’il est fondamental de gagner la bataille actuelle contre le copyright car elle fait figure de laboratoire pour les autres batailles à venir entre le citoyen, les multinationales et les états affaiblis. D’accord pas d’accord ?

CF : Entièrement d’accord. Si les droits d’auteur et les brevets ont pu être profitables au XIXème siècle, ils sont maintenant complètement obsolètes. Nous devons repenser tout cela.

Quand on voit que certains tentent maintenant de breveter aussi le vivant … c’est impensable de s’approprier nos biens communs, breveter des gènes humains, des gènes animaux, des gènes de plantes. Quelle société cela préfigure t-il ? Avons-nous envie de tout marquer et de tout jouer en bourse ? Les dégâts sont bien déjà assez suffisants avec le marché des matières premières et des matières alimentaires.

PM : Oui, absolument. La conférence de Cory Doctorow devant le Chaos Computer Club si mes souvenirs sont bons est un moment historique qui a donné un sens politique général a un combat qui pouvait sembler à la fois pointu et un peu secondaire parce que concernant seulement la consommation culturelle.

Le logiciel libre est un des pionniers et un des piliers de la révolution à venir. Délire ou prophétie ?

CF : Prophétie, oui ! Quand on voit que près de 95% des serveurs dans le monde sont sous Unix et non pas sous Windows, nous nous devons de demander pourquoi c’est mieux fabriqué. Et comment ça se fabrique. Là encore, la pédagogie est indispensable, peu de personnes savent.

L’autre jour, je me demandais : « et si on ouvrait les codes de la loi et qu’on puisse les améliorer, et même en faire un fork pour simplifier, repartir sur des bases saines et non pas un empilement où plus personne ne comprend plus rien. » 🙂

Mais sans aller aussi loin, on constate déjà que des initiatives voient le jour dans d’autres domaines que les logiciels : des plans partagés et améliorés de moteur, des systèmes agricoles, des systèmes d’eau potables, etc.

C’est en fait naturel à l’être humain, pouvoir comprendre, contribuer, améliorer, cela s’est toujours fait. La propriété généralisée à toute chose est finalement assez récente dans l’histoire de l’humanité. Si le silex avait été breveté et privatisé, nous ne serions peut-être pas là aujourd’hui. 🙂 Et la roue, hein, la roue…

DD : C’est moins l’outil libre que sa confection qui importe. Ce que le logiciel libre bouleverse, c’est cette forme de société de contribution qu’il annonce. Cette notion de pot commun, de partage, de désintéressement parfois provisoire, qu’importe. Mais nous avons un effort de pédagogie à mener: seule la communauté du Libre sait de quoi il s’agit. Hors de celle-ci, libre et free, gratuit et open source, sont des notions encore mal comprises et qui semblent vidées de leur caractère politique.

PM : Ni l’un ni l’autre : le logiciel libre est aujourd’hui un des piliers fondamentaux de la révolution en cours (et non à venir). Mais cela implique de devoir résoudre des problèmes que pose ce mouvement continu d’élargissement du « libre » à d’autres secteurs d’activités que la conception logicielle.

Et sur ce chemin, la voie est étroite entre une forme d’intransigeance aristocratique et parfois puriste qui empêche la greffe de prendre d’un côté, et ce qui constituerait une dilution tellement importante qu’on n’y retrouverait plus l’esprit originel de l’autre : logiciel libre, art libre, culture libre, creative commons, libre accès, open data, on a là une galaxie qui témoigne d’une dynamique positive. Cette dynamique ne peut exister que parce qu’une certaine souplesse est permise, mais aussi parce qu’un sens et des limites sont données.

Occupy, Anonymous, Indignados, Wikileaks sont des mots clés qui vous parlent ?

CF : Yep ! Tous ces mouvements dénoncent les opacités, les corruptions qui entachent notre civilisation et chacun à leur manière agit soit par Internet, soit dans la rue. Au Parti Pirate, on attaque par un autre biais, on tente de hacker la politique.

DD : + 1, Carole. Le Parti Pirate est un allié, sincère, de tous ces mouvements. Ils sont le signe du changement réel, d’une prise de conscience à la fois mondiale et citoyenne. Non violente pour certains, intrusives et hors la loi pour d’autres. Le phénomène des casseroles à Montréal s’inscrit aussi dans cet élan. Et ce n’est pas pour rien que les Anonymous ont infiltré les serveurs de la police canadienne dans le même temps ou diffusé des vidéos gênantes sur la collusion médias-politiques.

PM : Oui. Mais je me permets d’insister sur un fait : toutes ces initiatives qui procèdent de mouvements sociaux de fond n’ont pas encore trouvé de débouché politique. Je crois qu’on a tous un peu vécu sur le mythe qu’un pouvoir en place ne peut résister longtemps à des manifestations, occupations, assemblées populaires, mobilisations citoyennes, révélations compromettantes.

L’expérience politique de ces dernières années est que ce n’est pas tout à fait le cas. Et même lorsqu’il y a alternance, cela ne signifie pas nécessairement que les revendications que portent ces mouvements soient mieux représentées. Il y a donc une situation potentielle de danger avec des mouvements sociaux d’un côté qui se développent, bouillonnent, élaborent des propositions, et de l’autre un monde politique qui tourne en rond et continue sa petite musique sans que l’un n’arrive à embrayer sur l’autre.

Je ne dis pas que la Parti Pirate soit aujourd’hui en mesure d’être le débouché politique des ces mouvements. Ce serait très prétentieux et inexact. Mais je pense que c’est la direction dans laquelle nous devons aller. Pour moi, un des enjeux après les élections pour le Parti Pirate est de construire patiemment des liens solides avec ces mouvements, et d’autres, pour nourrir sa réflexion et son programme de l’expertise citoyenne qui s’y développe.

L’Europe semble bloquée par « la crise », une économie financiarisée injuste et incontrôlable et des mouvements identitaires de repli sur soi. Est-ce la bonne période pour « faire de la politique autrement” ?

CF : Plus que jamais, et il y a même urgence, tant que nous avons les moyens. La pauvreté, l’injustice amènent aux révoltes et aux guerres, et après il est beaucoup plus difficile d’agir.

DD : Si nous n’avons pas peur de nous-mêmes, si nous arrivons à nous regrouper autour de thèmes forts et précis, c’est déjà le cas en partie, tout est possible. Justement parce que nous sortons totalement des clivages et des raisonnements classiques, tous porteurs de repli.

PM : PLUS QUE JAMAIS. La crise financière et économique est d’abord une crise de la démocratie. La véritable question est moins de savoir quelles seraient les « bonnes » mesures à prendre que de savoir comment faire en sorte que les mesures qui sont prises soient voulues et soutenues par l’ensemble de la population ; en un mot : légitimes. J’ai écrit un billet à ce propos sur notre site de candidats ; je me permets d’y renvoyer.

Il a été dit que la France sous Sarkozy n’aura pas été spécialement brillante du côté d’Internet et des libertés. Votre avis ? Doit-on penser que vous accordez la même défiance au nouveau gouvernement en vous présentant ou bien est-ce au contraire pour le pousser à mettre en avant les thèmes que vous portez ?

CF : Les deux mon capitaine ! Si on peut interagir, aider à la réflexion tant mieux. Nous verrons bien. Personnellement, je n’ai guère confiance en ce nouveau gouvernement. Même si j’espère qu’il y aura moins de fracture sociale, j’ai bien peur que la notion de liberté et de partage leur échappe. Pierre Lescure, nommé pour la Hadopi, voyons, comment dire … Et que feront-ils des fichiers de citoyens, des caméras de surveillance, de la biométrie ?

DD : Sur la question des libertés individuelles et collectives, il n’y a aucune raison de laisser un blanc seing à la gauche socialiste. La nomination de Manuel Valls à l’Intérieur est assez claire: il n’y aura pas de rupture ou alors à la marge. J’ai en partie rejoint le PP pour travailler sur ces questions et c’est la raison pour laquelle avec Pierre Mounier, nous avons explicitement défendu notre point de vue dans notre profession de foi.

« Exiger que les procédures parlementaires de contrôle de services comme la Direction centrale du renseignement intérieur soient complètes et renforcées. Faire cesser les dérives d’une police politique au service de l’appareil d’Etat. Ouvrir le débat sur la privatisation du Renseignement (officines, mais pas seulement) et le jeu malsain entre « Services » et opérateurs de téléphonie (ex: fadettes, relevés téléphoniques, etc) / FAI. ». J’ai publié dans Le Monde une tribune sur le sujet.

PM : Pour ma part, je ne parlerai pas (encore) de défiance. Plutôt de méfiance. Le candidat devenu président ne s’est pas beaucoup engagé sur la question et il a même été en net retrait par rapport au programme de son propre parti. Les premiers signes qui ont été envoyés, les premières nominations, comme dit Carole, ne sont pas encourageantes. J’ai bien peur que ce gouvernement ait besoin d’un aiguillon qui constitue une menace électorale suffisamment importante pour qu’il se sente concerné par la question d’Internet et des libertés. On aura compris qui pourrait être cet aiguillon…

Vous donnez-vous le moindre objectif chiffré ou bien, comme disait De Coubertin, l’important ici c’est d’abord de participer car ça n’est qu’une première étape ?

CF : Comme Coubertin, c’est un galop d’essai !

DD : Un tour de chauffe, un moyen de s’aguerrir, d’expérimenter, de se compter, d’apprendre à se connaître, à partager, à travailler ensemble.

PM : C’est bien un galop d’essai, mais aussi un peu plus que cela : nous avons gagné une certaine visibilité dans l’espace public, du fait de la campagne électorale (il faut savoir que nous diffusons grâce à cela un spot télévisé visionné par tous les français, c’est absolument énorme comme caisse de résonance). Du coup, si, au moins dans certaines circonscriptions, nous faisons un score non négligeable, voire gênant pour d’autres formations politiques, cela va changer beaucoup de choses pour la suite. Bref, il y a un vrai enjeu en termes de résultats sur cette élection. Cela vaut le coup de se mobiliser.

Une fois les législatives passées, quel sera le prochain rendez-vous et comptez-vous personnellement poursuivre l’aventure avec le Parti Pirate ?

CF : Si le Parti Pirate continue sur la même lancée avec ouverture, transparence, liberté de chacun des membres, oui ! En 2014, il y a les municipales et surtout les européennes. Il devrait y avoir un programme commun européen, et là nous serons bien plus préparés !

DD : Le PP a vu dans ses rangs arriver de plus en plus de quadras et plus. On peut s’attendre à ce que le PP se dote bientôt d’une épine dorsale qui pourrait faire très mal. Connaissance des rapports de force + énergie bouillonnante = formule magique.

La prochaine étape sera donc interne: comment fusionner toutes ces énergies, les fédérer ? Ensuite, il faudra que le PP prenne part à la vie politique de manière constante, pas uniquement lors des échéances électorales. Pour ce qui est de mon implication, tout va dépendre des discussions et des orientations qui seront prises. Pour l’heure, comment dire, c’est bien parti, quelle aventure !

PM : Oui, j’ai très envie de continuer avec le Parti Pirate au delà de l’échéance. Il y a clairement une dynamique, un élargissement de la base militante, des perspectives de pouvoir faire bouger les choses, enfin !

En conclusion, dimanche 10 juin prochain, le « vote utile » c’est le Parti Pirate ?

CF : C’est le vote de ceux qui n’ont pas froid au yeux et qui arrêtent de penser « de toute façon, on ne peut rien faire ». Le Parti Pirate, c’est la reprise en main de la démocratie.

DD : Utile, heu… j’en sais rien. Protestataire et constructif, pirate et novateur, oui, vraiment.

PM : Le seul vote utile est celui qui est au plus proche des convictions de celui qui vote. que chacun s’informe et vote selon ses convictions. C’est tout ce que nous demandons.

Vous pouvez suivre nos trois candidats sur Twitter : Carole Fabre, Pierre Mounier et David Dufresne.

Qu’on les aime ou qu’on les déteste, les suites bureautiques se sont imposées ces derniers lustres comme indispensables dans le paysage logiciel. La suite numéro un, Microsoft Office, est devenue une référence et un incontournable. En langage courant, on ne parle plus de présentations ou de transparents, on dit tout simplement « un PowerPoint ».

Microsoft Office n’étant pas disponible sur les systèmes libres comme Linux, il est évident qu’une alternative viable se devait d’exister. Vous la connaissez certainement, il s’agit d’OpenOffice. Et, depuis quelques mois, on entend parler de LibreOffice. Mais n’est-ce pas juste un changement de nom ? Tout cela est un peu confus.

J’avais déjà tenté de faire une courte clarification. Essayons de voir en détail ce qu’il en est.

Les débuts de StarDivision

Nous sommes en 1984. Un très jeune programmeur allemand fonde la société StarDivision afin de vendre son logiciel de traitement de texte StarWriter. Celui-ci est destiné principalement aux ordinateurs Zilog Z80 et Amstrad CPC. Nous sommes dans les tous débuts de l’informatique à destination du grand public. Ni Microsoft Office ni même Windows n’existent encore.

Après quelque temps, StarDivision adapte son logiciel aux systèmes DOS, OS/2. D’autres composants se rajoutent à StarWriter : StarBase, un logiciel de base de données, StarDraw, un logiciel de dessin vectoriel. Le tout est empaqueté sous le nom global de StarOffice, en faisant une des premières suites bureautiques.

Avec le support de Windows 3.1, StarOffice gagne un nouveau composant, StarCalc, un tableur.

StarOffice dans le giron de Sun

Faisons un bond en avant et propulsons nous en 1999. À cette époque, Microsoft règne sans partage sur les ordinateurs individuels grâce à Windows 95 et Windows 98, sans oublier Windows NT dans les entreprises. Dans ces dernières, Microsoft Office 97 s’est imposé comme la suite office indispensable. Son plus gros concurrent est… Microsoft Works ! Eh oui, Microsoft se paie le luxe d’être son propre concurrent et d’avoir deux suites bureautiques qui sont difficilement interopérables (utilisant des formats propriétaires différents).

Sun travaille sur son système d’exploitation Solaris et espère en faire un concurrent à Windows. Le problème est que Solaris ne dispose pas d’une suite bureautique et que chacun des 42.000 employés de Sun doit garder deux ordinateurs : un sous Solaris et un sous Windows pour faire tourner Microsoft Office.

Stratégiquement, avoir une suite bureautique sous Solaris est indispensable. Sun se met en chasse et rachète StarDivision pour 73.5 millions de dollars. Rien que le prix économisé dans les licences Microsoft (42.000 licences Windows + 42.000 licences Office) permettrait de rentabiliser l’achat en quelques années.

Sun travaille donc à partir de la suite StarOffice et la porte sous Solaris.

Naissance d’OpenOffice

À peine un an plus tard, en 2000, Sun se rend compte que le seul ennemi capable d’affaiblir la toute-puissance de Microsoft, alors à son apogée, est le monde Open Source. Et selon l’adage « Les ennemis de mes ennemis sont mes amis », Sun décide de doter la communauté OpenSource d’un concurrent à Microsoft Office.

Une version Open Source de StarOffice est donc libérée sous le nom OpenOffice, qui deviendra OpenOffice.org, le nom OpenOffice étant déjà déposé dans certains pays.

Derrière ce mouvement se cache bien entendu une stratégie marketing. Sun espère qu’OpenOffice gagnera le cœur des étudiants, des particuliers, des hackers mais que les entreprises souhaitant un support professionnel se tournent vers StarOffice. Certaines fonctionnalités de StarOffice ne sont d’ailleurs pas présente dans OpenOffice.

Cela a pour conséquence que toute personne souhaitant contribuer au code d’OpenOffice doit céder ses droits à Sun, afin que celui-ci puisse le réutiliser dans StarOffice.

Sun OpenOffice, l’incontournable

De 2001 à 2010, OpenOffice va devenir incontournable chez les libristes et les utilisateurs de système Linux. Sa gratuité est également un atout indéniable dans les entreprises et les services publics. Certains évangélistes du libre y voient un cheval de Troie pour introduire le libre un peu partout et en font une promotion éhontée.

Cependant, tout n’est pas rose. Le développement n’est pas très rapide. Les contributions ne sont pas toujours acceptées par Sun. Le logiciel, vieillissant, acquiert une réputation de lenteur et de non-ergonomie.

Microsoft Office, de son côté, fait des progrès fulgurants avec les éditions 2003 et 2007. Malgré un succès d’estime, OpenOffice peine à sortir du cadre des geeks barbus.

Lotus Symphony, IBM rentre dans la danse

IBM, géant de l’informatique, est célèbre pour n’avoir jamais compris l’importance du logiciel et de la micro-informatique. Inventeur du PC, ils n’ont pas perçu le marché pour ce type de machine et ont laissé Microsoft fournir le système d’exploitation DOS. Se rendant compte de leur erreur, ils tenteront d’imposer OS/2 sans jamais y parvenir.

La même histoire se répète avec les suites bureautiques. Se rendant compte de l’importance de ce type de logiciel, IBM produira Lotus Symphony, une suite bureautique pour DOS. Cette suite sera complètement abandonnée en 1992.

Ce n’est qu’en 2007, à la mode des carabiniers d’Offenbach, qu’IBM décidera de relancer dans une suite de productivité qui comportera son client mail Lotus Notes, très populaire en entreprise et détenteur du titre de logiciel le plus haï par ses utilisateurs. IBM va donc reprendre OpenOffice et en modifier l’interface afin de créer IBM Lotus Symphony.

IBM Lotus Symphony est synchronisé avec OpenOffice mais aucun code n’est contribué au projet. En ce sens, IBM est vu comme un mauvais joueur par la communauté.

Oracle Open Office, la fin d’une époque

Sun ne va pas très bien. Solaris n’a jamais réellement percé. Le matériel Sun, d’excellente facture mais extrêmement cher, voit une concurrence rude tirer les prix vers le bas. Beaucoup d’investissements ont été faits comme le rachat de MySQL. Des questions se posent. C’est alors qu’arrive Oracle.

Oracle est un géant de l’informatique qui a fait sa fortune sur la gestion des bases de données. Ils aimeraient avoir un peu plus d’expertises dans le matériel (afin de vendre des serveurs liés à leurs bases de données) et contrôler un dangereux concurrent OpenSource qui est de plus en plus populaire : MySQL, justement racheté par Sun.

En 2009, Oracle rachète donc Sun pour 7,4 milliards de dollars. Seulement, Oracle n’a que faire de StarOffice ou d’OpenOffice. C’est le cadeau bonus venu avec l’achat et ça les ennuie plus qu’autre chose. De plus, contrairement à Sun, Oracle a montré de nombreuses fois qu’il se poste en ennemi acharné du logiciel libre.

En 2010, inquiets, les membres de la communauté OpenOffice créent donc la Document Foundation, une fondation sans but lucratif dont le but est de promouvoir et de continuer le développement d’OpenOffice, sans dépendre d’Oracle.

LibreOffice, la première suite communautaire

Il ne reste qu’un petit détail à régler : le nom, OpenOffice, appartient toujours à Oracle. La fondation fait une demande officielle à Oracle, Ô Oracle, vous qui êtes si puissant, si beau, si fort et qui n’avez que faire de ce misérable nom, cédez le nous et vous serez mille fois béni.

C’est à ce moment que les requins de chez Oracle lèvent les sourcils. Si ce nom est demandé, il a peut-être une certaine valeur. IBM met son grain de sel : si Oracle cède le nom à la fondation, IBM peut très bien ne plus pouvoir intégrer le code d’OpenOffice dans son Lotus Symphony qui est propriétaire, la Document Foundation soutenant des licences cancérigènes comme la LGPL !

Oracle refuse donc de céder le nom. La mort dans l’âme, la Document Foundation décide d’accepter la mort d’OpenOffice et de faire renaître le projet sous le nom LibreOffice.

Au final, ce changement de nom se révèle bénéfique. Comme le passage de XFree86 à X.org, il marque la transition. L’engouement communautaire est tel qu’en moins d’une année LibreOffice gagne des dizaines de contributeurs, un nombre impressionnant de lignes de code est changé et une première conférence rassemblant la communauté à lieu à Paris en octobre 2011. Conférence au cours de laquelle il est annoncé notamment le désir de porter LibreOffice sur Androïd. Les participants assistent également à une première démonstration de LibreOffice Online, une version web de la suite bureautique.

Apache Open Office, papy fait de la résistance

Mais il serait faux de penser qu’Oracle en resterait là. Tout aurait pu être tellement simple. Mais il ne faut jamais sous-estimer la nuisance qu’une confusion dans l’esprit du public peut apporter.

Peu après l’annonce de la création de LibreOffice, Oracle décide de donner le projet OpenOffice, y compris le nom, à la fondation Apache. À charge pour elle de continuer le développement de ce projet.

À la Document Foundation, tout le monde est un peu surpris. Surtout que la licence Apache choisie permet à LibreOffice de reprendre du code de chez Apache OpenOffice mais le contraire n’est lui pas possible. En juillet 2011, IBM annonce sa volonté de contribuer au projet Apache OpenOffice et, début 2012, annonce même arrêter complètement IBM Lotus Symphony pour se concentrer uniquement sur Apache OpenOffice.

OpenOffice ou LibreOffice, lequel choisir ?

Pour beaucoup, Apache OpenOffice n’est donc qu’un homme de paille, un projet IBM, qui sert les intérêts d’IBM et non ceux de la communauté. Après quelques mois, il faut se rendre à l’évidence: le projet Apache OpenOffice dispose de dix fois moins de contributeurs. Comparer le nombre de modifications du code entre les deux projets est également sans appel : LibreOffice est un projet libre, communautaire et OpenOffice est une anecdote poussée à contre-cœur.

La majorité des distributions Linux sont d’ailleurs passées à LibreOffice. Des grands projets se mettent en place: la région Île-de-France travaille à offrir un LibreOffice intégré avec sa solution Cloud à tous ses étudiants. Un écosystème de sociétés a rejoint la Document Foundation afin d’offrir du support professionnel sur LibreOffice, depuis les grands pontes comme Suse, partie de Novell, au petites structures comme Lanedo, employeur de votre serviteur.

Si l’offre est là, la demande est elle en pleine confusion. Des clients de Sun, payant pour le support d’OpenOffice, se sont retrouvés sans maintenance du jour au lendemain. Le changement de nom fait craindre une migration lente et coûteuse, beaucoup ne comprenant pas qu’il s’agit essentiellement du même logiciel.

Si l’avenir de LibreOffice semble radieux, beaucoup ne le saisissent pas encore. Mais, maintenant, si jamais on vous pose la question de savoir la différence entre OpenOffice et LibreOffice, vous pourrez répondre : « Assieds-toi, je vais te raconter une histoire… ».