Nouvelle semaine, nouveau point hebdomadaire. Avec quelques jours de retard puisque celui-ci aurait du paraitre jeudi dernier.

Les tâches réalisées

La semaine dernière, nous avons abondamment parlé d’une anomalie gênante autour d’Etherpad, de yajsml et de MyPads. Une solution de contournement a été trouvée mais devra être confirmée : pour réinstaller le plugin, il semblerait qu’après l’avoir désinstallé, la suppression forcée du cache NPM (se situant en général dans un répertoire caché, /home/user/.npm) permette de ne plus éprouver le problème. Nous verrons une fois MyPads publié sur NPM, et non installé en local, si ce contournement deviendra inutile et mettrons en œuvre ce qu’il faudra pour améliorer la situation si ce n’est pas le cas.

En dehors de cela, cette semaine a été consacrée essentiellement au module de gestion des groupes avec l’affichage de la liste des groupes, leur création. À propos de la notion, centrale, de groupe dans MyPads :

• chaque utilisateur, authentifié, peut créer un nombre illimité de groupes;
• ceux-ci contiennent chacun un nombre illimité de pads;
• chaque groupe dispose d’un identifiant unique en base de données et d’un label;
• au niveau du groupe, il est demandé de définir une visibilité pour les pads qui seront contenus
  • restreinte : uniquement pour les personnes explicitement invitées, lesquelles devront posséder ou créer un compte sur l’instance MyPads;
  • privée : accès restreint à l’utilisation d’un mot de passe et dans ce cas, un compte n’est pas nécessaire;
  • publique : les pads contenus sont accessibles par leur adresse Web, comme c’est le cas aujourd’hui sans MyPads.
• cette visibilité est appliquée par défaut mais pourra être écrasée individuellement pour chaque pad contenu;
• un groupe pourra être mis en lecture seule, pour consultation uniquement;
• chaque groupe pourra voir son administration partagée avec d’autres utilisateurs, qui pourront alors en modifier les propriétés et y créer des pads;
• en plus de ce qui était prévu initialement
  • chaque utilisateur pourra mettre en favori un ou plusieurs groupes auxquels il participe;
  • il sera possible d’associer des étiquettes (tags) pour chaque groupe.

Semaine 19

Le travail sur les groupes va être poursuivi. En théorie, nous devrions obtenir en fin de semaine :

• la suppression des groupes;
• les étiquettes, favoris;
• les filtres et la recherche dans la liste de groupes;
• les tests fonctionnels qui vont avec le module groupes.

Lorsque la gestion des groupes sera terminée, celle des pads arrivera rapidement, puisque cette dernière sera similaire à celle des groupes, et même simplifiée par rapport à elle.
Rendez-vous en fin de semaine pour le prochain point.

MyPads, week 18

New week, new point with a delay of couple of days : this news should have been published last Thursday

Tasks done

Last time, we’ve copiously talked about an annoying bug around Etherpad, yajsml and MyPads. A workaround has been found but must be confirmed : to install the plugin again, it seems that, after uninstalling it, a forced removal of NPM cache (which resides into a hidden directory, like  /home/user/.npm) helps to not suffer from the problem. We’ll check after MyPads publication under NPM public repository if this workaround becomes useless. We’ll work to improve the situation otherwise.

Apart from this bug, the week has been mostly dedicated to group management module : list display, creation. About the groups main concept in MyPads :

• every user, authenticated, can create an unlimited number of groups;
• those one can contain one or more pads;
• each group has a database unique identifier and a name;
• for each group, you’ll have to define a visibility level for linked pads
  • restricted : only invited users can view and edit pads, people who need a MyPads account;
  • private : the access is protected by a password, in this case, the account isn’t mandatory;
  • public : pads are accessible through their Web address, like in classical Etherpad.
• this visibility property is applied by default to all attached pads but can be overwritten for each pad;
• a group can be set up on read-only mode;
• each group can be shared with other users, then they will be able to edit its properties and create new pads into it;
• bonus elements
  • each user can bookmark one or more groups;
  • tags can be assigned to each group.

Week 19

Work in groups management will continue. In theory, we should get, at the end of the week :

• group removal;
• tags and bookmarks implementation;
• research and filters from the group list;
• functional testing of the groups module.

When the groups management will be finished, pads management will be out quickly, because it will be similar, and even simplified.
See you at the end of this week for the next point.

Edit du 20 août : L’article Logiciels à l’ère libre est désormais en ligne sur le site de Libération (voir aussi La règle de quatre du logiciel libre).

Allez, aujourd’hui on achète la version papier du journal Libération, on le partage avec ses proches non initiés, puis on le garde précieusement dans ses archives !

De mémoire, c’est en effet la première fois qu’un grand média consacre ainsi 3 pleines pages (et sa Une) au logiciel libre.

D’autant que le propos est fort clair et bien construit : explication, historique, évolution et situation actuelle… Avec des témoignages de Tristan Nitot, Jean-Baptiste Kempf (de VLC) et votre serviteur pour Framasoft.

Je l’ai fait lire à ma mère qui m’a dit que c’était peut-être la première fois qu’elle comprenait vraiment ce que je faisais, c’est vous dire…

L’article se termine avec cette citation de Tristan Nitot : « La clé de voûte de notre mouvement, c’est la liberté de l’utilisateur, et cette liberté n’a jamais été autant menacée. On a changé de paradigme: aujourd’hui, il faut que la communauté du logiciel libre s’attaque de front au sujet de la décentralisation du Web.On a libéré les logiciels, et il faut continuer à le faire. Mais il faut aussi libérer les serveurs et les données qui sont dedans. »

C’est tout le sens de notre « libération Google » actuelle à plusieurs étapes.

Merci à Alexandra Bruel et Erwan Cario pour cette mise en lumière grand public d’un sujet qui reste encore trop souvent dans l’ombre malgré tous nos efforts.

PS : Stallman sera content de lire “GNU-Linux” partout !

PS2 : Le logiciel libre partage modestement la Une avec un « Économie : Et si Hollande se trompait ? ». Les deux sujets ne sont peut-être pas si éloignés que ça, et le second ferait peut-être bien de lorgner du côté du premier pour apporter quelques réponses innovantes à la question 😉

Le samedi 17 mai et le dimanche 18 mai à Gérardmer se déroulera un événement inédit dans la région Grand Est : Vosges Opération Libre. Il est ouvert à tous et orienté à la fois vers le grand public et les professionnels.

Cette opération libre est à l’initiative de Framasoft et d’autres d’associations d’envergure nationale ayant une grande expérience dans le Libre, l’ouverture des données, les licences libres et le libre accès.

Il s’agit de la seconde Opération Libre se déroulant sur le territoire français. La première ayant eu lieu à Brocas (Aquitaine) en 2013. Les Opérations Libres visent à rassembler, le temps d’un week-end, des acteurs du Libre en vue d’initier la démarche open data dans les petites villes et villages en présentant les outils disponibles, notamment des logiciels libres. Elles invitent les habitants à participer à l’ouverture et à la diffusion des données de leur territoire. Elles proposent aussi d’engager les citoyens dans un rapport différent avec leur territoire en montrant que le partage des connaissances leur permet d’être collectivement valorisées.

Cette initiative portera aussi sur les usages numériques, leur appropriation, leur potentiel de créativité et leur économie. Cette manifestation vise à promouvoir la culture libre et l’ouverture des données en organisant des actions thématiques formulées en stands, ateliers de formation, conférences, projection permanente de films libres, débats, etc.

Il s’agit d’un événement culturel et participatif où le logiciel libre et ses principes sont conçus comme autant de moyens au service des activités pratiques proposées à destination du grand public. Un travail préalable précédant la manifestation a été mené avec les acteurs de la vie culturelle locale, en particulier la médiathèque de Gérardmer (soirées Wikipédia, ateliers et conférence).

Le programme de la manifestation est disponible à l’adresse vosges.operation-libre.org. Il comprendra :

• 8 ateliers (4 permanents et 4 ponctuels) ;
• 9 conférences ;
• 1 conférence-débat le samedi soir
• 17 stands, des démonstrations ;
• une projection permanente de films libres…

Bientôt la dernière séance de traduction ! Jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction framalang : tcit, Julius22, Sky, lamessen, goofy, peupleLà, merlin8282, lamessen, Jej, Alpha

Le Logiciel Libre dans le secteur public

Till Adam

Issu du milieu de la musique et des sciences humaines, Till Adam a passé pas loin des dix dernières années dans le monde de la programmation. Il travaille au sein de KDAB où il dirige plusieurs services, dont celui qui est en charge des logiciels libres. Till officie aussi au sein du conseil d’administration de Kolab Systems AG, une entreprise dont le modèle économique repose entièrement sur les logiciels libres. Il vit avec sa femme et sa fille à Berlin.

Introduction

J’imagine que comme de nombreux autres auteurs de cette compilation d’articles, j’ai commencé à contribuer au logiciel libre lorsque j’étais étudiant. J’avais décidé relativement tard dans ma vie de poursuivre un cursus en informatique (ayant échoué à devenir riche et célèbre en tant que musicien). Je m’attendais donc à être légèrement plus âgé que mes pairs en obtenant mon diplôme. J’ai donc pensé qu’il serait bénéfique d’apprendre par moi-même la programmation, qui ne m’était pas trop enseignée à l’école, afin de d’avoir plus d’atouts aux yeux de futurs employeurs, en dépit de mon âge. Après quelques incursions dans diverses petites communautés, j’ai finalement trouvé ma voie dans le projet KDE et j’ai commencé à travailler sur l’application de courriel.

Grâce aux personnes extrêmement serviables et douées techniquement que j’y ai rencontrées, j’ai pu apprendre rapidement et contribuer de façon significative au code, ce qui m’a entraîné de plus en plus dans leur réseau social, mais aussi vers le domaine fascinant des problèmes techniques liés à la gestion de données personnelles.

Lorsque KDAB, une entreprise remplie de gens qui utilisaient KDE, m’a demandé si, dans le cadre d’un stage étudiant, je voulais les aider sur la partie commerciale d’un projet en cours, j’ai bien sûr été ravi de pouvoir gagner ma vie et bidouiller le logiciel KDE en même temps. Au fil des ans, j’ai été témoin de l’adoption et de l’utilisation des architectures de gestion des données personnelles de KDE par le secteur public, particulièrement en Allemagne, où j’ai pu y assister personnellement à la croissance économique de KDAB dans ce secteur géographique. Alors que j’évoluais vers des postes plus orientés sur le management, vendre et livrer des services issus du logiciel libre comprenant des produits de KDE à de grandes organisations, en particulier dans le secteur public, a finalement fait partie de mon travail.

Il faut noter que la plupart du travail sur le projet qui a inspiré ce texte était généralement fait en collaboration avec d’autres entreprises du logiciel libre, à savoir glOcode, un spécialiste de la cryptographie qui se charge du maintien de GNUPG, et Intevation, une entreprise de conseil qui se concentre exclusivement sur le logiciel libre ainsi que ses défis stratégiques et opportunités. Mention spéciale à Bernhard Reiter, l’un des fondateurs d’Intevation, qui a joué un rôle clé lors de la vente et de la conduite de bon nombre de ces projets. Les quelques fragments de sagesse contenus dans ce texte sont probablement issus de son analyse et des nombreuses conversations que j’ai pu avoir avec lui au fil des ans.

Donc, si Bernhard et moi pouvions revenir dans le temps, quelles pourraient donc bien être les idées que nous partagerions avec nos « nous »  plus jeunes et plus naïfs ? Eh bien, il s’avère qu’elles commencent toutes par la lettre P.

Personnes

Telles que sont les choses aujourd’hui, il est toujours plus difficile pour les gens de terrain des technologies de l’information et pour les décideurs d’utiliser du logiciel libre que ça ne l’est d’utiliser les alternatives propriétaires. Même en Allemagne, où le logiciel libre a un soutien politique relativement fort, il est plus facile et plus sûr de suggérer l’utilisation de quelque chose qui est perçu comme un « standard de l’industrie » ou comme « ce que tous les autres font » ; en d’autres termes, des solutions propriétaires.

Celui qui propose une solution en logiciel libre fera probablement face à de l’opposition de la part de collègues moins aventureux (ou ayant moins de vision), à un examen minutieux des supérieurs, à de plus grandes attentes par rapport aux résultats et à une pression budgétaire irréaliste. Il faut donc un type particulier de personnes souhaitant prendre des risques personnels, potentiellement compromettre l’avancée de leur carrière et combattre dans une bataille presque perdue d’avance. Ceci est bien sûr vrai dans n’importe quelle organisation. Mais, dans une administration publique, une ténacité particulière est requise car les choses bougent généralement plus lentement. Et une hiérarchie organisationnelle inflexible ajoutée à des options de carrière limitées amplifient le problème.

Sans allié à l’intérieur, faire envisager de façon sérieuse les options du logiciel libre peut s’avérer quasiment impossible. Si de telles personnes existent, il est important de les soutenir autant que possible dans leurs luttes internes. Ceci signifie leur fournir des informations opportunes, fiables et vérifiables sur ce qui se passe dans la communauté avec laquelle l’organisation entend interagir. Ces informations doivent contenir suffisamment de détails pour fournir une image complète tout en atténuant la complexité de la communication et du chaos de planification faisant parfois partie de la façon de travailler dans le monde du logiciel libre, de façon à ce que ça devienne plus gérable et moins effrayant. L’honnêteté et le sérieux aident à construire des relations fortes avec ces personnes-clés, qui sont la base du succès à plus long terme. Elles se reposent sur vous, en tant qu’intermédiaire avec le monde merveilleux et quelque peu effrayant des communautés du logiciel libre, pour trouver des chemins qui les mèneront elles et leurs organisations à leurs objectifs. Elles prennent également des décisions en se basant largement sur la confiance personnelle. Cette confiance doit être acquise et conservée.

Afin d’y parvenir, il est important de ne pas se concentrer uniquement sur les résultats techniques des projets, mais de garder en tête les objectifs plus larges, personnels et organisationnels que l’on doit atteindre lorsqu’on travaille sur ces projets. Le succès ou l’échec du projet en cours ne dépendra peut-être pas du fait qu’un responsable de projet au sein d’une agence soit capable de ne vanter que des fonctionnalités auxiliaires à ses supérieurs à des moments plus ou moins aléatoires du calendrier. Mais cela impactera peut-être le fait que le projet suivant se fasse ou ne se fasse pas. Lorsque vous avez peu d’amis, les aider à réussir est un bon investissement.

Priorités

En tant que technophiles, les gens du logiciel libre ont tendance à se concentrer sur ce qui est nouveau, excitant et qui paraît important au niveau technologique. En conséquence de quoi, nous mettons moins l’accent sur les choses qui sont plus importantes dans le contexte d’une administration publique (souvent vaste). Mais considérez quelqu’un désireux de changer tout un ensemble de technologies dans une structure qui a plutôt tendance à rester sur les mêmes technologies pendant une longue durée. Étant donné qu’un changement brusque est difficile et coûteux, il est de loin bien plus important d’avoir de la documentation sur les choses qui ne fonctionneront pas, de façon à pouvoir les éviter ou les contourner, que de savoir qu’une version à venir fonctionnera beaucoup mieux. Il est peu probable que cette nouvelle version soit jamais disponible pour les utilisateurs dpnt nous parlons ici. Et il est bien plus simple d’avoir affaire à des problèmes connus et anticipés plutôt que d’être forcé de faire face à des surprises. Le bogue documenté d’aujourd’hui est paradoxalement préférable à sa résolution de demain avec ses effets de bord imprévisibles.

Dans une grande organisation qui utilise des logiciels pendant une longue durée, le coût d’acquisition du logiciel, que ce soit par le biais de licences ou dans le cadre de développement sur mesure de logiciels libres par contrat, a peu d’importance en comparaison du coût de maintenance et de support. Cela mène à penser que moins de fonctionnalités, plus stables, ce qui induit une moindre charge pour le  l’organisme de support, auxquelles on peut faire plus confiance et qui ont moins besoin de maintenance intensive sont meilleures que de séduisantes nouveautés, complexes et sans doute moins matures.

Alors que ces deux sentiments vont à l’encontre des instincts des développeurs de logiciels libres, ce sont ces mêmes aspects qui rendent attractif pour le secteur public le fait de payer pour le développement de logiciels libres, plutôt que de dépenser de l’argent pour des licences de produits pris au hasard. En partant d’une large palette de logiciels gratuitement disponibles, l’organisation peut investir son budget dans le perfectionnement des parties précises qui sont pertinentes pour ses propres opérations. Elle n’a ainsi pas à payer (via les coûts de licences) pour le développement de fonctionnalités clinquantes et guidées par le marché dont elle n’a pas besoin. En soumettant tout ce travail à la communauté en retour, la maintenance à long terme de ces améliorations et du logiciel de base est partagée par un grand nombre de personnes. De plus, grâce au fait que ces améliorations deviennent publiques, d’autres organisations aux besoins similaires peuvent bénéficier de celles-ci sans coût supplémentaire. Cela maximise donc l’utilité de l’argent du contribuable, ce que toute administration publique souhaite (ou devrait souhaiter).

Politique d’approvisionnement

Si les budgets informatiques des agences gouvernementales sont clairement mieux utilisés dans l’amélioration du logiciel libre et dans son adaptation à leurs besoins, pourquoi est-ce si rarement ce que l’on fait ? L’équivalence des fonctionnalités pour les types de logiciels les plus utilisés a depuis longtemps été atteinte, la convivialité est la même, la robustesse et le coût total de possession aussi. La notoriété et la connaissance sont bien sûr toujours des problèmes, mais le véritable obstacle à l’acquisition de services en logiciel libre réside dans les conditions légales et administratives sous lesquelles cela doit se produire. Changer ces conditions nécessite du travail, au niveau de la politique et du lobbying. C’est rarement possible dans le contexte d’un projet individuel. Heureusement, des organisations telles que la Free Software Foundation Europe et sa sœur aux États-Unis font du lobbying en notre nom et font lentement changer les choses. Jetons un coup d’œil à deux problèmes centraux d’ordre structurel.

Des licences, pas des services

Beaucoup de budgets informatiques sont structurés de telle façon qu’une partie de l’argent est mise de côté pour l’achat d’un nouveau logiciel ou pour le paiement continu de l’utilisation d’un logiciel sous forme de licences. Comme il était inimaginable pour ceux qui ont construit ces budgets qu’un logiciel puisse être autre chose qu’un bien achetable, représenté par une licence propriétaire, il est souvent difficile ou impossible pour les décideurs informatiques de dépenser cette même somme d’argent pour des services. La comptabilité de gestion n’en entendra simplement pas parler. Cela peut mener à la situation malheureuse où une organisation a la volonté et l’argent pour améliorer un morceau de logiciel libre afin qu’il convienne parfaitement à ses besoins, pour le déployer et pour le faire tourner pendant des années et envoyer ses contributions à la communauté, en retour, mais où cela ne peut se faire tant que toute l’affaire n’est pas enveloppée dans une vente et un achat artificiels et non nécessaires d’un produit imaginaire basé sur une licence libre.

Pièges légaux

Les cadres légaux pour les fournisseurs de logiciels supposent souvent que quiconque signant la production d’un logiciel exerce le plein contrôle des copyrights, marques déposées et brevets afférents. L’organisation cliente attend une garantie contre des risques variés de la part du fournisseur. Dans le cas où une société ou une personne produit une solution ou un service basé sur du logiciel libre, cela est souvent impossible car il y a d’autres titulaires de droits qui ne peuvent pas être raisonnablement impliqués dans l’arrangement contractuel. Ce problème apparaît plus ostensiblement dans le contexte des brevets logiciels. Il est pratiquement impossible pour un fournisseur de services de s’assurer contre les risques de contentieux de brevets, ce qui rend très risqué pour lui d’endosser la pleine responsabilité.

Prix

Historiquement, l’argument le plus vendeur du logiciel libre donné au grand public a été son potentiel pour d’économie d’argent. Le logiciel libre a en effet permis des économies à grande échelle pour beaucoup d’organisations depuis de nombreuses années. Le système d’exploitation GNU/Linux a été le fer de lance de ce développement. Ceci en raison de sa libre disponibilité au téléchargement qui a été perçue en opposition frappante avec les licences onéreuses de son principal concurrent, Microsoft Windows.

Pour quelque chose d’aussi utilisé et utile qu’un système d’exploitation, il est indéniable que le bénéfice des coûts structurels vient des coûts de développement qui sont répartis sur de nombreuses parties. Malheureusement, l’espoir que ceci reste vrai pour tous les logiciels libres a mené à la pensée irréaliste que les coûts seront toujours réduits, largement et immédiatement. D’après notre expérience, ce n’est pas vrai. Comme nous l’avons vu dans les sections précédentes de cet ouvrage, il est très logique de tirer le meilleur parti de l’argent dépensé dans l’utilisation de logiciels libres et il est probable qu’au fil du temps et pour de nombreuses organisations de l’argent puisse être économisé. Mais pour une agence isolée qui cherche seulement à déployer un logiciel libre, il devra y avoir un investissement initial et un coût nécessaire associé pour obtenir le niveau de maturité et de robustesse nécessaire.

Alors que cela semble largement raisonnable aux professionnels des opérations informatiques, il est souvent plus difficile de convaincre de cette vérité leurs supérieurs avec le bilan financier. Surtout lorsque la potentielle économie de moyens financiers a initialement été utilisée comme un argument pour faire entrer le logiciel libre, il peut s’avérer très difficile de gérer efficacement les attentes futures. Plus vite les décideurs sauront exactement de façon claire combien et dans quoi ils investissent, mieux ils accepteront de le faire sur le long terme

Le meilleur rapport qualité-prix est toujours attirant et un fournisseur de services informatiques qui cessera d’être disponible à cause de la pression des prix et n’obtiendra pas suffisamment de réussite économique est aussi peu attractif dans le logiciel libre que dans les modèles économiques basés sur des licences propriétaires. Il est donc aussi dans l’intérêt des clients que les estimations de coûts soient réalistes et que les conditions économiques dans lesquelles le travail est effectué soient durables.

Conclusion

Notre expérience montre qu’il est possible de convaincre des organismes du secteur public de dépenser de l’argent dans des services basés sur des logiciels libres. C’est une proposition intéressante qui offre une plus-value et qui a un sens politique. Malheureusement, il existe encore des barrières structurelles. Mais avec l’aide de pionniers dans le secteur public, elles peuvent être contournées. Avec un soutien suffisant de notre part à tous, ceux qui travaillent pour le logiciel libre au niveau politique finiront par les surmonter. Une communication claire et honnête sur les réalités économiques et techniques peut favoriser des partenariats efficaces qui amènent des bénéfices à la communauté du logiciel libre, aux administrations publiques utilisant ces logiciels et à ceux qui les fournissent avec les services nécessaires dans un cadre viable et durable.

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

Traduction Framalang : satanas_g, Sphinx, Sky, Julius22, peupleLà, lamessen, goofy

Du débutant au professionnel

Jonathan Riddell

Jonathan Riddell est développeur KDE et Kubuntu, actuellement employé par Canonical. Quand il n’est pas devant un ordinateur, il fait du canoë sur les rivières d’Écosse.

Il y avait un bogue dans le code. Un bien méchant en plus : un plantage sans enregistrement des données. C’est bien là le problème dès qu’on regarde le code, on trouve des trucs à réparer. C’est facile de s’impliquer dans le logiciel libre ; le plus dur est d’en sortir. Après le premier bogue réparé, il y en a d’autres, et de plus en plus, tous à portée de main. Les corrections de bogues mènent à l’ajout de fonctionnalités, ce qui mène à la maintenance de projet, ce qui mène à faire fonctionner une communauté.

Tout a commencé en lisant Slashdot, cette masse d’actualité geek et technique peu filtrée avec des commentaires de quiconque peut recharger assez vite pour être en haut de liste. Chaque actualité était intéressante et excitante, apportait un éclairage nouveau sur le monde de la technologie qui finissait par me fasciner. Je n’avais plus à accepter ce qui m’était donné par de grandes entreprises de logiciels, je pouvais voir là, dans la communauté du logiciel libre, le code se développer devant moi.

En tant qu’étudiant, il était possible de finir les exercices donnés par les professeurs très rapidement. Mais les exercices ne sont pas des programmes terminés. Je voulais savoir comment appliquer les compétences basiques qu’ils m’avaient données dans le monde réel en écrivant des programmes résolvant des problèmes réels pour les gens. J’ai donc recherché du code, qui n’était pas difficile à trouver, il se trouvait là, sur Internet, en fait. En regardant le code des programmes que j’utilisais de plus près, j’y ai décelé de la beauté. Non pas parce que le code était parfaitement soigné ou bien structuré, mais parce que je pouvais le comprendre avec les concepts que j’avais déjà appris. Ces classes, méthodes et variables étaient bien en place, me permettant de résoudre les problèmes pertinents. Le logiciel libre est le meilleur moyen de franchir le pas entre savoir comment finir ses exercices de cours et comprendre comment de vrais programmes sont écrits.

Tous les étudiants en informatique devraient travailler sur du logiciel libre comme sujet de leur mémoire. Sinon, vous avez de grandes chances d’y passer six mois à un an pour qu’il finisse au sous-sol d’une bibliothèque sans être jamais plus consulté. Seul le logiciel libre permet d’exceller en faisant ce qui va de soi : vouloir apprendre comment résoudre des problèmes intéressants. À la fin de mon projet, des programmeurs de la NASA utilisaient mon outil de création de diagrammes en UML (NdT : langage de modélisation unifié) et il reçut des prix au cours de réceptions somptueuses. Avec le logiciel libre, on peut résoudre de vrais problèmes pour de vrais utilisateurs.

La communauté des développeurs est remplie de personnes formidables, passionnées et dévouées à leur travail, sans espoir autre de récompense qu’un programme d’ordinateur couronné de succès. La communauté des utilisateurs est également incroyable. Il est satisfaisant de savoir qu’on a aidé quelqu’un à résoudre un problème. Et j’apprécie les messages de remerciement que je reçois.

Après avoir écrit un logiciel utile, il faut le mettre à la disposition du plus grand nombre. Le code source ne va pas fonctionner pour la plupart des gens, il doit être compilé. Avant d’être impliqué, je trouvais que le fait de compiler était une manière un peu paresseuse de contribuer au logiciel libre. Vous vous attirez la plus grande partie de la reconnaissance sans rien avoir à coder. C’est, quelque part, quelque chose d’injuste. De même, la gestion de la communauté nécessaire pour porter un projet de logiciel libre peut aussi être vue comme une façon de s’attirer la reconnaissance sans faire de code.

Les utilisateurs dépendent beaucoup des packagers (NdT : les « empaqueteurs » qui préparent et maintiennent les paquets logiciels). Il est nécessaire que leur travail soit à la fois rapide, pour satisfaire ceux qui veulent la dernière version, et fiable, pour ceux qui veulent la stabilité (autant dire tout le monde). La partie la plus délicate, c’est que cela implique de travailler avec les logiciels des autres, qui sont toujours « cassés ». Une fois que le logiciel est lâché dans la nature, commencent à emerger des problèmes qui n’étaient pas repérables sur l’ordinateur de l’auteur. Il est possible que le code ne puisse pas être compilé avec une version de compilateur différente, peut-être que la licence n’est pas claire et ne permet pas de le copier, peut-être que la gestion des versions est incohérente et qu’une mise à jour mineure est incompatible, ou encore que la taille de l’écran est différente, les environnements de bureau peuvent aussi l’affecter, quelquefois, des bibliothèques tierces nécessaires ne sont pas encore à jour. De nos jours, le logiciel doit pouvoir tourner sur différentes architectures. Les processeurs 64 bits ont occasionné pas mal de problèmes quand ils sont devenus courants. Aujourd’hui, ce sont les processeurs ARM qui déjouent les calculs des codeurs. Les packagers doivent régler tous ces problèmes pour donner aux utilisateurs quelque chose qui fonctionne de façon fiable.

Nous avons une règle chez Ubuntu selon laquelle les paquets avec des tests unitaires doivent inclure ces mêmes tests dans le processus de la création des paquets. Souvent, ils échouent et l’auteur du logiciel nous dit que les tests sont uniquement à son usage. Malheureusement, quand il s’agit de logiciel, il n’est jamais assez fiable de le tester soi-même, il doit aussi être testé par d’autres. Un test unique est rarement suffisant, il faut une approche à plusieurs niveaux. Les tests unitaires du programme original devraient être le point de départ, ensuite, le packager les teste sur son propre ordinateur, il faut ensuite que d’autres personnes les testent aussi. L’installation automatique et les tests de mise à jour peuvent être scriptés assez correctement sur les services d’informatique dans le nuage. L’envoyer dans la branche de développement d’une distribution permet d’effectuer plus de tests avant de le voir distribué en masse quelques mois après. À chaque étape, des problèmes peuvent être et seront découverts, ils devront être corrigés, puis ces correctifs eux-mêmes devront être testés. Il n’y a donc pas forcément à écrire beaucoup de code, mais il y a pas mal de travail pour passer le logiciel de 95 % à 100 % prêt. Ces 5 % sont la partie la plus difficile, un lent et délicat processus qui demande une grande attention pendant tout son cours.

Vous ne pouvez pas faire de paquets sans une bonne communication avec les développeurs en amont. Quand des bogues se produisent, il est vital de pouvoir trouver la bonne personne à laquelle parler rapidement. Il est important d’apprendre à bien les connaître comme des amis et des collègues. Les conférences sont vitales pour cela, car rencontrer quelqu’un apporte beaucoup plus de contexte à un message sur une liste de diffusion qu’une année entière de messages.

Une des faces cachées du monde du logiciel libre réside dans la communication par les canaux IRC privés utilisés par les principaux membres d’un projet. Tous les grands projets en ont. Quelque part, Linus Torvalds a un moyen de discuter avec Andrew Morton et les autres sur ce qui est bon et sur ce qui est mauvais dans Linux. Ils sont plus sociaux que techniques et, quand on en abuse, ils peuvent être très antisociaux pour la communauté en général. Mais pour les moments où on a besoin d’un canal de communication rapide sans bruit parasite, ils fonctionnent bien.

Tenir un blog est un autre moyen de communication important dans la communauté du logiciel libre. C’est notre principale méthode pour promouvoir à la fois le logiciel que nous produisons et nous-mêmes. Non pas que ce soit utilisé éhontément pour de l’auto-promotion (il est inutile de prétendre que vous sauverez des vies avec votre blog…), mais parler de votre travail sur le logiciel libre aide à construire une communauté. Cela peut même vous valoir de trouver un travail ou d’être reconnu dans la rue.

Ces histoires venant de Slashdot, à propos de développements de nouvelles technologies, ne concernent pas des personnalités éloignées que vous ne rencontrerez jamais comme dans la presse people. Elles concernent des personnes qui ont trouvé un problème et qui l’ont résolu en utilisant l’ordinateur qu’elles avaient en face d’elles. Pendant quelques années, j’ai édité le site d’informations de KDE, trouvant les personnes qui résolvaient des problèmes, créaient des idées novatrices, s’acharnaient longuement à améliorer un logiciel jusqu’à ce qu’il soit d’une qualité suffisante, et j’en parlais au monde entier. Je n’ai jamais été à court d’histoires à raconter ni de personnes à présenter à tout le monde.

Mon dernier conseil est de conserver de la diversité. Il existe une telle richesse de projets intéressants à explorer, qui vous permettent d’apprendre et de progresser. Mais une fois que vous avez atteint une position de responsabilité, il peut être tentant d’y rester. Après avoir aidé à créer une communauté pour Kubuntu, je repars temporairement vers un travail sur Bazaar, un projet très différent, orienté sur les développeurs plutôt que sur des utilisateurs novices en technologies. Je peux à nouveau apprendre comment le code devient une réalité utile, comment une communauté communique, comment la qualité est maintenue. Ce sera un défi amusant et j’ai hâte de m’y attaquer.

Sources :

• Le gouvernement compte revoir le cadre de la liberté d’expression (Numerama)
• Vu du Sénat # 23: La liberté sur internet, c’est quoi au juste ? (Le Huffington Post)

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

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

Traduction Framalang : lamessen, lerouge, Kalupa, Sky, Astalaseven, Alpha, LuD-up, CoudCoud, peupleLa, goofy

La documentation et moi, avant et après

Anne Gentle

Anne Gentle est une rédactrice technique acharnée et la coordinatrice de la documentation communautaire à Rackspace pour OpenStack, un projet open source d’informatique dans le nuage. Avant de rejoindre OpenStack, Anne travaillait en tant que consultante de publication communautaire, en donnant une direction stratégique aux rédacteurs professionnels qui veulent produire du contenu en ligne sur des wikis contenant des pages et des commentaires générés par les utilisateurs. Sa passion pour les méthodes communautaires de documentation l’a amenée à écrire un livre sur les techniques de publication collaborative pour la documentation technique intitulé Conversation et communauté : la documentation dans le web social. Elle s’occupe aussi bénévolement de la maintenance de la documentation pour les manuels FLOSS qui proposent de la documentation open source pour les projets open source.

Voilà une prémisse bien étrange : vider mes tripes sur ce que j’aurais voulu savoir de l’open source et de la documentation. Plutôt que de vous dire ce que je veux que vous sachiez sur l’open source et la documentation, je dois vous dire ce que j’aurais aimé que mon moi antérieur sache. Cette demande suscite un sentiment de nostalgie ou de remords voire cette horrible énigme : « à quoi pouvais-je bien penser ? ».

En ce qui me concerne, avec juste cinq ans de moins, mon moi antérieur était une trentenaire bien installée dans sa vie professionnelle. D’autres, au contraire, se souviennent qu’ils n’étaient qu’adolescents lors de leurs premières expériences open source. Jono Bacon dans son livre L’art de la Communauté, raconte comment il s’est tenu devant la porte d’un appartement, le cœur battant, alors qu’il était sur le point de rencontrer quelqu’un à qui il n’avait jamais parlé que sur le réseau, par le biais d’une communauté open source. J’ai moi aussi fait cette expérience de la première rencontre physique de gens que j’avais découverts en ligne, mais ma première incursion dans le monde de la documentation open source s’est produite lorsque j’ai répondu à une demande d’aide par courriel.

Le courriel provenait d’un ancien collègue qui me demandait de l’aide pour la documentation de l’ordinateur portable XO, le projet fondateur de l’organisation One Laptop Per Child (un portable pour chaque enfant). J’ai réfléchi à ce que je pensais être une proposition intéressante, j’en ai parlé à mes amis et à mon époux en me demandant si ce n’était pas une bonne occasion d’expérimenter de nouvelles techniques de documentation et d’essayer une chose que je n’avais jamais faite auparavant : une documentation basée sur un wiki. Depuis cette première expérience, j’ai rejoint OpenStack, un projet open source sur une solution d’informatique dans le nuage, et je travaille à plein temps sur la documentation et le support communautaires.

Je pense immédiatement aux nombreuses contradictions que j’ai rencontrées tout au long de la route. J’ai découvert que pour chaque observation il existe des champs et contre-champs surprenants. Par exemple, la documentation est absolument indispensable pour l’aide aux utilisateurs, l’éducation, la possibilité de choisir ou bien la documentation promotionnelle qui amène à adopter un logiciel. Pourtant, une communauté open source pourra continuer d’avancer malgré le manque de documentation ou de la doc complètement défectueuse. Voici une autre collision apparente de valeurs : la documentation pourrait être une très bonne tâche pour démarrer, un point de départ pour les nouveaux volontaires, pourtant les nouveaux membres de la communauté savent si peu de choses qu’il ne leur est pas possible d’écrire ni même d’éditer de manière efficace. En outre les petits nouveaux ne sont pas bien familiers des différents publics auxquels doit servir la documentation.

Ces derniers temps on entend dire un peu partout : « les développeurs devraient écrire la doc de développement » parce qu’ils connaissent bien ce public et par conséquent cela lui serait aussi utile qu’à eux-mêmes. D’après mon expérience, un regard frais et neuf est toujours le bienvenu sur un projet et certaines personnes ont la capacité d’écrire et de partager avec d’autres ce regard frais et empathique. Mais vous n’allez sûrement pas vous mettre à créer une culture « réservée aux novices » autour de la doc parce qu’il est important que des membres essentiels de la communauté technique apportent leur contribution aux efforts de documentation, et qu’ils encouragent aussi les autres à y participer.

Une partie du vilain petit secret sur la documentation des projets open source est qu’il n’existe qu’une frontière pour le moins floue entre leur documentation officielle et leur documentation officieuse. Si seulement j’avais su que les efforts de documentation devraient être sans cesse renouvelés et que de nouveaux sites web pourraient apparaître là où il n’y en avait pas… Une documentation extensive n’est pas le moyen le plus efficace pour s’initier à des projets ou des logiciels mais un parcours sinueux dans les méandres de la documentation sur le Web peut s’avérer plus instructif pour ceux qui veulent lire entre les lignes et avoir ainsi une idée de ce qui se passe dans la communauté grâce à la documentation. Avoir beaucoup de forks(1) et des publics variés peut indiquer que le produit est complexe et qu’il est très suivi. Cela peut aussi signifier que la communauté n’a mis en place aucune pratique quant à la documentation de référence ou que les efforts désorganisés sont la norme.

À mes débuts, j’aurais aimé avoir la capacité de ressentir la « température conviviale » d’une communauté en ligne. Quand vous entrez dans un restaurant rempli de tables nappées de blanc, de couples qui dînent et de conversations feutrées, l’information visuelle et auditive que vous recevez détermine l’ambiance et vous donne quelques indices sur ce que vous vous apprêtez à vivre lors de votre repas. Vous pouvez tout à fait transposer ce concept de température conviviale à une communauté en ligne.

Une communauté open source vous donne quelques indices dans ses listes de discussion, par exemple. Une page de présentation de la liste qui commence par de nombreuses règles et conventions sur la manière de poster indique une gouvernance très stricte. Une liste de discussion qui contient de nombreuses publications mettant l’accent sur le fait qu’il « n’y a pas de question bête » est plus accueillante pour de nouveaux rédacteurs de documentation.

J’aurais aussi aimé connaître un moyen de faire non seulement de l’audit de contenu, c’est-à-dire lister le contenu à disposition pour le projet open source, mais aussi de l’audit de communauté, donc lister les membres influents de la communauté open source, qu’il s’agisse ou non de contributeurs.

Pour terminer, une observation à propos de l’open source et de la documentation que j’ai pu vérifier avec plaisir, c’est l’idée que la rédaction de la documentation peut s’effectuer via des « sprints » — grâce à des de brusques dépenses d’énergie avec un public ciblé et un but précis, pour aboutir à un ensemble documentaire de référence.

J’ai été très contente d’entendre lors d’une conférence à SXSW Interactive que les sprints sont tout à fait acceptables pour la collaboration en ligne, qu’il faut s’attendre à des fluctuations du niveau d’énergie de chacun et que c’est OK. La documentation des logiciels est souvent faite à l’arrache dans les moments d’accalmie d’un cycle de release(2) et ça ne pose aucun problème dans la documentation open source qui est basée sur la communauté. Vous pouvez adopter une approche stratégique et coordonnée et continuer tout de même de proposer des évènements de grande intensité autour de la documentation. Ce sont des moments exaltants dans l’open source et mon ancien moi les a pleinement ressentis. C’est une bonne chose que vous continuiez à passer de votre moi antérieur à votre moi actuel avec un paquet de conseils en poche.

(1) Un fork est un nouveau logiciel créé à partir du code source d’un logiciel existant.

(2) La release est la publication d’un logiciel.