Jehan est un contributeur actif de l’excellent logiciel libre d’édition et de retouche d’image GIMP. Il se propose ici de développer la fonctionnalité « peinture en miroir » et s’en explique (fort bien) ci-dessous.

Il ne demande pas la lune mais quelques deux mille euros. Parce qu’il a besoin de temps et que le temps c’est souvent de l’argent.

Non, logiciel libre ne veut pas dire gratuit, et comme le rappelle François Elie, le logiciel libre est gratuit une fois fois qu’il a été payé (en temps et/ou en argent). L’avantage ici c’est qu’on le paye une seule fois et qu’il s’en va direct dans le pot commun.

L’occasion également de mettre en avant le projet (français) Open Funding, nouvelle et prometteuse plateforme de financement participatif du logiciel libre.

Proposition de Financement Participatif de Peinture Symétrique dans GIMP

Jehan – 16 septembre 2013

URL d’origine du document

Salut à tous,

comme vous vous en souvenez peut-être, je suis un des développeurs de GIMP. Je propose ce jour de co-financer une fonctionnalité qui m’intéresse, et qui intéresse apparemment d’autres personnes, d’après ce que j’ai pu voir: la peinture en miroir (ou plus largement « symétrique »).

Introduction

Sur la liste de diffusion de GIMP et ailleurs, j’ai vu plusieurs personnes demandant du financement collaboratif pour améliorer GIMP. J’ai donc décidé d’appliquer l’idée et de tester la viabilité du financement collaboratif pour améliorer du Logiciel Libre.

Notez que je suis un développeur avec un bon passif et partie de l’équipe principale du programme. Cela signifie qu’en cas de financement, j’implémenterai la fonctionnalité complète et m’arrangerai pour qu’elle soit intégrée dans le logiciel final. Ce ne sera donc pas un énième fork qui disparaîtra dans quelques années, mais une fonctionnalité faite pour durer.

La Fonctionnalité

Proposition

Implémentation d’un fonctionnalité de peinture en symétrie/miroir instantanée dans GIMP.

Description

GIMP est l’un des principaux outil de traitement d’image multi-usage et multi-platerforme (Windows, OSX, Linux, BSD…). Pour la peinture en particulier, certaines fonctionnalités manquent. L’une d’elle est de pouvoir dessiner en symétrie instantanée.

À l’heure actuelle, les seule possibilités sont soit de dessiner des formes très simples, soit d’utiliser des filtres ou plug-in après coup, soit de dupliquer puis retourner les calques. Toutes sont de loin moins pratiques que de pouvoir dessiner et voir son dessin apparaître en miroir en temps réel.

Usage

J’ai rencontré au moins un artiste qui utilisait un mode de miroir vertical dans un autre programme pour rapidement conceptualiser des personnages, lors des premières étapes du design de personnages, période pendant laquelle le temps vaut plus que l’art. Je peux aussi aisément imaginer que cela simplifiera la création de designs symétriques complexes (logo, etc.).

Et probablement de nombreux autres usages. Par exemple, jetez un œil au dessin original dans la vidéo ci-dessous. La dessinatrice, Aryeom Han, a testé ma première (instable et encore loin de la perfection) implémentation pour dessiner la réflexion d’un lac, ensuite redimensionnée, puis ajout de gradient et utilisation du nouvel outil warp pour donner un effet liquide.

Implémentation

Idée 1 Ma dernière implémentation de test implémentait la symétrie comme une option d’outil de peinture. Néanmoins je prévois de tester d’autres implémentations en même temps. Par exemple lier les axes de symétrie à l’image pourrait être une implémentation plus appropriée pour un travail de longue durée. Le design final n’est pas encore fixe.

Idée 2 Il doit y avoir des raccourcis pour rapidement activer/désactiver les symétries.

Idée 3 L’idée de base est d’avoir au moins 3 modes de symétries (horizontale, verticale, centrale) à utiliser ensemble ou séparément. Évidemment en allant plus loin, on devrait pouvoir faire faire des rotations sur les axes pour avoir une rotation d’angle arbitraire. Je n’implémenterai peut-être pas cette option avancée (à moins que le financement ait un succès phénoménal), mais si possible j’essaierai de rendre le système suffisamment générique pour être plus tard étendu et permettre la rotation des axes dans le futur.

Idée 4 Les axes/centres de symétrie doivent pouvoir être rendus visibles ou invisibles.

Idée 5 Les axes/centres de symétrie doivent pouvoir être déplaçables sur le canvas par simple drag’n drop, de manière similaires aux guides. J’ai une implémentation en cours, comme vu dans la vidéo et les photos d’écran. Mais le gros du travail pour rendre la fonctionnalité solide n’a pas encore débuté.

Ce à quoi s’attendre

• J’écouterai les commentaires.
• Le design peut évoluer pendant le développement. Je ne peux promettre exactement la forme finale car cela nécessite aussi discussion et approbation de mes pairs de l’équipe de GIMP. Je ne suis pas seul à décider.
• Puisqu’il s’agit d’une toute nouvelle fonctionnalité, elle sortira avec GIMP 2.10 (pas de date de sortie encore), voire même plus tard si ce projet ne peut être financé correctement, ou toute autre raison hors de mon contrôle. Néanmoins dès que les patchs seront prêts, quiconque pourra compiler le projet lui-même à partir de la branche de développement. Notez aussi que si certains attendent vraiment cette fonctionnalité impatiemment et si j’ai obtenu un financement exceptionnel, j’essaierai de proposer des binaires à télécharger.
• En fonction du succès du financement, s’il dépasse mes espérances, j’implémenterai éventuellement des options plus avancées de la fonctionnalité (comme le fait de pouvoir faire une rotation des axes de symétrie, etc.).
• Je donnerai des nouvelles de l’avancée sur la page de nouvelles du Studio Girin, c’est à dire ce même site web.

À Mon Propos

Je suis un développeur de GIMP, indépendant, et travaillant dernièrement beaucoup avec une dessinatrice. J’ai participé aux deux dernières versions de correction de bug de GIMP (2.8.4 et 2.8.6) et suis une part active de la prochaine sortie majeure (2.10). Vous pouvez avoir une idée de mon activité dans le logiciel Libre sur Ohloh et sur le suivi de ticket de GNOME.

Liste non-exhaustive de fonctionnalités et corrections déjà intégrées dans GIMP :

• support du XDG dans GIMP (fichiers de configurations dans $XDG_CONFIG_HOME) sur Linux ;
• configuration dans le « Roaming Application Data folder » (répertoire utilisateur) sur Windows ;
• support du standard de gestion des miniatures (Freedesktop’s Thumbnail Management Standard) ;
• plusieurs améliorations de l’interface et corrections de bugs ;
• plusieurs corrections de crashs sévères (en particulier le crash quand vous déconnectiez votre tablette graphique ! À partir de GTK+ 2.24.19, vous n’aurez plus à vous en soucier !) ;
• amélioration de la liste de langages pour localisation (les noms de langages sont self-traduits) ;
• déja plusieurs améliorations du plugin « Animation Playback » (scroll, zoom, refresh, sélection de la disposition des frames, pas en arrière, raccourcis…) ;
• encore plus de travail-en-cours sur le plugin « Animation Playback » (dont je suis maintenant mainteneur) afin d’en faire un outil indispensable aux animateurs 2D ;
• etc.

Je contribue aussi sur d’autres projets divers comme vous pouvez le voir sur la page Ohloh (pas tout n’y est listé, en particulier pour les projets qui utilisent encore CVS ou svn, qui perdent donc la paternité des patchs. Par exemple Blender, etc.).

Et Après ?

Si j’obtiens un financement, je proposerai d’autres fonctionnalités, pour GIMP principalement, mais probablement aussi pour d’autres logiciels que j’utilise. Je travaille actuellement en indépendant, et avoir la communauté des Logiciels Libres et OpenSource comme boss serait un job idéal. J’adorerais travail pour vivre sur des Logiciels Libres et faire du monde un endroit bien à vivre. Pas vous ?

Donc même s’il ne s’agit pas forcément de votre fonctionnalité préférée, je dirais que vous pouvez tout de même y gagner en finançant, si cela me fait continuer à travailler sur des fonctionnalités avancées de GIMP, peut-être même à temps-plein dans le futur, qui sait ? Bien sûr, je prévois de continuer à améliorer GIMP même sans financement, mais il y a des limites à ce qu’il est possible de faire quand on a besoin de vivre par ailleurs.

Une liste possible, non-exhaustive encore, de fonctionnalités qui m’intéressent, et que je pourrais éventuellement proposer dans de futurs projets de financement collaboratifs, est par exemple: faire du plug-in « animation-playback » un outil indispensable pour les créateurs d’animation, les macros, unlimited-sized layers, les images extérieures « liées » comme calques (proche du concept de Smart Object, mais encore plus proche des objets liés de Bender, ce qui est à mon avis bien plus puissant), édition non-destructive, sélection de plusieurs calques pour des modifications de masse, améliorations des options d’export (par exemple redimensionner à l’export sans toucher l’original), et bien plus.

Notez aussi que si cela fonctionne, ce serait aussi un bon précédent pour d’autres développeurs qui pourraient aussi penser à travailler ainsi et améliorer GIMP (et d’autres logiciels Libres et OpenSource). Je pense que c’est gagnant-gagnant ! 🙂

Pour conclure, sachez que je ne travaille pas seulement sur GIMP, mais aussi avec GIMP, ou en particulier avec la dessinatrice talentueuse qui a dessiné le « lapin près d’un lac » dans la vidéo, et nous prévoyons de produire des BDs et des animations, le tout avec des Logiciels Libres et sous des licenses d’Art Libre (comme CC by-sa). Donc en me finançant, vous financez aussi l’Art Libre. Juste au cas où vous ayez besoin de plus d’encouragement ! 😉

Vous n’avez pas encore cliqué sur le lien ?

Co-financez la Peinture en Symétrie dans GIMP !

Bryan Lunduke est développeur. En faisant passer ses logiciels de propriétaires à libres, il a fait une bien triste constatation.

Non seulement il ne gagne plus assez d’argent pour trouver le temps de continuer à les développer (et personne d’autres ne semble intéressé à le faire sauf lui) mais en plus les téléchargements ont drastiquement baissé, alors même qu’ils sont mis gratuitement à disposition.

Un billet un peu troll qui se demande quand même si on peut faire de ce cas particulier une généralité.

Regard attristé sur les chiffres de l’open source

Very sad looking Open Source charts

Bryan Lunduke – 27 août 2013 – Blog personnel
(Traduction : schiste, Genma, brihx, mokas01, @zessx, MFolschette, Asta, elfabixx, La goule, Beij, goofy, Penguin + anonymes)

Depuis un certain temps déjà, chaque ligne de code que j’écris est placée sous licence libre GPL (la plupart de ce que j’ai publié avant était sous licence propriétaire) parce que j’aime l’open source. Mais il y a un souci sur lequel je planche et bloque. Et j’ai besoin de votre avis. Je vous explique rapidement :

Lorsque mes logiciels étaient sous licences privatives, et leur développement financé à l’ancienne par la vente de copies, les mises à jour étaient plutôt fréquentes (en général plusieurs versions par mois). Les bénéfices retirés des ventes allaient directement dans le financement de temps de développement dédié. Ça fonctionnait assez bien. Pas 100 % parfait, mais le développement avançait à un bon rythme.

Maintenant que le logiciel est libre, on ne peut espérer plus de 200 $ par mois en dons. Je ne peux du coup raisonnablement passer que quelques heures par mois sur ce logiciel. Ce qui n’est même pas assez pour tester une version et en faire un package à publier (et certainement pas assez pour ajouter des fonctionnalités notables).

Donc, pour faire simple, ma production de code s’est tout bonnement arrêtée (par nécessité).

Mais j’ai choisi de laisser le logiciel libre dans l’espoir que d’autres personnes se plongent dedans et aident à faire avancer les choses en donnant de leur temps et de leur énergie.

Malheureusement, ça ne s’est pas produit. Une personne plutôt sympa a filé un coup de main en créant des packages pour plusieurs distributions Linux. Mais c’est tout. En fait, personne n’a exprimé le moindre intérêt à coder activement sur l’un de ces projets.

Et maintenant, les téléchargements ont également chuté. De manière significative. Regardons quelques graphiques sur l’évolution des statistiques.

Ce chiffre représente le nombre total de téléchargements pour tous mes logiciels (jeux, outils de développement, tout). Ce qu’il faut retenir :

1. Quand le logiciel est propriétaire (et vendu comme shareware), les téléchargements sont bons.
2. Quand le logiciel est open source (et disponible gratuitement), les téléchargements chutent à 1/30e de ce qu’ils étaient pour du logiciel propriétaire.
3. Curieusement, les téléchargements des versions Linux sont les plus touchés (ils ont chuté à 1/50e de ce qu’ils étaient).

Le revenu mensuel a aussi pris un sacré coup. Voilà ce qu’on peut déduire de ces chiffres :

1. Lorsque le logiciel était propriétaire (et un shareware), les ventes étaient suffisantes pour financer le développement à temps plein.
2. Maintenant que le logiciel est open source, le financement (en grande partie par les dons) a chuté à, et je ne blague pas, à peine plus de 2 % des ventes moyennes par mois du logiciel propriétaire. 2. Pour. Cent.

Aujourd’hui, je peux clairement comprendre la raison de la chute des revenus. Le logiciel est disponible gratuitement – supprimant ainsi l’incitation à dépenser de l’argent. Ce que je ne comprends pas, c’est la chute significative des téléchargements. Peut-être y a-t-il un aspect psychologique en jeu.

Donc la question est, que puis-je faire ?

Si je laisse le logiciel en open source, comme c’est le cas actuellement, il va complètement stagner.

Je suppose que je pourrais essayer encore une autre méthode de financement open source… mais cela me semble un peu être une cause perdue, pour être honnête. J’aime l’open source. Vraiment. Je pourrais y passer toute la nuit. Mais il n’y a pas vraiment beaucoup d’histoires où de petits développeurs indépendants arrivent à vivre de l’open source sans avoir à intégrer une entreprise beaucoup plus grande (qui est souvent financée par la vente de logiciels propriétaires ou par des contrats de maintenance/support utilisateurs – ce qui n’a aucun sens pour le logiciel que je développe).

Je pourrais toujours revenir à une licence propriétaire pour les futures versions du logiciel. Cela permettrait au moins d’avoir les fonds nécessaires pour financer du développement concret – ce financement pourrait être utilisé pour payer des gens pour travailler dessus (à temps plein ou à temps partiel). Mais dans ce cas… ce ne serait pas de l’open source.

C’est un problème difficile. Un problème pour lequel je ne trouve pas de solution évidente.

L’avantage pour moi est qu’aujourd’hui je ne dépends pas des ventes du logiciel (ou des dons) pour vivre (mes revenus proviennent de l’écriture). Ce qui m’enlève une bonne part de stress. Néanmoins, je détesterais voir ce logiciel qui, quand il était propriétaire, était utilisé par des dizaines de milliers de personnes, disparaître. J’ai fait ce logiciel parce que personnellement, j’en avais besoin. Et ça me dépiterait de le voir mourir.

Alors… que faire ? Que feriez-vous pour être sûr que ce genre de logiciel indépendant continue d’être régulièrement mis à jour? Si vous avez des idées, je suis tout ouïe.

Crédit photo : Retis (Creative Commons By)

Y aurait-il moins de 5000 développeurs libres sur tout le continent africain (4527 pour être plus précis) ?

C’est ce qu’on peut lire sur cette intéressante carte interactive intitulée GitHub Africa Users. Leur auteurs (non africains) ont en effet collecté, en mars dernier, les données des utilisateurs de la plateforme qui avaient renseigné leur localisation (et uniquement ceux-ci) en nous présentant cela à l’aide de MapBox.

A partir de là un certain nombre de questions se posent pour nuancer ce chiffre :

• Est-ce les utilisateurs africains de GitHub se localisent moins que les autres ?
• Est-ce qu’un utilisateur de GitHub est nécessairement un développeur qui fait du libre ?
• Est-ce que les développeurs libres africains utilisent GitHub ?
• Est-ce que les développeurs libres africains voudraient utiliser GitHub mais en sont empêchés à cause de la faiblesse de leur connexion à Internet ?
• Combien y a-t-il de développeurs non libres en Afrique ?

Il n’empêche que cela reste tout de même inquiétant.

Qu’en pensez-vous ?

Le témoignage d’un développeur qui considère qu’à partir du moment où vous vivez bien il est moralement important de rendre à la communauté un peu de ce qu’elle vous a donnée.

L’open source, une responsabilité civique

Open Source as a Civic Duty

Jeremy Kahn – 13 juillet 2013 – Blog personnel
(Traduction : Asta, r0u, aKa, GregR, regularuser, Tentate, dig, Fol, Maijin + anonymes)

On me demande parfois la raison pour laquelle je passe autant de mon temps libre à écrire des logiciels et à les mettre à disposition librement et gratuitement. Il y a un certain nombre de raisons à cela. J’aime construire des choses et cela me sert de prétexte pour pratiquer et m’améliorer, mais une de mes principales motivations est que je vois dans les contributions open source un devoir civique, une obligation morale envers le reste du monde.

Étant donné que je suis un programmeur actif travaillant dans la Silicon Valley, et qu’on me considère généralement comme pas trop incompétent, vous vous doutez bien que je ne me soucie pas trop de comment j’arriverai à payer mon prochain repas. Je ne suis pas « riche », mais j’ai un style de vie plutôt confortable, et c’est tout ce que j’ai toujours voulu. Après tout, un programmeur a-t-il besoin d’autre chose qu’un ordinateur portable et d’une tasse de café pour être heureux ? Ceci étant, je n’ai pas à m’inquiéter de savoir si je vais avoir, ou non, un endroit pour vivre et à manger le mois prochain, je suis parmi les gens les plus heureux du monde. Et si vous avez toute la technologie nécessaire à la lecture de cet article, vous l’êtes sûrement tout autant.

La morale est un sujet sensible qui dépend des individus et de leurs cultures, et ce texte ne suggère pas que ma conception de la moralité soit nécessairement correcte. Cependant, je pense que les gens assez chanceux pour parvenir à vivre par leurs propres moyens ont une obligation de rendre quelque chose à leur communauté. Je crois qu’un certain niveau de sacrifice personnel et de devoir civique est nécessaire afin de bâtir et de maintenir un collectif au sein duquel nous souhaitons tous vivre. Cela peut prendre plusieurs formes, des dons, du travail bénévole ou, dans mon cas, la conception et le développement de logiciels libres. La manière dont vous tentez de contribuer à la communauté n’est pas vraiment importante, ce qui compte est que vous le fassiez.

Bien sûr, je ne code pas des logiciels qui permettront de fournir de l’eau à des pays pauvres en Afrique ou à soigner la malaria. Je me focalise plutôt sur des outils d’animations pour le Web et d’autres utilitaires pour les interfaces utilisateurs. Cependant, je travaille dessus afin que d’autres n’aient pas à le faire. Mon but à mon niveau est de faire gagner du temps à d’autres personnes, et leur permettre de résoudre des problèmes qui n’ont pas encore de solutions. Pour prendre un exemple significatif, considérons le projet GNU. Au final, GNU a permis de faire gagner à l’humanité des siècles en temps de travail. De nos jours, on ne passe plus beaucoup de temps à développer des systèmes d’exploitation et autres outils basiques, car c’est une tâche quasiment résolue. À la place nous utilisons des outils GNU que d’autres ont laborieusement développé, nous permettant alors ainsi de poursuivre et nous concentrer vers d’autres défis comme la modélisation statistique ou la lutte contre le SIDA. Si vous avez des doutes sur l’intérêt du logiciel libre, il vous suffit de regarder le projet GNU.

L’altruisme n’est malheureusement pas très répandu dans la Silicon Valley. Au mieux, les grandes firmes ont une division s’occupant de responsabilité sociale et environnementale, et les plus petites organisent une collecte de fonds à but solidaire de temps en temps. Mais il semble qu’une grande partie des entreprises technologiques de la Silicon Valley se concentrent sur une vision autocentrée et des problèmes « de niche », spécifiques à leur fondateur et à ses amis. Je ne veux pas d’une culture dans laquelle les seuls problèmes résolus sont ceux que les techniciens rencontrent. Je pense que l’écriture de logiciels libres sur mon temps personnel est un petit pas dans la bonne direction, même indirect. Mon rêve est qu’un jour, un outil libre que j’aurai écrit soit utilisé à des fins vraiment utiles. N’importe qui peut accomplir cela, ça ne requiert que peu de temps ou d’argent — seulement de prendre un peu de recul.

Crédit photo : David Orban (Creative Commons By)

Bonjour Céline, peux-tu nous expliquer comment tu en es venue à utiliser le système d’exploitation Free BSD ? Tu l’as attrapé tout d’un coup ou bien c’est l’effet d’une lente incubation ?

Je suis arrivée sur FreeBSD un peu par hasard. En fait, quand j’ai décidé de passer à Linux (en 1999, je sais ça remonte), j’ai testé plusieurs distributions dont La Lycoris Desktop LX, Debian et Ubuntu 6.06. J’ai utilisé Ubuntu et Debian en parallèle pendant énormément de temps jusqu’à ce que je décide de tester OpenBSD (réputé pour sa sécurité) pour l’utiliser sur un serveur de développement. À cause de l’absence de Java et comme je suis développeuse C/Java, j’ai éprouvé de la frustration de ne pas pouvoir tout faire sur ma machine nouvellement acquise. J’ai donc cherché une alternative la plus proche possible : FreeBSD s’est avéré être mon choix final. Une installation sans fioriture, simple et qui n’installait que ce dont j’avais besoin sur mon serveur (seul ArchLinux m’avait satisfaite au même degré jusque-là), je ne demandais rien de plus. Donc pour en revenir à l’usage de ce système d’exploitation, c’est bien l’effet d’une incubation d’une bonne dizaine d’années.

Bon c’est bien joli FreeBSD mais son installation et son usage réclament un certain niveau de compétence technique, non ? est-ce que tu le conseillerais vraiment à des usagers qui comme moi choisissent Ubuntu parce que c’est la distribution la plus abordable ? Il n’existe pas une version plus simple avec une interface graphique qui simplifie la vie ?

C’est vrai que quand on arrive sur FreeBSD, il ne faut pas avoir peur de la console. C’est pareil pour certaines distributions Linux, il faut s’armer de patience, lire la documentation (très bien réalisée) et parfois galérer dans les pages man. L’installation ne se fait pas en quelques clics, une fois l’installation finie, on ne dispose vraiment que des outils de base. Mais c’est ce que j’adore sur OpenBSD et FreeBSD (bon et aussi ArchLinux), c’est que je sais ce qu’il y a sur mon poste, ce qui démarre quand j’allume mon ordinateur, alors qu’au fil de temps je trouve que le fonctionnement des distributions Linux, pour se rendre facile d’accès au grand public, devient de plus en plus opaque. Il suffit de taper un petit ps aux sur Ubuntu pour voir tout ce qui peut tourner (des fois pour rien)… Pour ce qui est d’une version plus facile d’accès, j’ai entendu parler de PC-BSD qui a justement pour objectif de rendre FreeBSD accessible à tous : installation aisée en quelques clics, KDE est fourni en bureau par défaut… Je testerai peut-être un jour sur un autre PC ou avec VirtualBox 😉

Tu en fais un usage dans ta vie professionnelle ou bien c’est choix de passionnée pour ton usage personnel ?

Dans ma vie professionnelle, je travaille sur RedHat, Debian et Solaris, hélas pas encore de FreeBSD en vue, mais ça viendra ! 😉

Merci, je te laisse le soin de présenter l’article…

Il y a de cela 20 ans, le 19 juin 1993, David Greenman, Jordan Hubbard et Rod Grimes annonçaient la création d’un nouveau logiciel basé sur le code source de BSD (Berkeley Software Distribution, voyez cette page Wikipédia) : FreeBSD était né. Peu connu du grand public, ce système d’exploitation est pourtant utilisé partout : en tant que solution d’hébergement pour des sociétés telles que Yahoo!, ou comme solution de sécurité pour la mise en place de firewall. Deux systèmes d’exploitation reposent sur son noyau : FreeNAS et MacOS. FreeNAS est une solution libre grand public pour héberger du contenu à travers un réseau, tandis que MacOS est le système d’exploitation propriétaire que nous connaissons tous au moins de nom. Pour fêter ce cap des 20 ans, voici un petit article qui vous fera découvrir une partie du monde BSD.

— Céline

FreeBSD fête ses 20 ans et met toute sa puissance à votre service.

Traduction Framalang : lamessen, Céline, Garburst, Asta, audionuma d’après l’article original de Lawrence Latif

Le système d’exploitation open source FreeBSD vient de fêter son vingtième anniversaire.

FreeBSD a vu au fil des années sa popularité auprès du grand public diminuer alors que le noyau Linux et les nombreuses distributions qui l’utilisent ont connu un développement rapide. Cependant, FreeBSD a eu 20 ans le 19 juin et continue de faire fonctionner des infrastructures réseaux vitales.

FreeBSD a introduit de nombreuses innovations qui ont été adoptées par certaines distributions Linux. Par exemple, la collection de ports FreeBSD, qui compile des logiciels à partir du code source plutôt qu’à partir de binaires pré-assemblés, a été copiée par Gentoo Linux pour son système Portage.

FreeBSD est également connu pour avoir l’une des piles réseau les plus robustes. Il est fréquemment utilisé par les chercheurs et les industriels comme base pour la simulation et les systèmes de production. Monowall et Pfsense sont des distributions populaires basées sur FreeBSD destinées à être utilisées sur des périphériques réseaux qui embarquent tous les types de fonctionnalités, des firewalls aux réseaux privés virtuels en passant par les liaisons ADSL, sur un système facile à utiliser.

Alors que FreeBSD n’est pas la seule variante libre et largement distribuée de BSD Unix, il est différent de OpenBSD qui essaie d’être le système d’exploitation le plus sécurisé et de NetBSD qui tente de fonctionner sur n’importe quel appareil possédant un microprocesseur. Il est devenu la référence pour une utilisation générale de BSD.

Cependant, FreeBSD n’est pas que réseau et démons, puisque durant ces dernières années les distributions de bureau BSD Unix reposant sur FreeBSD sont apparues, notamment avec PC-BSD qui est la plus célèbre.

FreeBSD, grâce à ses performances et sa licence, est utilisé par des sociétés commerciales comme Citrix, Netapp et Juniper.

Ces dernières années, même la communauté Linux a commencé à reprendre des parties de FreeBSD, avec Debian qui propose une version de sa distribution utilisant le kernel FreeBSD. Malgré la blague récurrente sur le fait que BSD soit mort ou non, étant donné son support à l’industrie, il est probable qu’il continuera son combat dans les décennies à venir.

Qu’il s’agisse de son code ou de son utilisation, la faiblesse de la documentation d’un logiciel libre est souvent montrée du doigt.

Voici, selon Andy Lester, 13 défauts ou lacunes communément rencontrés, qui sont autant d’écueils que l’on peut contourner avec un minimum d’efforts aujourd’hui pour gagner demain un temps précieux.

13 choses que les gens détestent sur vos documentations open source

13 Things People Hate about Your Open Source Docs

Andy Lester – 10 janvier 2013 – SmartBear Blog
(Traduction : Lamessen, calou, Shanx, sinma, Asta + anonymes)

La plupart des développeurs open source aiment penser à la qualité du logiciel qu’ils développent, mais la qualité de la documentation est souvent laissée de côté. Il est rare de voir vanter la documentation d’un projet, et pourtant elle a un impact direct sur sa réussite. Sans une bonne documentation, les utilisateurs n’utiliseront pas votre projet, ou ils n’y prendront pas de plaisir. Les utilisateurs comblés sont ceux qui diffusent des infos à propos de votre projet – ce qu’ils ne font qu’après avoir compris comment il fonctionne. Et ils apprennent cela à partir de la documentation du projet.

Malgré tout, de trop nombreux projets ont une documentation décevante. Et cela peut être décevant de plusieurs manières.

Les exemples que je donne ci-dessous sont purement arbitraires, je ne veux pas cibler un projet en particulier. Ce sont seulement ceux que j’ai utilisés récemment, cela ne veut pas dire qu’ils représentent les pires atrocités. Chaque projet a commis au moins quelques-uns de ces péchés. Que vous soyez utilisateur ou développeur, à vous d’évaluer à quel point votre logiciel préféré est ou non coupable, et comment vous pouvez aider à y remédier le cas échéant.

1. Le manque d’une bonne introduction ou d’un README/LISEZ-MOI

Le README/LISEZ-MOI est la première impression que les utilisateurs potentiels ont de votre projet. Si le projet est sur GitHub, le README/LISEZ-MOI est automatiquement affiché sur la page d’accueil du projet. Si vous l’avez mal rédigé, ils peuvent ne jamais revenir.

Vous voulez capter l’attention du lecteur et l’encourager à continuer la découverte de votre projet ? Le README/LISEZ-MOI devrait alors au moins expliquer :

• ce que le projet fait
• pour qui il est fait
• sur quel matériel ou plateforme il tourne
• toutes les dépendances majeures, comme « Requiert Python 2.6 et libxml »
• comment l’installer, ou un accompagnement de chaque étape à la suivante.

Tout cela doit pouvoir être compris par quelqu’un qui n’a jamais entendu parler de votre projet, et peut-être même jamais imaginé un projet pouvant s’en rapprocher. Si le projet possède un module calculant la distance de Levenshtein, ne partez pas du principe que n’importe qui lisant votre README/LISEZ-MOI sait ce que c’est. Expliquez que la distance de Levenshtein est utilisée pour comparer deux chaînes de caractères, et ajoutez quelques renvois vers des explications plus poussées pour celui qui aimerait approfondir le sujet.

Ne décrivez pas votre projet par rapport à un autre projet, comme « NumberDoodle est comme BongoCalc, mais meilleur ! » Ça n’est d’aucune aide pour quelqu’un qui n’a jamais entendu parlé de BongoCalc.

2. La documentation non disponible en ligne

Bien que je n’ai pas lu d’études à ce sujet, je serais prêt à parier que 90% des recherches de documentation sont faites avec Google et un navigateur sur Internet. La documentation de votre projet doit être en ligne, et disponible. Partant de là, il serait embarrassant que la documentation de mon propre projet, ack, ne soit pas disponible à l’endroit où la majorité des gens vont la chercher. Mon hypothèse est basée sur ma propre expérience, à savoir que si je veux connaître le fonctionnement d’un outil en ligne de commande, je vais vérifier sa page man.

Comment je m’en suis aperçu ? Les utilisateurs m’écrivaient pour me poser des questions dont les réponses se trouvaient dans la FAQ. Ce qui m’a ennuyé : ils ne lisaient pas ma FAQ. Il se trouve qu’ils avaient cherché sur le site internet, mais je n’avais pas mis la FAQ à cet endroit. C’est une erreur facile à faire. Je suis proche du projet et je n’ai jamais eu besoin d’utiliser moi-même la FAQ, je n’avais donc pas remarqué qu’elle n’était pas présente en ligne. Beaucoup de problèmes sont dus à ce piège : les auteurs ne se mettent pas à la place des utilisateurs.

3. La documentation disponible uniquement en ligne

Le revers de ce problème est d’avoir la documentation disponible uniquement en ligne. Certains projets ne distribuent pas la documentation avec les livrables du projet, ou incluent une version médiocre de la documentation.

Le moteur de recherche Solr, par exemple, a un excellent wiki qui sert à la documentation du projet. Malheureusement, la documentation liée au téléchargement comporte 2200 pages de Javadoc d’API auto-générées. Au final, la seule documentation pour l’utilisateur est une unique page de tutoriel.

Le langage PHP n’est distribué avec aucune documentation. Si vous voulez la documentation, vous devez aller sur une page séparée pour les obtenir. Pire, seule la documentation du cœur est disponible au téléchargement, sans les annotations utiles des utilisateurs (voir « Ne pas accepter les remarques des utilisateurs » plus bas), et ce n’est pas le même format facile à parcourir que celui qui est disponible en ligne.

Les projets open source ne peuvent pas supposer que les utilisateurs ont accès à Internet quand ils ont besoin de la documentation. Le mode avion existe toujours. De toute façon, vous ne souhaitez pas que l’utilisateur dépende uniquement du fait que votre site web est disponible ou non. Au moins à deux reprises durant les derniers mois, le wiki de Solr était indisponible au beau milieu de ma journée de travail alors que je recherchais des informations sur un problème de configuration épineux.

Un projet qui fait les choses bien est Perl et son dépôt de module CPAN. La documentation pour chaque module est disponible soit à search.cpan.org ou metacpan.org dans un format hypertexte facile à lire. Pour la consultation hors-ligne, la documentation de chaque module est intégrée dans le code lui-même, et quand le module est installé sur le système d’un utilisateur, la documentation locale est créée sous forme de pages man. Les utilisateurs peuvent aussi utiliser « perldoc Module::Name » pour obtenir la documentation depuis le shell. En ligne ou hors-ligne : c’est votre choix.

4. La documentation non installée avec le paquet

Ce problème est généralement une erreur des paquageurs, pas des auteurs du projet. Par exemple, sur Ubuntu Linux, la documentation du langage Perl est séparée, ce sont des paquets optionnels pour le langage lui-même. L’utilisateur doit savoir qu’il doit explicitement installer la documentation de la même façon que le langage principal ou il n’y aura pas accès quand il en aura besoin. Ce compromis de quelques mégabites d’espace disque au détriment de la documentation à portée de main de l’utilisateur dessert tout le monde.

5. Le manque de captures d’écran

Il n’y a pas de meilleur moyen d’obtenir l’attention potentielle d’un utilisateur, ou d’illustrer un usage correct, qu’avec des captures d’écran judicieuses. Une image vaut mieux qu’un long discours, c’est encore plus important sur Internet parce que vous ne pouvez obtenir d’un lecteur de lire plus de quelques centaines de mots en tout.

Les captures d’écran accompagnant le texte sont inestimables pour guider l’utilisateur voulant faire les choses au mieux. Une capture d’écran lui permet de comparer visuellement ses résultats à ceux de la documentation et va le rassurer d’avoir exécutée la tâche correctement ou l’aidera à trouver facilement ce qui ne va pas.

Il est de plus en plus commun de trouver des vidéos sur le site internet d’un projet pour en donner un aperçu, et c’est génial. Tout autant que le fait d’avoir une vidéo pour chaque étape d’un processus complexe. Le projet Plone, par exemple, a un site entier dédié aux tutoriels vidéos. Cependant, les vidéos ne peuvent pas remplacer les captures d’écran. Un utilisateur veut voir rapidement l’allure des captures d’écran sans s’arrêter devant une vidéo. Les vidéos n’apparaissent également pas dans une recherche Google Image, à l’inverse des captures d’écran.

6. Le manque d’exemples réalistes

Pour les projets basés sur du code, l’analogue des captures d’écran sont de bons et solides exemples du code en action. Ces exemples ne devraient pas être abstraits, mais directement issus du monde réel. Ne créez pas d’exemples bateaux plein de « nom de la démo ici » et lorem ipsum. Prenez le temps de créer des exemples signifiants avec une histoire d’utilisateur qui représente la façon dont votre logiciel résout un problème.

Il y a de bonnes raisons de vous embêter avec des problèmes de maths en classe. Ils permettent d’appliquer ce que vous avez appris.

Disons que j’ai écrit un module d’un robot Web, et que j’explique la méthode follow_link. Je pourrais montrer la définition de la méthode ainsi :

$mech->follow_link( text_regex => $regex_object, n => $link_index );

Mais admirez à quel point cela devient évident en ajoutant de la réalité dans l’exemple.

# Suit le 2e lien où la chaîne de caractères « download » apparait
$mech->follow_link( text_regex => qr/download/, n => 2 );

Les noms des variables $regex_object et $link_index sont maintenant compréhensibles par le lecteur.

Bien entendu, vos exemples ne doivent pas être aussi brefs. Comme Rich Bowen du projet Apache le souligne, « Un exemple correct, fonctionnel, testé et commenté l’emporte sur une page de prose, à chaque fois. »

Montrez autant que possible. L’espace n’est pas cher. Créez une section dédiée aux exemples dans la documentation, ou même un livre de cuisine. Demandez aux utilisateurs d’envoyer du code qui fonctionne, et publiez leurs meilleurs exemples.

7. Liens et références inadéquats

Vous avez les hyperliens. Utilisez-les.

Ne pensez pas, parce que quelque chose est expliquée dans une certaine partie de la documentation, que le lecteur a déjà lu cette partie, ou bien qu’il sait où elle se trouve. Ne vous contentez pas de signaler que cette partie du code manipule des objets frobbitz. Expliquez brièvement lors du premier usage de ce terme ce qu’est un objet frobbitz, ou donnez le lien vers la section du manuel l’expliquant. Encore mieux, faites les deux !

8. Oublier les nouveaux utilisateurs

Il arrive trop souvent que l’écriture de la documentation soit rédigée à partir du point de vue de son auteur, alors que es nouveaux utilisateurs ont besoin de documentation d’introduction pour les aider.

L’introduction devrait être une page séparée de la documentation, idéalement avec des exemples qui permettent à l’utilisateur de réussir quelques manipulations avec le logiciel. Pensez à l’excitation que vous ressentez quand vous commencez à jouer avec un nouveau logiciel et qu’il vous permet de faire quelque chose de cool. Faites que ça arrive aux nouveaux utilisateurs également.

Par exemple, un package graphique pourrait présenter une série de captures d’écran qui montrent comment ajouter des données dans un fichier, comment faire intervenir le grapheur, et ensuite montrer les graphes obtenus. Une bibliothèque de codes pourrait montrer quelques exemples d’appels à la bibliothèque, et montrer le résultat obtenu. Pensez simplicité. Offrez une victoire facile. Le texte devrait introduire les termes aux endroits appropriés, avec des liens vers une documentation plus détaillée sur le long terme.

Un document de démarrage séparé donne à l’utilisateur une compréhension rapide du logiciel. Il garde aussi les explications d’introduction en dehors de la partie principale de votre documentation.

9. Ne pas écouter les utilisateurs

Les développeurs doivent écouter les utilisateurs de la documentation. La chose évidente est d’écouter les suggestions et requêtes des personne qui utilisent activement votre logiciel. Quand un utilisateur prend le temps d’écrire un mail ou de poster quelque chose comme « ça aurait pu m’aider à mieux installer le programme s’il y avait eu une explication ou des liens au sujet des pilotes de la base de données », prenez ce message au sérieux. Pour chaque utilisateur vous envoyant un mail pour un problème, vous devez vous attendre à ce que dix utilisateurs silencieux aient le même problème.

Il est important d’écouter les problèmes des utilisateurs et d’en chercher les causes. S’ils ont souvent des problèmes pour effectuer des mises à jour groupées de bases de données, la première chose à faire est d’ajouter une question à la FAQ (vous avez bien une FAQ, n’est-ce pas ?) qui traite de ces questions-là. Cependant, la question peut aussi indiquer que la section traitant des mises à jour de base de données n’est pas assez claire. Ou peut-être qu’il n’y a pas de référence à cette section depuis la vue d’ensemble introductive du document, avec pour conséquence que vos utilisateurs ne pensent jamais à lire le reste du manuel.

En plus d’aider plus de gens à découvrir à quel point votre projet est utile, ça diminuera aussi la frustration de la communauté déjà existante. Si votre liste de diffusion, forum ou canal IRC est remplie de personnes qui posent toutes les mêmes questions idiotes (ou pas si idiotes) au point que tout le monde devient lassé d’y répondre, sachez reconnaître que ce sont des questions récurrents pour la FAQ, et mettre les réponses à un endroit facile à trouver aidera tout le monde à se concentrer sur des choses plus amusantes.

Gardez aussi un œil sur les questions des forums externes. Consultez les sites comme StackOverflow régulièrement, et placez une Google Alert sur votre nom de projet pour être maintenu au courant des discussions concernant votre projet sur Internet.

10. Ne pas accepter les entrées des utilisateurs

Si votre projet a une base d’utilisateur assez grande, il peut être judicieux d’incorporer les commentaires des utilisateurs directement dans la documentation. Le meilleur exemple que j’ai pu voir est celui donné par PHP. Chaque page de la documentation permet aux utilisateurs authentifiés d’ajouter des commentaires sur la page, aidant ainsi à clarifier certains points ou ajoutant des exemples qui ne sont pas dans la documentation principale. L’équipe PHP laisse aussi le choix au lecteur de lire la doc avec ou sans les commentaires des autres utilisateurs.

Aussi pratique cela soit-il, cela nécessite de la maintenance. Les commentaires doivent être éliminés de temps en temps pour éviter la prolifération. Par exemple, la page de la documentation PHP sur comment lancer PHP depuis la ligne de commande inclut 43 commentaires d’utilisateurs qui remontent à 2001. Les commentaires écrasent la documentation principale. Les commentaires devraient être archivés ou supprimés, tout en incluant les points les plus importants dans la documentation principale.

Un wiki est également une bonne approche. Cependant, si votre wiki ne permet pas à l’utilisateur de télécharger toutes les pages en une seule grosse archive (cs. point n°3 ci-dessus), alors vos utilisateurs sont à la merci de votre connexion internet et du serveur hébergeant le projet.

11. Impossibilité de voir ce que fait le logiciel sans l’installer

Au minimum, chaque projet de logiciel nécessite une liste de fonctionnalités et une page de captures d’écran pour permettre au potentiel utilisateur intéressé de savoir pourquoi il devrait l’essayer. Aidez l’utilisateur, comparant les différents paquets à utiliser, à voir pourquoi cela vaut la peine de prendre le temps de le télécharger et de l’installer.

Les images sont un bon moyen de faire cela. Votre projet devrait avoir une page « Captures d’écran » qui montre des exemples de l’outil en action (cf. point n°5 ci-dessus). Si votre projet se résume uniquement à du code, comme une librairie, alors il devrait y avoir une page d’exemples montrant ce code utilisant le projet.

12. S’appuyer sur la technologie pour votre rédaction

Trop souvent, les auteurs de logiciels utilisent des systèmes de documentation automatisés pour faire leur travail. Ce système automatisé rend les choses plus facile à maintenir, mais il ne supprime pas la nécessité d’un travail d’écriture humain.

Le pire des cas concerne le changelog, qui n’est rien de plus qu’un dump des messages de commit du système de gestion de version, mais sans un résumé qui l’explique. Un changelog devrait lister les nouvelles fonctionnalités, les problèmes résolus et les incompatibilités potentielles. Sa cible est l’utilisateur final. Un log de commit est pratique et simple à générer pour les personnes travaillant sur le projet, mais ce n’est pas ce dont l’utilisateur a besoin.

Jetez un œil à cette page de la documentation de Solarium, une interface PHP pour le moteur de recherche Solr. Tout d’abord, l’avertisemment prend la moitié supérieure de l’écran, ne donnant aucune information au lecteur. Ensuite, il n’y a vraiment rien de véritablement descriptif sur la page que la liste des noms de fonctions. Il n’y a aucune explication sur les différentes méthodes, ni de liens indiquant où trouver l’explication. Les pages générées automatiquement sont jolies, et elles pourraient ressembler à de la documentation, mais elles n’en sont pas.

13. Arrogance et hostilité vis-à-vis de l’utilisateur

L’attitude du type RTFM (Read The Freaking Manual) est mauvaise pour votre projet et votre documentation.

C’est le summum de l’arrogance que de croire que tous les problèmes qui ont trait au fait que quelqu’un ne sache pas utiliser votre logiciel sont de la faute de l’utilisateur.

Même s’il est probablement vrai que les utilisateurs peuvent trouver leurs réponses dans votre documentation mais ne le font pas, il est stupide de penser que c’est la faute de l’utilisateur. Peut-être votre documentation est-elle mal écrite, ou difficile à lire, ou présente mal à l’écran. Peut-être avez-vous besoin d’améliorer la section « Mise en route » (lien #8 ci-dessus) qui explique ce que le logiciel a pour but de faire. Peut-être que certaines parties d’information nécessitent d’être répétées à de multiples endroits de la documentation.

N’oubliez pas que les nouveaux utilisateurs de votre logiciel peuvent arriver sur votre projet sans rien n’en savoir. Votre documentation doit faire de son mieux pour s’assurer que cette ignorance soit facilement résolue.

Synthèse

Je suis sûr que vous avez déjà eu affaire à quelques-uns de ces problèmes listés ci-dessous, et peut-être que pour d’autres vous n’y avez pas pensé. Faites-nous connaître les problèmes que vous avez rencontrés dans les commentaires ci-dessous, sachant qu’il ne s’agit pas de pointer du doigt certains projets en particulier.

Surtout, j’espère que si vous reconnaissez un problème dans la documentation de vos projets, vous prendrez la peine d’améliorer la situation. Heureusement, améliorer la documentation est une manière idéale de faire participer les nouveaux arrivants dans votre projet. On me demande souvent : « Comment puis-je commencer dans l’open source », et je recommande des améliorations dans la documentation comme une bonne manière de commencer.

Faites-en sorte que ce soit aussi facile que possible, pour les novices comme les plus anciens, de savoir où il est nécessaire de travailler la documentation. Créez une liste des tâches, par exemple dans votre système de suivi des bogues, qui explique ce qui a besoin d’être amélioré. Soyez précis dans ce que sont vos besoins. Ne vous contentez pas de dire que vous avez besoin d’exemples, sans plus de précision. Créez des tâches spécifiques, comme « ajoutez un code d’exemple sur le fonctionnement de la tâche X », « ajouter une capture d’écran du générateur de rapports » ou « ajouter des informations de dépendances au fichier README/LISEZ-MOI ». Les contributeurs souhaitent aider mais trop souvent ils ne savent pas par où commencer.

La documentation n’est pas la partie la plus glamour d’un projet open source, et pour la plupart d’entre nous ce n’est pas amusant. Mais sans une bonne documentation, les utilisateurs ne sont pas servis comme ils pourraient l’être, et votre projet en souffrira sur le long terme.

Crédit photo : Rosalux Stiftung (Creative Commons By)

Vous connaissiez la suite bureautique libre Joeffice ?

Nous, non ! Et quand nous avons appris qu’elle avait été conçue en 30 jours par un développeur (qui plus est français), nous avons évidemment eu envie d’en savoir plus…

Bonjour Anthony, peux-tu te présenter succinctement ? Quel a été ton parcours de développeur ?

Bonjour, je m’appelle Anthony Goubard, j’ai 40 ans et j’habite à Amsterdam. J’ai commencé Java durant ma dernière année d’ingénieur avec la version 1.0 alpha puis j’ai fait du détachement sur la région parisienne. Il y a 14 ans je suis allé travailler pour une start-up aux Pays-Bas puis pour Wanadoo Pays-Bas et il y a 5 ans je me suis mis à mon compte.

Alors Joeffice c’est quoi exactement ? Comment et pourquoi est né le projet ?

Joeffice est une suite bureautique open source écrite en Java. L’idée m’est venue il y a environ 2 ans lorsque je me suis aperçu que c’était galère d’avoir 10 documents d’ouverts avec Microsoft Office ou Libre Office alors que ce n’est pas un problème d’avoir 30 documents ouverts dans Eclipse ou NetBeans.

Dans quel sens évoques-tu une version « online » et « offline » ?

Les logiciels Java peuvent être installés sur un ordinateur comme un logiciel classique ou bien être lancé en ligne dans le navigateur avec l’aide du plugin Java. C’est ce qu’on appelle le mode Applet. Il suffit donc d’aller à l’URL et le logiciel s’installe et se lance dans le navigateur automatiquement. J’ai donc décidé d’offrir les deux possibilités. La version « online » est soumise à un abonnement.

Pourquoi le choix Java ?

Java offre beaucoup d’avantages. Il est portable sur plusieurs OS, il est relativement facile à lire, beaucoup d’étudiants apprennent Java et il est très utilisé dans le monde de l’entreprise. Beaucoup de projets open source utilisent Java. Joeffice offre aux étudiants et développeurs Java la possibilité de travailler sur un projet assez visuel et utile.

Pourquoi le choix de la licence libre ?

L’union fait la force.Tous les développeurs Java que je connais se servent de temps en temps d’une suite bureautique. Avoir un projet bien mené par un grand groupe de contributeurs permettra à long terme de créer un bien meilleur logiciel qu’avec une petite équipe. En plus, beaucoup d’entreprises et de pays en voix de développement sont attirés par l’open source et mon but est de toucher le plus de personnes possible.. Le premier groupe d’utilisateurs pour Joeffice est donc l’entreprise. Dans ce cas la licence Apache 2.0 donne beaucoup de liberté, plus que GPL et LGPL. Cette licence est par exemple utilisée pour le framework Spring.

Comment se positionne Joeffice, aujourd’hui et demain, par rapport à des « monstres » comme Google Docs, Microsoft Office ou LibreOffice ?

Joeffice est moins complet que ces autres offices mais il a aussi des atouts que d’autres n’ont pas. Il est donc open source sous licence Apache. Il est développé entièrement en Java. Il peut s’installer « offline » ou « online ». Il est facilement portable. Il n’a pas une fenêtre par document mais un système d’onglet et d’amarrage ou les documents peuvent être l’un à côté de l’autre ou détachés en groupe. Les mises à jour et plugins, même si pour l’instant non utilisés, peuvent se faire en ligne. Toutes les librairies Java peuvent être facilement utilisées pour créer des actions spéciales, afin par exemple de remplir un document.

La légende dit que tu l’aurais codé tout seul en moins d’un mois ? La légende dit vrai ?

Je l’ai codé en 30 jours. Mais ce sont 30 jours non consécutifs. Pour chaque journée j’ai fait une vidéo que j’ai postée sur YouTube. Il a fallu que je sois efficace sur le code et pragmatique sur certains choix.

En France, on vient d’introduire cette année l’informatique comme discipline à part entière au lycée (pour le moment en option de Terminale S). Bonne ou mauvaise idée ?

Bien sûr, je trouve ça une bonne idée. Même en n’étant pas informaticien, les gens ont de plus en plus besoin de savoir développer. Par exemple un plug-in, une macro ou un site Web.

Joeffice se présente en version alpha. Que lui manque-t-il exactement pour une première version ?

Je me sers de la librairie open source Apache POI pour lire les documents malheureusement il manque encore certaines parties. Chaque partie du logiciel doit être améliorée pour avoir quelque chose de plus utilisable pour l’utilisateur final. Cette version alpha est plus destinée aux développeurs et aux entreprises qui ont des besoins spécifiques. Le but pour la version 1.0 est de s’approcher de ce que peut faire Google Docs.

Et comment vois-tu le futur du projet ? Un appel à lancer ?

Tous les développeurs qui veulent participer à ce projet ou à une des librairies dont Joeffice se sert sont les bienvenus. Le code se trouve sur BitBucket.

Lorsque la distribution GNU/Linux Ubuntu est sortie en 2004, son père fondateur Mark Shuttleworth a signalé lui-même le premier « bug » : Microsoft détient la majorité du marché (Microsoft has a majority market share).

Il s’agissait symboliquement, et avec humour, de montrer le cap à suivre en désignant le principal concurrent.

Aujourd’hui la donne a changé et Shuttleworth a décidé hier de marquer ce bug comme résolu (fix released), quand bien même cela ne signifie pas, loin de là, qu’Ubuntu ait gagné comme il s’en explique ci-dessous.

Remarque : Nous en profitons pour signaler que Framasoft sera présent en masse à l’Ubuntu Party de Paris, avec stand et 3 mini-conférences le samedi 1er juin.

Bug #1 : Microsoft détient la majorité du marché

Bug #1 (liberation) : Microsoft has a majority market share

Mark Shuttleworth – 30 mai 2013 – Launchpad Ubuntu
(Traduction : Penguin, Mowee, Cryptie, quack1, @zessx, Asta, misc, MFolschette, Samusz + anonymes)

Aujourd’hui, l’utilisation de l’informatique dans la vie de tous les jours est beaucoup plus importante qu’elle ne l’était en 2004 : les téléphones, tablettes et autres appareils nomades sont devenus une part non négligeable de notre vie numérique. D’un point de vue compétitif, cet édifiant marché est une bénédiction pour la concurrence. Avec notamment iOS et Android, qui tous deux représentent une part significative du marché (Voir Windows en dessous de iOS et Android réunis avec ce graphique.

Android n’est peut-être pas mon premier choix de (noyau) Linux, ni le vôtre, mais c’est sans aucun doute une plateforme open source qui offre des avantages pratiques et économiques aux utilisateurs, comme à l’industrie. Ainsi, nous avons d’un côté de la concurrence et de l’autre une bonne représentation de l‘open source dans l’informatique personnelle.

Même si nous n’avons joué qu’un petit rôle dans ce changement, je pense qu’il est important pour nous de reconnaître qu’il a eu lieu. Du point de vue d’Ubuntu, le bug est maintenant clos.

Évidemment, ce bug a aussi un aspect social. Pour beaucoup, il a fait office de déclaration d’intention. Mais il est préférable pour nous de nous concentrer sur l’excellence de notre propre travail, plutôt que considérer notre impact sur le produit des autres. Depuis les (nombreuses) années que ce bug est référencé, nous avons trouvé comment être excellents dans le cloud, et j’espère que nous trouverons aussi bientôt comment l’être sur les postes de travail des développeurs, et peut-être même sur toute la quantité d’appareils que les utilisateurs réguliers peuvent utiliser. Je préférerais désormais que nous trouvions un cri de ralliement qui célébrerait ces idées et leur management.

Il est important de remarquer que de nos jours, si vous êtes dans le domaine de l’informatique dématérialisée (NdT : cloud computing), l’équipe de service d’infrastructure (NdT : IaaS) de Microsoft est très compétente et travaille dur pour que Linux soit parfaitement supporté par Azure, ce qui rend le travail avec eux très plaisant. Si l’évolution du marché a peut-être joué un rôle dans tout ça, les circonstances ont changé et les institutions se sont adaptées. Nous nous devons donc de le faire aussi.

Cela dit, il est bon de prendre du recul et de visualiser combien tout cela a changé depuis 2004, et à quelle vitesse ! Avec Ubuntu, notre but est de proposer à tous une expérience utilisateur formidable, que ce soit pour les développeurs, pour la production en entreprise ou tout simplement l’utilisateur final. Et tout cela avec un large support de matériel. Nous évoluons dans un environnement dynamique qui ne cesse de changer d’année en année. C’est donc pour cela que nous devons sans arrêt nous remettre en question, que ce soit au niveau de notre façon de faire, nos pratiques, les outils que nous utilisons ainsi que les relations que nous entretenons en interne et en externe. Corriger ce problème n’en est qu’un tout petit exemple.