Comme le souligne avec malice notre ami Gee, la suite bureautique libre LibreOffice 3.3 vient de voir le jour.

Sauf que, comme son numéro ne l’indique pas, c’est sa toute première version stable. Mais alors pourquoi n’a-t-on pas logiquement une version 1.0 ? Parce qu’il s’agit d’un fork de la célèbre suite OpenOffice.org qui, au moment de la séparation, en était restée à la version 3.2.

Petit rappel Wikipédia : « Un fork, ou embranchement, est un nouveau logiciel créé à partir du code source d’un logiciel existant. Cela suppose que les droits accordés par les auteurs le permettent : ils doivent autoriser l’utilisation, la modification et la redistribution du code source. C’est pour cette raison que les forks se produisent facilement dans le domaine des logiciels libres. Les forks sont perçus par certains comme une épée de Damoclès au-dessus des auteurs des projets les moins bons, et aussi comme une méthode pour empêcher l’appropriation d’un projet par un groupe. La « peur de l’embranchement » est un des mécanismes essentiels de régulation et de sélection des projets libres. »^[1]

Vous êtes un développeur d’un logiciel libre non satisfait de la manière dont évolue le projet ? Vous avez donc cette possibilité essentielle que constitue le fork. Mais il y parfois un gouffre entre la théorie et la pratique, car il n’est pas simple de reconstituer une communauté active autour du projet dérivé.

C’est pourtant justement ce que vient de réussir l’équipe de LibreOffice, structurée autour de la Document Foundation et qui a décidé de quitter le navire OpenOffice.org suite au rachat de Sun par Oracle. Ce dernier ayant refusé de rejoindre le projet et de céder la marque OpenOffice.org (qu’il continuera de développer par ailleurs), c’est donc désormais LibreOffice (ou LibO) qui sera l’un des fers de lance du logiciel libre grand public aux côtés de Firefox ou GNU/Linux.

LibreOffice 3.3 : les véritables enjeux

The Deeper Significance of LibreOffice 3.3

Glyn Moody – 28 janvier 2011 – ComputerWolrd.uk
(Traduction Framalang : Yonel et Don Rico)

Sur le blog RedMonk, James Governor a publié un billet amusant à propos des forks, suite à l’arrivée imminente d’une mise à jour majeure d’Android, la 3.0, dont le nom de code est « Honeycomb », et laquelle a été conçue en pensant aux tablettes :

Ainsi que le voudrait la sagesse populaire, les développeurs ne devraient pas s’attaquer à des environnements multiples. Ben voyons… le genre de sagesse qui nous a valu une décennie où il n’y en a eu que pour Java, et une vingtaine d’années pendant lesquelles dès qu’il y fallait choisir une architecture on collait du Oracle partout. Avouons que pour l’instant, Android est vraiment pas mal sur les téléphones. J’aime beaucoup mon HTC Desire. J’ai aussi la chance de pouvoir faire joujou avec un Dell Streak qu’on m’a prêté ; encore un bon petit appareil, qui fait bien son boulot pour m’accompagner devant la télé. Mais Android n’a pas été conçu pour un format plus grand, comme l’iPad 10 pouces d’Apple, du moins dans ses premières versions.

Et comme il le fait remarquer :

Tous les éditeurs de logiciels doivent gérer des codebases multiples, en particulier pour les progiciels. Si une entreprise doit gérer les deux codebases, est-ce vraiment un fork ?

Je dirais qu’il s’agit plus de fragmentation, et qu’on en voit partout – dans Android lui-même, dans Windows, admettons, et dans le monde de GNU/Linux à travers les centaines de distributions, chacune avec des versions et des configurations différentes. Rien de bien nouveau.

Les vrais forks ne courent pas les rues, précisément à cause des différences entre le fork et la fragmentation. Cette dernière peut être gênante ou pas, mais elle est rarement aussi douloureuse qu’un fork peut l’être. En général, les forks déchirent les communautés et forcent les programmeurs à choisir leur camp.

C’est ce qui rend l’apparition de LibreOffice si intéressante : c’est un vrai fork, avec des décisions réelles et douloureuses que doivent prendre les codeurs – où vont-ils ? Et à la différence de la fragmentation, qui souvent se produit naturellement et perdure pour un tas de raisons en grande partie banales, les forks exigent beaucoup de travail pour survivre. Résultat, de nombreux forks échouent, car il est souvent plus facile de rester ou de revenir au projet d’origine, plutôt que de se battre pour en installer et en faire grandir un nouveau.

Dans ce contexte, la publication récente de LibreOffice 3.3 est un jalon important, au moins pour ce qu’elle a déjà réussi :

La Document Foundation présente LibreOffice 3.3, la première version stable de la suite bureautique libre développée par la communauté. En moins de quatre mois, le nombre de développeurs codant LibreOffice est passé de moins de vingt à la fin septembre 2010, à largement plus d’une centaine aujourd’hui. Cela nous a permis de publier en avance par rapport au calendrier audacieux fixé par le projet.

À l’évidence, attirer les développeurs est une épreuve cruciale pour le potentiel de survie du fork, et même de son épanouissement. D’autres points importants :

La communauté des développeurs a pu bâtir ses propres méthodes en toute indépendance, et devenir opérationnelle en très peu de temps (eu égard à la taille du codebase et aux grandes ambitions du projet).

Grâce au grand nombre de nouveaux contributeurs qui ont été attirés par ce projet, le code source est vite soumis à un nettoyage d’ampleur, pour offrir une meilleure base aux développements de LibreOffice à venir.

C’est-à-dire que LibreOffice n’en est plus au stade de vague projet, ou à celui des étapes pénibles comme définir l’infrastructure qui permettra au projet d’avancer. La signification de cette réussite va au-delà du fait que la Fondation propose aux utilisateurs une alternative libre à OpenOffice (qui vient également de sortir sa dernière version). La possibilité de choix étant au coeur du logiciel libre, c’est donc certainement une bonne nouvelle, surtout à cause de la politique de copyright de LibreOffice, que j’ai déjà évoquée.

Mais je pense que LibreOffice a une importance supplémentaire parce qu’il représente une attaque délibérée contre la façon dont Oracle traite son catalogue open-source. Hélas, le mécontentement qui a poussé à cette scission va bien plus loin que le seul domaine des suites bureautiques.

L’attitude d’Oracle envers la communauté open-source semble empirer, c’est de plus en plus évident. Marc Fleury le résume bien dans ce billet révélateur. Fondateur de Jboss, et l’un des vrais innovateurs en termes de modèles économiques reposant sur l’open-source, il sait certainement de quoi il parle quand il s’agit de diriger des codeurs open-source dans un contexte professionnel, ce qui rend des commentaires comme celui-ci particulièrement significatifs – et inquiétants pour Oracle :

Il y a d’abord eu le fiasco OpenOffice/Libre Office, où OpenOffice a été forké dans la plus grande partie par sa propre communauté. Puis il y a eu le caprice d’Apache concernant Java/JCP, quand le groupe a bruyamment quitté le JCP (NdT : Java Community Process) après des prises de bec sur les licences open-source de la JVM (Harmony). Et en ce moment, il y a d’autres bisbilles, dont une au sujet de NetBeans. Mais celle qui me concerne le plus (ainsi que mon porte-monnaie), cela concerne un projet mené par un employé de Cloudbees.

Si je comprends bien la situation, le principal développeur était employé par Sun quand il a initié Hudson. Oracle revendique donc l’identité et la marque, ce qui en toute franchise est aberrant, puisque la licence est open-source et que les gars de Cloudbees peuvent poursuivre leur travail sans entrave. Reste donc une dernière étape : la création d’un fork du projet. Et voilà… une grande partie de la communauté open-source dit merde à Oracle.

Ce que LibreOffice montre (jusqu’ici, en tout cas) c’est que dans ces circonstances, il y a bien une vie après Oracle, que les gens se regrouperont dans un fork au lieu de l’éviter, et que le travail alors fourni amène des améliorations non négligeables. Il est vrai que cet argument ne s’appuie que sur un seul exemple, et il faudrait être un expert bien téméraire pour essayer d’en extrapoler quoi que ce soit. Mais cela reste une source d’inspiration importante et tentante pour les codeurs contrariés qui grognent sous le joug d’Oracle. Après tout, comme le met en évidence le nom de LibreOffice, il ne s’agit pas que de code. Il s’agit aussi de liberté.

Framasoft est fier et heureux d’annoncer officiellement la sortie d’un nouveau volume à sa collection de livres libres Framabook. Il s’agit de la traduction d’un livre considéré comme une référence chez les développeurs anglophones : Producing Open Source Software, de Karl Fogel.

C’est une évidence, maintes fois constatées : il ne suffit pas de coller une licence libre au code source de son application pour en faire un logiciel libre à succès. Nombreux sont les paramètres à prendre en compte pour se donner les moyens de véritablement réussir votre projet. Cela ne coule pas de source, si j’ose dire, et c’est pourquoi un tel ouvrage peut rendre de grands services.

Ayant payé de sa personne, Karl Fogel n’hésite pas à affirmer lui-même que 95% des projets échouent. Et de rédiger alors ce livre pour contribuer à faire en sortie que le pourcentage restant remonte !

Dans la foulée du framabook sur Unix et sur le langage C, nous faisons un effort didactique tout particulier pour accompagner tous ceux qui souhaiteraient se lancer dans la création de logiciels libres ou rejoindre un projet existant. Nous pensons à ceux qui ne maîtrisent pas forcément d’emblée l’anglais.

Nous pensons également aux jeunes débutants. Parce que, comme cela a déjà été souligné, l’informatique est l’une des grandes absentes de l’enseignement secondaire français. Alors, fille ou garçon, l’étudiant motivé se retrouve bien souvent livré à lui-même et c’est à lui de se débrouiller pour extraire le bon grain de l’ivraie du Grand Internet. Nous espérons lui être utile en lui apportant notamment ici gain de temps et efficacité.

Voici comment le livre est présenté dans le communiqué de presse joint à ce billet :

« Teinté d’humour et de réflexions subtiles, ce livre prodigue de précieux conseils à ceux qui souhaitent commencer ou poursuivre un projet de développement en logiciel libre. Pour cela, Karl Fogel propose une description claire et détaillée des bonnes pratiques de développement. Il initie non seulement le lecteur à la méthode de travail collaboratif mais démontre aussi l’importance des relations humaines dans la réussite d’un projet, comme l’art d’équilibrer actions individuelles et intérêt commun. Identifiés à travers sa longue expérience en gestion de projet open source, différents aspects sont abordés : structurer l’ensemble de la communauté de développeurs, maintenir un système de gestion de versions, gérer les rapports de bugs et leurs corrections, bien communiquer à l’intérieur comme à l’extérieur du projet, choisir une licence adaptée au logiciel… »

Grâce à son expérience du développement open source, Karl Fogel nous livre ici bien davantage qu’une simple marche à suivre pour qu’un projet voit le jour et ait une chance d’aboutir. Il s’agit en effet de détailler les éléments stratégiques les plus importants comme la bonne pratique du courrier électronique et le choix du gestionnaire de versions, mais aussi la manière de rendre cohérents et harmonieux les rapports humains tout en ménageant les susceptibilités… En somme, dans le développement Open Source peut-être plus qu’ailleurs, et parce qu’il s’agit de trouver un bon équilibre entre coopération et collaboration, les qualités humaines sont aussi décisives que les compétences techniques. »

La traduction de cet ouvrage a obéi aux mêmes principes que ceux exposés par Karl Fogel. Elle fut le résultat de la convergence entre les travaux initiés par Bertrand Florat et Étienne Savard et ceux de Framasoft coordonnés par Christophe Masutti. Comme d’habitude, ce livre a été finalisé dans La Poule ou l’Œuf et peut se commander en version papier chez InLibroVeritas pour la modique somme de 15 euros.

Comme d’habitude aussi ce livre est sous licence libre (Creative Commons By) et est intégralement consultable en ligne ou téléchargeable dans sa version numérique sur le site Framabook. Parce qu’ici comme ailleurs, et peut-être même plus qu’ailleurs, il nous apparaît fondamental de pouvoir en assurer sa plus large diffusion et participer ainsi à susciter des vocations.

Nous comptons sur vous pour signaler l’information 😉

Framasoft ne serait rien sans les développeurs de logiciels libres. Ce projet est en quelque sorte une manière pour nous de les remercier.

Gee revient cette semaine sur l’affaire des portes dérobées découvertes dans le code d’OpenBSD, un systèmes d’exploitation libre réputé pour l’importance accordée, dans son développement, à la sécurité et à la cryptographie.

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

Le noyau Linux possède plusieurs millions de lignes de code mais parfois il en suffit d’une poignée pour sensiblement améliorer les choses (cf cette news de LinuxFr).

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

« Une semaine tous frais payés dans la petite Venise du nord… » c’est le cadeau qu’ont gagné les quatre projets retenus par l’EPPLUG ^[1] pour la deuxième édition des H@ckWeeks qui se déroulera la semaine prochaine à Amiens.

Les membres de ces quatre projets se retrouveront donc dans le nord dès lundi prochain, confiés aux mains expertes des bénévoles de l’EPPLUG, qui, à la suite de l’organisation de l’édition 2007 des RMLL dans la préfecture de Picardie ont imaginé une variante hebdomadaire des barcamps, ces réunion de travail et d’ateliers.

Le principe est simple : se retrouver tous en vrai (souvent pour la 1ère fois) et n’avoir rien d’autre à penser pendant une semaine que l’avancement du projet libre en question.

L’évènement en étant seulement à sa 2e édition, il suffit aux heureux gagnants de déposer dans les temps une candidature auprès de l’EPPLUG, détaillant le nombre de participants et les objectifs fixés pour cette semaine de travail intensif.

Les quatre projets de cette 2e édition sont :

• Domogik
• Seeks
• Nobjet
• Dolibarr

Et nous aurons l’occasion de revenir en détail sur chacun d’eux plus tard. Toutefois, les lecteurs consciencieux auront d’ores et déjà remarqué que « Nobjet », présenté aux RMLL 2010, est davantage un projet artistique qu’un projet logiciel. Et c’est bien là le deuxième aspect des H@ckWeeks d’Amiens. En effet, la manifestation ne se limite pas à enfermer des codeurs ensembles avec des machines, mais s’accompagne de tout un programme embrassant la culture du libre ^[2] dans tous ses états. Projections de films libres ^[3], conférences sur l’art ou la cuisine libre, concerts de musique libre et ateliers permettant au public d’aller à la rencontre des développeurs de chaque projet rythmeront cette semaine intense.

Enfin, cerise sur le gâteau, vous allez pouvoir vivre ces H@ckWeeks hiver 2010 au quotidien, grâce au Framablog ! Ce ne sera pas exactement comme si vous y étiez certes, mais ça sera par contre vraiment comme si j’y étais 🙂

Dans la série « projets Framasoft », je voudrais le FramaDVD. Et plus exactement le « FramaDVD École ».

Rappel : le FramaDVD est une compilation des meilleurs logiciels libres pour Windows, sélectionnés par Framasoft, auxquels nous avions ajouté le liveCD Ubuntu, ainsi que de très nombreuses ressources libres (textes, vidéos, musiques, photos, etc) afin de montrer que la culture libre allait aujourd’hui bien plus loin que le logiciel libre. Co-réalisé avec une équipe d’étudiants aussi dynamiques que sympathiques, ce DVD 100% libre a été largement diffusé depuis sa sortie (en septembre 2009). Une mise à jour est d’ailleurs prévue pour les prochaines semaines.

Mais l’un des avantages du 100% libre, c’est entre autre la possibilité de décliner un projet libre existant pour l’adapter à différents besoins.

Et c’est ce qui s’est passé avec le FramaDVD École. Cyrille Largillier, directeur et professeur des écoles, membre déjà très actif du projet Framakey, s’est proposé de créer un DVD destiné à favoriser l’usage des TUIC à l’école primaire. Et, pour joindre l’utile à l’agréable, favoriser l’usage des logiciels et de la culture libre dans ces mêmes écoles.

—> La vidéo au format webm

En plus d’un projet libre, il s’agit bien là d’un projet collaboratif. Il a en effet été conçu avec l’aide d’autres communautés. Notamment :

• ASRI Education : pour l’intégration de sa distribution GNU/Linux particulièrement légère, adaptée aux enfants et aux adultes ;
• EducOO : pour l’intégration d’OOo4kids, une suite bureautique dérivée d’OpenOffice, elle aussi adaptée aux enfants, dont nous vous avions déjà parlé ici ;
• Okawix (ou plus exactement la société Linterweb, qui a développé le logiciel libre Okawix) : grâce à Okawix, le FramaDVD École intègre l’excellente encyclopédie pour enfants Vikidia, en version hors ligne, pour les écoles ou les foyers où Internet n’est pas ou peu disponible.

Après plusieurs mois de travaux, nous sommes donc fiers de vous annoncer la naissance du FramaDVD École !

Conçu spécifiquement pour les élèves et les enseignants des écoles, le FramaDVD École, doté de nombreuses fonctionnalités, comprend notamment :

• Plus de 130 logiciels libres à installer, pour Windows, répartis en 5 catégories principales :
1. Général : des logiciels pour tous (bureautique, graphisme, Internet…)
2. Élève : pour travailler dans toutes les disciplines de l’école primaire ;
3. Enseignant : pour aider les professeurs à préparer leur classe ;
4. Handicap : pour faciliter l’intégration des élèves en situation de handicap ;
5. Jeux : pour se divertir intelligemment ;

• Des copies d’écran ou des vidéos et des notices qui présentent les fonctionnalités de chaque logiciel ;

• Des tutoriels qui expliquent comment utiliser ces logiciels en classe ;

• Des ressources pédagogiques libres;

• Des textes, vidéos, images et sons utilisables et diffusables librement;

• Un installateur de logiciels qui permet en quelques clics d’ajouter très rapidement de nombreuses applications sur son ordinateur;

• L’encyclopédie pour enfants Vikidia disponible hors-ligne, sur le DVD, grâce au logiciel Okawix;

• Une distribution GNU/Linux particulièrement adaptée aux écoles, ASRI Éducation.

Le DVD est bien évidemment en libre téléchargement.

Cette compilation représente une contribution pour le développement des TUIC (Techniques Usuelles de l’Information et de la Communication) et en particulier des logiciels libres dans les classes.

La liste des applications et contenus est visible sur la page du projet.

Par ailleurs, il sera possible d’ici quelques semaines d’acheter ce DVD à bas prix sur notre boutique en ligne : EnVenteLibre.org. Si vous êtes intéressés, merci de remplir le formulaire dédié afin que nous puissions faire presser le DVD en quantité suffisante.

Enfin, suivant le succès des ventes du DVD, une partie des bénéfices sera redistribué aux communautés participantes, et nous envisageons un programme inspiré du “Get 1 Give 1” d’OLPC qui permettrait de faire parvenir gratuitement des exemplaires dans les pays à faible connectivité.

Bons téléchargements ^[1] !

Téléchargement et informations complémentaires sur la page officielle du FramaDVD Ecole.

Voici, révélé sur son blog par Bradley M. Kuhn (cadre dirigeant à la FSF impliqué dans le projet GNU), l’un des meilleurs ingrédients pour la réussite d’un projet de logiciel libre : rendre son développement public, dès la conception. C’est du moins l’enseignement qu’il retire d’un échange qu’il a eu avec Loïc Dachary, pionnier du logiciel libre, fondateur de la FSF France, d’EUCD.info ou encore de la plateforme d’hébergement de projets libres Gna! ^[1].

Or, si l’idée peut sembler simple, sa réalisation est loin d’être anecdotique et porte à de nombreux débats, comme le synthétise ici Bradley. Mais surtout, ce qui se dessine au travers de cette réflexion, c’est un élément fondamental de la définition de ce qu’est un projet libre, un projet ouvert, un projet pérenne : c’est un projet dont on partage les idées et la conception, en plus des sources. Bradley Kuhn oppose, en filigrane, à cette vision, celle de grands projets (qui se clament bien souvent eux-même « OpenSource ») dont en effet seul le code est publié. Des projets opposant une résistance aux contributions extérieures, et qui peuvent alors presque paradoxalement sembler hermétiques, fermés…

Plusieurs exemples viennent aisément en tête car c’est entre autres l’un des principaux reproches fait à Chromium, la version « OpenSource » du navigateur Google Chrome. Mais LibreOffice, le récent fork d’OpenOffice, illustre parfaitement la conclusion de Bradley, quand la communauté d’un projet de logiciel libre finit par n’avoir d’autre choix que de partir sur un embranchement définitif des fichiers sources pour en ouvrir au public le développement, et plus le code seulement.

Où sont les octets ? ^[2]

Where Are The Bytes?

Bradley M. Kuhn – 11 juin 2010 – EBB.org
(Traduction Framalang : Barbidule, Loquemunaine, Goofy)

Il y a quelques années, j’avais envisagé de me lancer dans un projet de logiciel libre. Il n’a pas vu le jour, mais j’ai appris au passage des choses bonnes à savoir. Quand j’ai pensé à démarrer ce projet, j’ai fait comme à mon habitude : j’ai demandé à quelqu’un qui en savait plus que moi. J’ai donc téléphoné à Loïc Dachary, qui a initié de nombreux projets de logiciels libres, pour lui demander conseil.

Avant même que je puisse ne serait-ce qu’évoquer mon idée, Loïc m’a demandé : « Tu as une URL » ? J’étais abasourdi. Ben, je n’ai pas encore commencé, répondis-je. Bien sûr que si, reprit-il, puisque tu m’en parles c’est que tu as commencé. Le plus important, c’est que tu me dises où sont les octets.

Loïc m’expliqua ensuite que la plupart des projets échouent. Le plus difficile dans un projet de logiciel libre est de le pousser à un stade suffisamment avancé pour qu’il puisse survivre même si ses créateurs initiaux le quittent. Donc, selon la théorie de Loïc, la tâche la plus urgente à accomplir au démarrage d’un projet, c’est de générer ces octets, dans l’espoir qu’ils se fraieront un chemin jusqu’à une équipe de développeurs qui contribueront à maintenir le projet actif.

Mais qu’est-ce qu’il entend par « octets » au juste ? Il veut tout simplement dire que vous devez exposer vos réflexions, votre code, vos projets, vos idées, presque tout en fait sur une adresse publique où tout le monde pourra les voir. Montrez vos octets, montrez-les à chaque fois que vous en créez si peu que ce soit. C’est la seule chance de survie de votre projet de logiciel libre.

Le premier objectif d’un projet de logiciel libre est de rassembler des développeurs. Aucun projet ne peut avoir de succès à long terme sans une base diversifiée de développeurs. Le problème c’est que le travail initial de développement et le planning du projet finissent trop souvent enfermés dans la tête d’un petit noyau de développeurs. C’est dans la nature humaine : comment puis-je passer mon temps à expliquer à chacun ce que je suis en train de faire ? Si je le fais, quand trouverai-je le temps de faire vraiment avancer les choses ? Ceux qui dirigent les projets de logiciels libres savent résister à ce désir naturel et font ce qui peut sembler contre-intuitif : ils exposent leurs octets publiquement, même si cela les ralentit un peu.

Ce processus est d’autant plus nécessaire à l’ère des réseaux. Si quelqu’un veut créer un programme qui remplisse sa mission, son premier outil est le moteur de recherche : il s’agit de savoir si quelqu’un d’autre a déjà fait le boulot. L’avenir de votre projet dépend entièrement du fait que chaque recherche de ce type aide des développeurs à découvrir vos octets.

Début 2001 j’ai demandé à Larry Wall quel était le projet le plus difficile parmi tous ceux sur lesquels il a travaillé. Sa réponse fut immédiate : "quand j’ai développé la première version de Perl5," m’a dit Larry, "j’avais l’impression que je devais coder tout seul et le faire tourner par mes propres moyens". Bien sûr, Larry est un gars tellement doué qu’il peut se permettre de créer à lui tout seul un programme que tout le monde voudra utiliser. Bien que je ne lui aie pas demandé ce qu’il ferait aujourd’hui dans une situation pareille, je devine – particulièrement quand on voit comment le développement de Perl6 est devenu public – qu’il utiliserait plutôt les nouveaux outils en ligne, tels que DVCS, pour montrer plus vite et plus souvent ses octets, et chercher à impliquer plus tôt davantage de développeurs^[3].

Il est vrai que la priorité de la plupart des développeurs est de tout cacher. "On publiera quand ce sera prêt", ou bien – pire encore – "le noyau dur de l’équipe travaille bien ensemble ; rendre le projet public maintenant ne ferait que nous ralentir". En vérité, c’est un mélange dangereux de peur et de narcissisme, exactement la même pulsion que celle qui pousse les développeurs de logiciels non-libres à les conserver propriétaires.

Les développeurs de logiciels libres ont la possibilité de dépasser la réalité fondamentale de tout développement logiciel : le code est mal fichu, et n’est généralement pas terminé. Malgré tout, il est essentiel que la communauté puisse voir ce qu’il se passe à chaque étape, dès le noyau initial du code et au-delà. Quand un projet est perçu comme actif, cela attire les développeurs et donne au projet une chance de succès.

Quand j’étais à la fac, une des équipes d’une classe de génie logiciel s’est complètement plantée. C’est arrivé alors même qu’un des membres de l’équipe avait passé près de la moitié du semestre à coder par lui-même, nuit et jour, sans se soucier des autres membres de l’équipe. Durant l’évaluation finale, le professeur lui fit remarquer : « un développeur de logiciel, ce n’est pas un pilote de chasse ». L’étudiant, ne voyant pas le rapport, plaisanta : « Ouais, je sais, au moins le pilote de chasse, il a un copilote ». En vérité, il ne suffira pas d’une personne ou deux, ou même d’une petite équipe, pour faire aboutir un projet de logiciel libre. Le projet ne marchera que s’il est soutenu par une communauté importante qui évitera tout point individuel de défaillance.

Il n’en reste pas moins que la plupart des projets de logiciels libres sont voués à l’échec. Cependant, il n’y a aucune honte à balancer quelques octets, pour inciter les gens à y jeter un oeil, quitte à laisser tomber si la mayonnaise ne prend pas. Toute la recherche scientifique fonctionne ainsi, et il n’y a pas de raison pour que l’informatique fasse exception. Garder un projet privé, c’est garantir son échec ; le seul intérêt, c’est que vous pouvez dissimuler le fait que vous avez essayé. Comme le disait mon directeur de thèse lorsque je me faisais du souci quant à la réussite de ma recherche : un résultat négatif peut être aussi intéressant qu’un résultat positif. Ce qui est important, c’est d’être sûr que tous les résultats seront publiés et que le public pourra les examiner.

Quand j’ai commencé à parler de cette idée il y a quelques semaines, certains m’ont répondu que les premiers programmes GNU, les logiciels fondateurs de notre communauté ont d’abord été développé en privé. C’est vrai, mais le fait que les développeurs du projet GNU aient procédé de cette façon ne veut pas dire que c’est la bonne. Nous disposons désormais des outils pour faire facilement du développement en public, et nous devrions le faire. De mon point de vue, aujourd’hui nous ne sommes pas vraiment dans l’esprit du logiciel libre tant que le projet, y compris les discussions sur sa conception, les plans et les prototypes, ne sont pas développés publiquement. Le code (quelque soit sa licence) qui n’est que balancé à intervalles plus ou moins réguliers mérite d’être repris par une communauté qui rende son développement public.

Mise à jour (2010-06-12) : J’ai complètement oublié de parler de « The Risks of Distributed Version Control » par Ben Collins-Sussman, qui date de cinq ans maintenant mais qui est toujours d’actualité. Ben fait un constat similaire au mien, et remarque que certaines utilisations de DVCS peuvent avoir les effets que j’encourage les développeurs à éviter. Je pense que DVCS est comme n’importe quel autre outil : il peut être mal utilisé. Il faut éviter de s’en servir comme Ben le signale, et DVCS, lorsqu’il est utilisé correctement, aide dans le processus de développement public de logiciel.

Comme nous l’annoncions il y a tout juste 10 mois, Framasoft a mis en place un service destiné à favoriser la migration, en douceur, des utilisateurs de Windows vers les logiciels libres. Or, comme pour l’annuaire Framasoft dès ses débuts, le succès rencontré par Framapack aujourd’hui nous confirme que les logiciels libres, on les aime d’abord un peu, et puis beaucoup, et même passionnément dans les associations du libre, voire à la folie selon certains.

En quelques mots, Framapack permet d’installer automatiquement sur un ordinateur équipé de Windows toute une collection de logiciels libres.

Ainsi, sur Framapack.org vous pouvez sélectionner parmi les cinquante applications proposées celles qui correspondent à vos besoins, et télécharger d’un clic l’installateur généré pour vous à la volée en fin de sélection. Un nouveau clic vous permet de lancer l’installateur sur la machine à libérer, et ce dernier se chargera alors de télécharger à son tour et d’installer pour vous les dernières versions des logiciels libres que vous avez choisis.

Il est important de préciser que les applications sont installées telles que vous les auriez téléchargées depuis leur site d’origine, sans avoir subit la moindre transformation de notre part^[1].

Or, nous sommes fiers de pouvoir annoncer aujourd’hui que ce projet, dont les maîtres mots sont simplicité et liberté^[2], a rencontré un succès dépassant nos pronostics, en distribuant plus de 100 000 logiciels libres au cours de ses 8 premiers mois d’existence.

Nous ne pouvons que remercier les quelque 5000 visiteurs mensuels de nous accorder ainsi leur confiance.

Enfin, si vous n’y trouvez pas le logiciel que vous cherchez ou si vous avez une idée d’amélioration, n’hésitez pas à nous déposer un petit message sur contact _arobase_ framapack.org. Pour l’heure, nous envisageons d’ajouter dans les prochaines versions du projet un petit morceau de musique libre pour agrémenter le temps de chargement des applications, n’hésitez pas à nous faire part de vos préférences dans les commentaires de cet article.