À l’occasion de la sortie du framabook Produire du logiciel libre (dont notre secret espoir est qu’il suscite des vocations chez les jeunes et les moins jeunes), nous avons posé quelques questions à son auteur Karl Fogel.

Est-ce que la situation a évolué depuis la première version du livre, en particulier avec les nouvelles forges comme GitHub (qui repose entre autres la question du fork) ? Est-ce un problème d’héberger des logiciels libres sur des plateformes propriétaires ? Est-ce que l’informatique devrait être enseignée en tant que telle aujourd’hui à l’école ?

Autant de questions auxquelles il apporte de très intéressantes réponses.

Entretien avec Karl Fogel

L’interview en version originale anglaise sur le blog de Karl (intéressants commentaires inside)

(Traduction Framalang : Don Rico pour les questions et Olivier Rosseler pour les réponses)

La version française de POSS vient tout juste d’être publié et votre livre a été traduit, ou est en cours de traduction, dans d’autres langues. Que pensez-vous de ces adaptations de votre œuvre, rendues possibles par le choix de le placer sous licence libre ?

Je suis absolument ravi. Je n’y vois vraiment aucun inconvénient. Les traductions permettent une diffusion plus large du livre, et c’est exactement ce que je souhaite.

Je suis extrêmement reconnaissant envers les traducteurs.

Si vous deviez écrire une deuxième version de POSS aujourd’hui, qu’est-ce que vous changeriez ou ajouteriez ? Et d’ailleurs, est-ce qu’une deuxième version est prévue ?

Et bien, en fait, j’y apporte toujours des petites modifications, à mesure que les pratiques de l’open source évoluent. La version en ligne change constamment. On pourra peut-être la nommer officiellement « Version 2.0 » à un moment donné, mais au fond, c’est vraiment un processus continu.

Par exemple, il y a cinq ou six ans, presque tous les projets avaient leur propre infrastructure de développement. Chacun avait son serveur, son système de contrôle de versions, son système de suivi de bogues, un responsable de la liste de diffusion, un wiki peut-être, c’étaient les outils de développement.

Mais depuis, on a assisté à des regroupements. De nos jours, seuls les très gros et les très petits projets possèdent leur propre infrastructure. La majorité des projets choisissent des sites pré-conçus, comme GitHub, Google Code Hosting, SourceForce, Launchpad, etc. La plupart des développeurs open source se sont familiarisés avec ces environnements.

Et par conséquent, j’ai mis à jour la partie du livre traitant des infrastructures d’hébergement, pour enrichir la section « Les sites Web » et parler des sites comme ceux mentionnés ci-dessus, plutôt que de ré-inventer la roue à chaque projet. Les gens se rendent bien compte qu’administrer son propre hébergement requiert énormément de ressources, malgré les avantages que l’on peut en tirer, et que donc, externaliser cette tache est devenu presque une obligation si on veut avoir un peu de temps pour effectivement travailler sur le projet.

J’ai également mis le livre a jour pour parler des nouvelles versions des licences open source (comme la GNU General Public License 3, qui est sortie après que le livre ait été publié), et j’ai également revu mes recommandations vis à vis de certains logiciels, car les temps changent. Par exemple, Git est de bien meilleure qualité aujourd’hui qu’à l’époque où j’ai rédigé la toute première édition.

La manière de produire des logiciels libres n’a pas tellement changée en cinq ans. Mais de nouvelles forges sont apparues, sur un modèle un peu différent de SourceForge. Je pense à Google Code mais surtout à GitHub. GitHub serait un peu le « Facebook des forges open source », avec ses fonctions de réseau social, son édition à même le navigateur… Son slogan est « Fork me on GitHub ». La notion de fork semble ne plus être tout à fait la même qu’avant. Que pensez-vous de tout cela ?

En fait, je pense que la notion de fork n’a pas changé. La terminologie, peut-être, mais pas le concept.

Si je me penche sur les dynamiques des rouages des projets open source, je ne vois pas de differences fondamentales selon que le projet utilise une forge ou l’autre. GitHub propose un produit fantastique, mais ils ont aussi un marketing fantastique. Ils encouragent les projets à inviter leurs utilisateurs à « créer une fork sur GitHub », c’est à dire « créer une copie pour jouer un peu avec ».

Et même si en un sens la copie d’un projet hébergé sur Git peut techniquement s’appeler un « fork », en pratique ça n’en est pas un. Le concept de fork est avant tout politique, pas technique.

À l’origine, initier un fork signifiait élever la voix pour dire : « nous pensons que le projet ne prend pas la bonne direction, nous avons pris la décision d’en faire une copie pour le poursuivre dans la bonne direction, que tout ceux qui partagent ce point de vue se joignent à nous ». Et les deux projets se retrouvaient alors publiquement en concurrence, à l’attention des développeurs et des utilisateurs, parfois aussi pour des questions d’argent. Parfois l’un des deux l’emporte, parfois ils fusionnent pour ne former à nouveau qu’un seul projet. Mais quelle qu’en soit l’issue, c’est avant tout un processus politique : susciter des adhésions pour continuer ensemble le projet.

Cette dynamique est toujours d’actualité, elle se poursuit tous les jours. Qu’on parle de « fork » pour designer quelque chose de différent, pourquoi pas, mais ça ne change pas la réalité, on utilise juste un terme différent pour décrire la réalité.

GitHub a commencé à parler de « fork » pour dire « créer une copie à bidouiller ». Maintenant, c’est vrai qu’avec ce genre de copie il est facile de s’éloigner du projet originel pour re-fusionner plus tard, c’est l’une des caractéristiques de Git et de tous les systèmes de contrôle de version décentralisé. Et c’est vrai que s’éloigner pour re-fusionner est plus compliqué avec les systèmes de contrôle de version centralisé comme Subversion et CVS. Mais tous ces « forks » créés sur Git ne sont pas des forks au sens premier du terme. En général, lorsqu’un développeur se fait une copie sur Git et la modifie, c’est en espérant que ses changements seront fusionnés dans la copie « maîtresse ». Et quand je dis « maîtresse », ce n’est pas au sens technique, mais bien au sens politique : la copie maîtresse est celle que la plupart des utilisateurs suivent.

Je trouve que ces fonctionnalités de Git et de GitHub sont géniales, et j’aime bien les utiliser, mais il n’y a rien de révolutionnaire ici. Il y a peut-être une évolution de la terminologie, mais la vraie dynamique des projets open source ne varie pas : les développeurs fournissent de gros efforts pour que leurs modifications soient intégrées a la distribution principale, car ils ne veulent pas s’embarrasser avec une copie privée qu’ils auraient a entretenir. Git réduit la pénibilité liée à la maintenance de modifications indépendantes, mais pas encore suffisamment pour que cet effort soit négligeable. Les développeurs intelligents forment des communautés et tentent de conserver un code de base unifié, car c’est la meilleure chose à faire. Ça n’est pas près de changer.

En juin 2010, Benjamin Mako Hill remarque dans son article Free Software Needs Free Tools (traduit ici sur le Framablog) qu’héberger un projet libre sur une plateforme propriétaire pose problème. À votre avis, quelle est l’importance de ce problème ?

Et bien, je connais Mako Hill, je l’apprécie et j’éprouve beaucoup de respect pour lui. Mais je dois dire que je ne partage pas son avis sur ce point, et ce, pour plusieurs raisons.

D’abord, il faut être réaliste. On ne peut pas être un développeur logiciel sans outils propriétaires de nos jours. Réduire arbitrairement la notion de « plateforme » n’est qu’un artifice pour croire qu’on travaille dans un milieu entièrement libre. Par exemple, je peux héberger mon projet chez Launchpad, qui est un logiciel libre, mais est-ce que je peux vraiment écrire du code sans utiliser le moteur de recherche de Google, qui n’est pas libre ? Bien sur que non. Tous les bons programmeurs utilisent en continu Google, ou un autre moteur de recherche propriétaire. Il faut inclure ces recherches Google dans la « plateforme », impossible de se voiler la face.

Mais on peut pousser la réflexion plus loin :

Qu’attendez-vous de l’hébergeur de votre projet, quelles sont les libertés importantes ? Vous utilisez une plateforme et vous demandez aux autres de l’utiliser aussi pour collaborer avec vous, donc, idéalement, la plateforme devrait être libre.

Ainsi, si vous souhaitez y apporter des modifications, vous pouvez : si quelqu’un veut créer un fork de votre projet (au sens ancien, politique, du terme), ils peuvent reproduire l’infrastructure d’hébergement ailleurs, où ils la contrôleront, si nécessaire. Alors, en théorie tout cela est très bien et très joli, mais honnêtement, même si le code source de Google Code, par exemple, était libre, vous ne pourriez pas reproduire Google Code Hosting. Il vous manquerait encore le personnel, le service, les data center de Google… toute l’infrastructure qui n’a rien à voir avec le code source. Ça n’est pas réalistiquement faisable.

Vous pouvez forker le projet, mais en général vous ne pouvez pas reproduire son hébergement, cela demande trop de ressources. Et puisque ça n’est pas votre propre service, vous ne pouvez pas l’adapter a votre convenance ; ce sont les gens qui font tourner les serveurs matériels qui décident de quels ajustements sont acceptables ou pas. Donc dans la pratique, vous ne disposez pas de ces libertés.

(Certains services d’hébergement tentent d’octroyer autant de libertés que possible a leurs utilisateurs. Par exemple, le code de Launchpad est open source, et ils intègrent les correctifs de leurs membres. Mais l’entreprise qui héberge Launchpad doit quand même approuver chaque modification puisque ce sont eux qui font tourner les serveurs. Je crois que SourceForge veut tenter la même expérience, si l’on en croit l’annonce faite récemment à propos d’Allura.)

Alors, en fonction de tout cela, quelles sont les libertés possibles ?

Il vous reste la liberté de faire entrer et sortir vos données. En d’autres termes, le noeud du problème se situe au niveau de la possibilité qu’on les interface de programmations (API pour Application Programming Interfaces) de déplacer les données d’un service à l’autre, de manière fiable et automatique. Si je peux écrire un programme qui peut récupérer toutes les données de mon projet depuis une forge pour les transférer à une autre, c’est une liberté utile. Je ne suis pas pieds et poings liés. Ça n’est pas la seule liberté qui compte, on est même loin d’une liberté idéale. Mais c’est une liberté utile dont on dispose dans un monde où utiliser ses propres serveurs est devenu inabordable.

Ce n’est pas que cette conclusion m’enchante. Mais les choses sont ainsi. La période de « chasseur/cueilleur » dans l’open source est terminée, nous sommes entrés dans l’ère agricole et urbaine. Vous ne pouvez plus creuser vos propres sillons d’irrigation ou votre propre système d’évacuation des eaux usées. C’est trop compliqué. Mais, au moins, si vous n’êtes pas satisfait du service rendu par un hébergeur, vous pouvez déménager chez un autre plus efficace grâce a la portabilité des données.

Donc ça m’importe assez peu de savoir que la plateforme GitHub est propriétaire, par exemple. Evidemment, ça serait mieux si elle était entièrement open source, mais le fait qu’elle ne le soit pas n’est pas vraiment un énorme problème. Le premier critère auquel je fais attention lorsque j’évalue un service d’hébergement est la richesse de leurs APIs. Est-ce que je peux récupérer toutes mes données si besoin ? Si leurs APIs sont riches, c’est bon signe, ils feront leur travail pour maintenir un service de qualité, car c’est le critère qui leur permettra de conserver leurs utilisateurs.

En France, les élevés de collège et de lycée ne suivent pas de cours d’informatique. Pensez-vous que l’informatique devrait être une matière a part entière, et pas seulement un outil pour les autres matières ?

Evidemment. La compréhension des données et du calcul formel est très importante désormais. C’est une forme d’alphabétisme. Sans aller jusqu’à maîtriser la programmation, il faut savoir comment les données fonctionnent. Cela fait écho à une discussion récente où je me suis rendu compte du gouffre qui peut exister.

J’étais chez le docteur, pour faire quelques tests. L’un d’eux consistait à filmer les battements de mon cœur grâce aux ultra-sons et toute la séquence était enregistrée. C’était incroyable a voir ! Et donc, une fois terminé, je demande à l’accueil si je pouvais avoir les données. Pour être précis, j’ai demandé : « Est-ce que je pourrai avoir les données de l’echocardiogramme ? » L’assistante m’a répondu qu’ils pouvaient m’imprimer des images basse-résolution. J’ai alors répondu : « Merci, mais ce sont les données que je veux ». Elle m’a répondu que c’est bien ce qu’elle me proposait. Pour elle, le mot « données » n’avait pas la même signification précise que pour ceux qui ont appris ce que sont les données. Ma question impliquait évidemment que je voulais toutes les données qu’ils avaient enregistres. C’est bien ce que signifie « Toutes les données », non ? Il ne devrait pas y avoir de perte d’information : c’est une copie bit par bit. Mais cela ne lui parlait pas. Pour elle, les données, c’est « quelque chose qui ressemble a ce que j’ai demandé ». Je parlais d’information, d’informatique, elle me parlait de perception.

Je suis bien conscient que mon point de vue est radical, mais je trouve que c’est une forme d’illettrisme de nos jours. Vous devez savoir faire la différence entre les vraies informations et les fausses informations et vous devez comprendre l’énorme différence d’application qui existe entre les deux. Si je me rends chez un autre médecin, vous imaginez bien la différence que ça fait si je lui présente la vidéo complète sur clé USB par rapport à des copies basse résolution d’images fixes. L’une est utile, l’autre ne sert strictement à rien.

Les entreprises qui comprennent le mieux la valeur des données, de données nous concernant, ont de plus en plus de moyens d’utiliser ces données à leur avantage, mais pas nécessairement dans le vôtre. Les cours d’informatique sont une forme de défense contre ceci, une réponse immunitaire à un monde dans lequel la possession et la manipulation des données se transforme de plus en plus en pouvoir. Vous êtes mieux à même de comprendre comment les données peuvent être utilisées si vous les avez déjà manipulées vous-même.

Donc oui, je suis pour les cours d’informatique… mais pas seulement comme moyen de défense :-). C’est aussi une formidable occasion pour les écoles de réaliser quelque chose de collaboratif. L’enseignement se focalise trop souvent sur des apprentissages « individuels ». D’ailleurs, la coopération à l’école est souvent prohibée et on appelle cela de la triche. Or en cours d’informatique, la chose la plus naturelle est d’initier des projets open source ou de participer à des projets open source.

Bien sûr, tous les étudiants ne seront pas forcément doués ou hyper motivés pour cela, mais c’est la même choses dans toutes les autres matières. Je pense donc que les cours d’informatique sont une bonne opportunité d’exposer les élèves aux plaisirs du développement collaboratif. Ces cours devraient avoir un impact incroyable sur certains élèves, comme, par exemple, les cours de musique.

Une toute dernière question : quel conseil donneriez-vous au programmeur en herbe qui souhaite découvrir la communauté des logiciels libres et open source ? Essayez de répondre en une phrase, pas avec un livre entier 🙂

Trouvez un projet ouvert que vous appréciez (et, idéalement, que vous utilisez) et commencez à y participer ; vous ne le regretterez pas !

Certains résistent encore mais nombreux sont les visiteurs (et rédacteurs) de ce site à posséder un compte de messagerie Google Gmail.

Il faut dire que, techniquement parlant, c’est une excellente application en ligne^[1].

Mais il ne faut pas oublier de dire aussi que, techniquement parlant, l’application est propulsée par du code JavaScript qui est malheureusement non libre, avec toutes les conséquences (néfastes) que cela implique.

Or puisqu’il existe une version simplifiée de Gmail, épurée de ce code, cela signifie d’abord que l’on peut s’en passer et ensuite que cette surcouche pourrait fort bien devenir libre.

C’est la proposition de la Free Software Foundation qui nous invite à faire pression sur Google pour qu’il accepte ce pas dans la bonne direction.

Évitons les pièges du JavaScript de Gmail

Avoid the pitfalls of the JavaScript Trap on Gmail

Matt Lee – 30 mars 2011 – FSF.org
(Traduction Framalang : Goofy et Penguin)

Nous lançons aujourd’hui la première phase d’une série d’opérations à mener pour utiliser les sites Web les plus populaires sans leur code JavaScript propriétaire.

Vous n’êtes peut-être pas conscient des dangers du JavaScript, un problème que nous avons intitulé le piège JavaScript, lorsque du logiciel propriétaire est exécuté dans le navigateur de votre ordinateur.

Nous concentrerons notre première opération sur le service Gmail de Google.

Le piège JavaScript

Lorsque vous visitez un site Web comme Gmail, votre navigateur va télécharger et exécuter plusieurs milliers de lignes de code JavaScript. Le code JavaScript n’est pas différent de langages comme Pyhon, C++ ou Ruby (les applications qui sont exécutées sur nos ordinateurs et qui sont écrites dans ces langages doivent être des logiciels libres, afin que nous puissions les exécuter, les modifier et les partager si nous en avons envie). Le JavaScript d’aujourd’hui n’est plus le JavaScript d’autrefois, il est désormais utilisé pour écrire de puissantes applications côté serveur grâce à des logiciels libres comme Node.js et le moteur JavaScript V8.

De plus, nous avons vu récemment des entreprises comme Research In Motion (les fabricants du BlackBerry) recommander à leurs clients de désactiver complètement le JavaScript du navigateur WebKit de leurs téléphones à cause de la découverte d’un problème de sécurité. Même si les logiciels libres qui intègrent du JavaScript peuvent également avoir des problèmes de sécurité, cet exemple illustre le fait que nous avons un réel besoin d’avoir accès au code qui s’exécute sur nos ordinateurs, et de pouvoir le modifier.

Ce que JavaScript pourrait faire

Il est évident que le JavaScript est une technologie très puissante et très utile lorsqu’elle se trouve entre de bonnes mains. De nombreux développeurs de logiciels libres ont ainsi écrits des extensions et des améliorations pour des sites populaires grâce à des outils comme GreaseMonkey. Il existe une flopée de scripts Greasemonkey libres pour Gmail. L’existence de tels scripts montre à la fois que le JavaScript de Gmail n’est pas trivial, mais également que des utilisateurs pourraient faire des contributions intéressantes et utiles si le code JavaScript était publié en tant que logiciel libre pour leur permettre de le modifier.

Par ailleurs, des sites comme Gmail, Twitter et Facebook utilisent beaucoup trop de JavaScript pour proposer leurs services. La preuve en est que les mêmes services en version mobile proposent pratiquement les mêmes fonctionnalités sans JavaScript. Là où la nécessité du JavaScript se fait sentir il peut être publié en tant que logiciel libre, et là où ces raffinements supplémentaires sont facultatifs, on peut fournir une version basique du site qui n’a pas besoin de JavaScript.

Google a fait un premier pas vers cet objectif en développant une version du site Gmail en « Version HTML simplifiée », qui ne dépend donc pas d’un copieux code JavaScript pour proposer une interface utilisateur. Google propose également les protocoles IMAP et POP qui permettent d’accéder aux comptes Gmail sans passer du tout par la case site Web. Ces initiatives constituent toutes deux des avancées positives vers un idéal plus vaste.

Notre requête à Google : une étape de plus dans la bonne direction

Si vous utilisez Gmail, demandez gentiment mais fermement à Google d’être « logiciel libre friendly » en publiant le code JavaScript de Gmail sous une licence libre. En acceptant de le faire, Google permettrait aux utilisateurs qui accordent de l’importance aux libertés logicielles d’utiliser Gmail dans une version avancée, et de proposer des contributions et modifications utiles à tout le monde.

Nous serions ravis de recevoir vos réactions et suggestions, ainsi que les démarches que vous proposez pour les sites les plus connus. Vous pouvez dès maintenant ajouter vos idées et contributions sur le wiki de LibrePlanet.

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.