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

Traduction Framasoft : Miki, peupleLà, dabou, Asta, elquan, Goofy, Julius22, okram, lamessen, Jej, lerouge, SaSha_01, Lycoris, meumeul, vvision

Ne soyez pas timide

Máirín Duffy Strode

Máirín Duffy Strode utilise des logiciels libres et open source depuis le lycée et y contribue depuis huit ans. Elle contribue aux communautés Fedora et GNOME et a travaillé sur l’identité visuelle des interactions, l’image de marque ou l’iconographie de plusieurs applications libres et open source importantes telles que Spacewalk, Anaconda, virt-manager, SELinux et SSSD. Elle s’est également engagée dans des activités de sensibilisation en enseignant les techniques de design à des enfants à l’aide d’outils libres et open source tels que GIMP et Inkscape qu’elle défend ardemment. Elle est à la tête de l’équipe de conception graphique de Fedora et designer d’interaction senior chez Red Hat, Inc.

Je connaissais et utilisais des logiciels libres et open source bien avant de devenir contributrice. Ce n’est pas faute d’avoir essayé — il y a eu quelques faux départs auxquels je n’ai pas donné suite principalement parce que j’étais trop timide et que j’ai eu peur d’aller plus loin. Sur la base de ces tentatives avortées et de ce que m’ont rapporté d’autres designers qui se sont embarqués dans des projets libres et open source, j’ai cinq astuces à vous offrir si vous êtes un designer aspirant au statut de contributeur au logiciel libre et open source.

1. Sachez que l’on a besoin de vous et qu’on vous veut (très fort !)

Mon premier faux départ s’est produit alors que j’étais étudiante en première année d’informatique au Rensselaer Polytechnic Institute. Il y avait un projet particulier que j’utilisais beaucoup et auquel je voulais participer. Je ne connaissais personne au sein du projet (ni qui que ce soit investi dans le logiciel libre). J’ai donc fait une tentative à froid. Le site web du projet signalait que les contributeurs voulaient de l’aide et qu’ils avaient un canal IRC. J’y ai alors traîné pendant une semaine ou deux. Un jour, après une pause dans la conversation, j’ai osé élever la voix. J’ai dit que j’étais une étudiante en informatique intéressée par l’ergonomie et que j’adorerais participer.

On m’a répondu : « Dégage ! ». Qui plus est, on m’a fait comprendre que mon aide n’était ni nécessaire ni désirée.

Cela a retardé mon engagement de quelques années — il avait suffi de quelques mots un peu rudes sur IRC pour me dissuader de réessayer pendant près de cinq ans. Je ne découvris que bien plus tard que la personne qui m’avait plus ou moins expulsée du canal IRC de ce projet était en marge du projet, qu’elle avait un lourd passif de ce genre et que je n’avais vraiment rien fait de mal. Si seulement j’avais persévéré dans mes tentatives d’approche et conversé avec d’autres personnes, j’aurais pu commencer à ce moment-là.

Si vous souhaitez contribuer au logiciel libre et open source, je vous garantis qu’il y a un projet quelque part qui a vraiment besoin de votre aide, en particulier si vous êtes orienté design ! Faites-vous du design web ? De l’iconographie ? De l’ergonomie ? De l’habillage ? Des maquettes d’interface utilisateur ? J’ai parlé à de nombreux développeurs de logiciels libres et open source qui non seulement sont désespérément à la recherche d’aide dans ce domaine, mais qui en plus l’apprécieraient vraiment et vous vénéreraient pour l’avoir apportée.

Si vous rencontrez des résistances la première fois que vous essayez de participer dans un projet, apprenez de mon expérience et n’abandonnez pas tout de suite. Si, en définitive, le projet n’est pas fait pour vous, ne vous inquiétez pas et passez votre chemin. Il y a des chances pour que vous trouviez un projet que vous adorerez et qui vous adorera en retour.

2. Aidez le projet pour qu’il vous aide à aider les autres

Bien des projets libres et open source sont aujourd’hui dominés par les programmeurs et les ingénieurs. Et si certains ont la chance qu’une ou deux personnes créatives s’investissent, dans la plupart des projets, un designer, un artiste ou une autre présence créative représente un rêve souvent-caressé-mais-jamais-réalisé. En d’autres termes, même s’ils comprennent qu’ils ont besoin de vos compétences, ils peuvent ne pas savoir quelle sorte d’aide ils peuvent vous demander, quelle information ils doivent vous donner pour que vous puissiez être productif ni même les bases pour travailler avec vous efficacement.

Quand j’ai commencé à m’investir dans différents projets libres et open source, j’ai rencontré beaucoup de développeurs qui n’avaient jamais travaillé directement avec un designer auparavant. Au début, je me suis sentie un peu inutile. Je ne pouvais pas suivre toutes leurs conversations sur IRC parce qu’ils parlaient de leur cuisine interne et de détails techniques qui ne m’étaient pas familiers. Quand ils se sont donné la peine de me prêter attention, ils m’ont posé des questions comme « Quelle couleur dois-je mettre ici ? » ou « Quelle police dois-je utiliser ?  ». Ce que je voulais vraiment en tant que designer d’interactions, c’était d’être associée à la prise de décision lorsqu’on abordait les contraintes spécifiques du projet. Si un utilisateur voulait une fonctionnalité particulière, je voulais avoir mon mot à dire sur le design — mais je ne savais pas où ni quand ces décisions se prenaient et je me sentais exclue.

Le design couvre une gamme assez large de compétences : l’illustration, la typographie, la conception des interactions, la conception visuelle, la conception d’icônes, la conception graphique, la rédaction, etc. et il y a peu de chances qu’un seul concepteur les possède toutes. Il est alors compréhensible qu’un développeur ne soit pas sûr de ce qu’il peut vous demander. Ce n’est pas qu’ils essaient de vous faire obstacle — c’est seulement qu’ils ne savent pas dans quelle mesure vous avez besoin de vous investir ou le désirez.

Aidez-les à vous aider. Montrez-leur clairement le type de contributions que vous pouvez apporter en fournissant des exemples de contributions antérieures. Faites-leur comprendre vos besoins de sorte qu’ils comprennent mieux comment vous aider à vous engager dans leur projet. Par exemple, lorsque vous vous impliquez pour la première fois dans une initiative spécifique pour le projet, prenez le temps de présenter les grandes lignes de son processus de conception et postez cela dans la liste de développement principale afin que les autres contributeurs puissent vous accompagner. Si vous avez besoin d’idées sur des points particuliers, soulignez-les dans votre présentation. Si vous n’êtes pas certain de la façon dont certaines choses se produisent — comme le processus de développement d’une nouvelle fonctionnalité — entrez en contact avec quelqu’un en parallèle et demandez-lui de vous l’expliquer pas à pas. Si quelqu’un vous demande de faire quelque chose au-delà de vos capacités techniques — travailler sur de la gestion de versions, par exemple — et que vous n’êtes pas à l’aise avec ça, dites-le.

Communiquer sur votre processus et vos besoins vous évitera de jouer aux devinettes dans le projet et ses membres seront au contraire capables d’utiliser au mieux vos talents.

3. Posez des questions, beaucoup de questions ; il n’y a pas de question idiote

Nous avons parfois remarqué chez Fedora que, lorsque de nouveaux designers arrivaient à bord, ils avaient peur de poser des questions techniques, par crainte de paraître stupides.

Ce qu’on ne vous dit pas, c’est que les développeurs peuvent être tellement spécialisés qu’il y a beaucoup de détails techniques qui sortent de leur domaine de compétence et qu’ils ne comprennent pas non plus — cela se produit même au sein du même projet. La différence, c’est qu’ils n’ont pas peur de demander — donc vous ne devriez pas avoir peur non plus ! Dans mon travail de design des interactions, par exemple, j’ai dû contacter de nombreuses personnes du même projet pour comprendre comment un processus se déroulait dans leur logiciel, car ce dernier comportait plusieurs sous-systèmes et tous les participants du projet ne comprenaient pas forcément comment chaque sous-système fonctionnait.

Si vous ne savez pas sur quoi travailler, que vous ne savez pas par quoi commencer ou que vous ne comprenez pas pourquoi ce que quelqu’un a dit sur le chat est si drôle — demandez. Vous avez des chances que quelqu’un vous réponde qu’il ne sait pas non plus et peu de risques de passer pour stupide. Dans la plupart des cas, vous allez apprendre quelque chose de nouveau qui vous aidera à devenir un meilleur contributeur. Il peut être particulièrement efficace de chercher un tuteur — certains projets ont même un programme de tutorat — et de lui demander s’il veut bien être votre référent quand vous avez des questions.

4. Partagez et partagez souvent, même si ce n’est pas encore prêt, surtout si ce n’est pas encore prêt

Nous avons aussi remarqué que de nouveaux designers pour Fedora et d’autres projets libres et open source sont un peu timides lorsqu’il est question de montrer leur travail. Je comprends qu’on ne veuille pas ruiner sa réputation en publiant quelque chose qui n’est pas ce qu’on peut faire de mieux ni même fini ; mais une grande partie du travail sur des projets libres et open source est de partager souvent et ouvertement.

Plus vous aurez avancé sur un élément avant de le partager, plus il sera difficile à d’autres de vous apporter un retour utilisable, de se lancer et de s’investir. Il est aussi plus difficile pour autrui de collaborer à votre travail et d’avoir un sentiment d’appartenance au projet, de le soutenir et de le pousser jusqu’à l’implémentation. Dans certains projets libres et open source, ne pas être communicatif avec vos ébauches, compositions et idées est même considéré comme offensant !

Publiez vos idées, maquettes ou compositions sur le Web plutôt que par courriel, afin qu’il soit plus aisé pour les autres collaborateurs de faire référence à votre contribution en faisant un copier-coller de l’URL — c’est particulièrement pratique au cours d’une discussion. Plus vos éléments de design seront faciles à trouver, plus il est probable qu’ils seront utilisés.

Essayez ce conseil et gardez l’esprit ouvert. Partagez votre travail tôt et souvent. Rendez disponibles vos fichiers sources. Vous serez peut-être agréablement surpris par ce qui va se passer !

5. Soyez aussi visible que possible au sein de la communauté du projet

Un outil qui — de manière totalement involontaire — a fini par m’aider énormément à démarrer en tant que contributeur de logiciels libres et open source a été mon blog. J’avais commencé à entretenir un blog, simplement pour moi, à l’image d’un portfolio grossier des choses sur lesquelles j’avais travaillé par le passé. Mon blog est un énorme atout pour moi, parce que :

• En tant qu’enregistrement de l’historique des décisions de projet, il représente un moyen pratique pour rechercher d’anciennes décisions de design — comprendre pourquoi nous avons décidé de laisser tomber tel ou tel visuel à nouveau ou pourquoi une approche particulière, précédemment essayée, n’a pas fonctionné, par exemple ;
• En tant que dispositif de communication, il aide les autres contributeurs associés à votre projet et même les utilisateurs à être au courant des travaux en cours et des changements à venir pour le projet. De nombreuses fois, j’ai omis quelque chose d’essentiel dans un design et ces personnes ont très rapidement posté un commentaire pour m’en informer !
• Il m’a aidé à construire ma réputation en tant que designer de logiciels libres et open source, ce qui m’a aidé à gagner la confiance des autres envers mes choix de design avec le temps.

Vous bloguez ? Trouvez quels agrégateurs de blogs lisent les membres du projet auquel vous participez et demandez à ce que votre blog y soit ajouté (il y a en général un lien pour cela dans la barre latérale). Par exemple, l’agrégateur de blogs que vous devrez rejoindre pour faire partie de la communauté Fedora se nomme Planet Fedora. Écrivez un premier billet pour vous présenter aux autres et leur faire savoir ce que vous aimez une fois que vous y aurez été ajouté — des informations du genre de celles listées dans la première astuce.

Le projet aura certainement une liste de diffusion ou un forum où les discussions ont lieu. Rejoignez-les et présentez-vous là aussi. Quand vous apportez une contribution au projet — peu importe qu’elle soit petite ou loin d’être aboutie — postez des billets sur ce que vous faites, téléchargez-le vers le wiki du projet, tweetez à ce sujet et envoyez des liens aux membres importants de la communauté via IRC afin d’avoir leur retour.

Rendez votre travail visible et les gens commenceront à vous associer à votre travail et à vous proposer des projets sympas ou d’autres opportunités, simplement grâce à ça. C’est tout ce que j’aurais aimé savoir quand j’ai essayé de m’investir pour la première fois dans le logiciel libre et open source comme designer. Si vous ne deviez retenir qu’un message de tout cela, c’est que vous ne devriez pas être timide — faites-vous entendre haut et fort, faites connaître vos besoins, faites savoir aux autres quels sont vos capacités et ils vous aideront à les utiliser pour que le logiciel libre envoie du lourd.

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

Traduction Framalang : Floxy, ga3lig, goofy, Astalaseven, Slystone, okram, KoS, Lycoris, 4nti7rust, peupleLa, Luc Didry, + Julius22

Même en multipliant les regards, les bogues ne sautent pas aux yeux.

Ara Pulido

Ara Pulido est ingénieure d’essais pour Canonical, d’abord comme membre de l’équipe assurance qualité d’Ubuntu (QA team), et maintenant dans le cadre de l’équipe de certification du matériel. Même si elle a commencé sa carrière en tant que développeuse, elle a vite découvert que ce qu’elle aimait vraiment, c’était tester les logiciels. Elle est très intéressée par les nouvelles techniques d’analyse et tente d’utiliser son savoir-faire pour améliorer Ubuntu.

Les tests maison ne suffisent pas

Je me suis impliquée dans le logiciel libre dès le début de mes études à l’Université de Grenade. Là-bas, avec des amis, nous avons fondé un groupe local d’utilisateurs de Linux et organisé plusieurs actions pour promouvoir le logiciel libre. Mais, depuis que j’ai quitté l’université, et jusqu’à ce que je commence à travailler chez Canonical, ma carrière professionnelle s’est déroulée dans l’industrie du logiciel propriétaire, d’abord comme développeuse puis comme testeuse.

Lorsque l’on travaille au sein d’un projet de logiciel propriétaire, les ressources pour tester sont très limitées. Une petite équipe reprend le travail initié par les développeurs avec les tests unitaires, utilisant leur expérience pour trouver autant de bogues que possible afin de mettre à disposition de l’utilisateur final un produit aussi abouti que possible. Dans le monde du logiciel libre, en revanche, tout est différent.

Lors de mon embauche chez Canonical, hormis la réalisation de mon rêve d’avoir un travail rémunéré au sein d’un projet de logiciel libre, j’ai été émerveillée par les possibilités des activités de test dans le cadre d’un tel projet. Le développement du produit s’effectue de manière ouverte, et les utilisateurs ont accès au logiciel dès son commencement, ils le testent et font des rapports de bogues dès que c’est nécessaire. C’est un nouveau monde rempli de beaucoup de possibilités pour une personne passionnée par les tests. Je voulais en profiter au maximum.

Comme beaucoup de personnes, je pensais que les tests « maison », c’est-à-dire l’utilisation par soi-même du logiciel que l’on envisage de mettre à disposition, était l’activité de test la plus importante qu’on puisse mener dans le logiciel libre. Mais si, selon la formule de Raymond dans La cathédrale et le bazar « avec suffisamment d’observateurs, tous les bogues sautent aux yeux », alors comment se fait-il qu’avec ses millions d’utilisateurs Ubuntu comporte encore des bogues sérieux à chaque nouvelle version ?

La première chose dont je me suis aperçue quand j’ai commencé à travailler chez Canonical c’est que les activités de test organisées étaient rares ou inexistantes. Les seules sessions de test qui étaient d’une certaine façon organisées se présentaient sous la forme de messages électroniques envoyés à une liste de diffusion, manière de battre le rappel pour tester un paquetage dans la version de développement d’Ubuntu. Je ne pense pas que cela puisse être considéré comme une vraie procédure de test, mais simplement comme une autre forme de « test maison ». Cette sorte de test génère beaucoup de doublons, car un bogue facile à débusquer sera documenté par des centaines de personnes. Malheureusement le bogue potentiellement critique, vraiment difficile à trouver, a de bonnes chances de passer inaperçu en raison du bruit créé par les autres bogues, et ce même si quelqu’un l’a documenté.

En progrès

La situation s’améliore-t-elle ? Sommes-nous devenus plus efficaces pour les tests au sein des projets de développement libre ? Oui, j’en suis convaincue.

Pendant les derniers cycles de développement d’Ubuntu, nous avons commencé bon nombre de sessions de test. La gamme des objectifs pour ces sessions est large, elle comprend des domaines comme de nouvelles fonctionnalités de bureau, des tests de régression, des tests de pilotes X.org ou des tests de matériel d’ordinateur portable. Les résultats sont toujours suivis et ils s’avèrent vraiment utiles pour les développeurs, car ils leur permettent de savoir si les nouveautés fonctionnent correctement, au lieu de supposer qu’elles fonctionnent correctement à cause de l’absence de bogues.

En ce qui concerne les outils d’assistance aux tests, beaucoup d’améliorations ont été apportées :

• Apport(1) a contribué à augmenter le niveau de détail des bogues signalés concernant Ubuntu : les rapports de plantage incluent toutes les informations de débogage et leurs doublons sont débusqués puis marqués comme tels ; les utilisateurs peuvent signaler des bogues sur base de symptômes, etc.
• Le Launchpad(2), avec ses connexions en amont, a permis d’avoir une vue complète des bogues – sachant que les bogues qui se produisent dans Ubuntu se situent généralement dans les projets en amont, et permet aux développeurs de savoir si les bogues sont en cours de résolution.
• Firefox, grâce à son programme et à son extension Test Pilot, mène des tests sans qu’on ait à quitter le navigateur(3). C’est, à mon sens, une bien meilleure façon de rallier des testeurs qu’une liste de diffusion ou un canal IRC.
• L’équipe Assurance Qualité d’Ubuntu teste le bureau en mode automatique et rend compte des résultats toutes les semaines(4), ce qui permet aux développeurs de vérifier très rapidement qu’il n’y a pas eu de régression majeure pendant le développement.

Cependant, malgré l’amélioration des tests dans les projets de logiciel libre il reste encore beaucoup à faire.

Pour aller plus loin

Les tests nécessitent une grande expertise, mais sont encore considérés au sein de la communauté du le logiciel libre comme une tâche ne demandant pas beaucoup d’efforts. L’une des raisons pourrait être que la manière dont on les réalise est vraiment dépassée et ne rend pas compte de la complexité croissante du monde du logiciel libre durant la dernière décennie. Comment est-il possible que, malgré la quantité d’innovations amenées par les communautés du logiciel libre, les tests soient encore réalisés comme dans les années 80 ? Il faut nous rendre à l’évidence, les scénarios de tests sont ennuyeux et vite obsolètes. Comment faire grandir une communauté de testeurs supposée trouver des bogues avérés si sa tâche principale est de mettre à jour les scénarios de test ?

Mais comment améliorer la procédure de test ? Bien sûr, nous ne pouvons pas nous débarrasser des scénarios de test, mais nous devons changer la façon dont nous les créons et les mettons à jour. Nos testeurs et nos utilisateurs sont intelligents, alors pourquoi créer des scripts pas-à-pas ? Ils pourraient aisément être remplacés par une procédure de test automatique. Définissons plutôt une liste de tâches que l’on réalise avec l’application, et certaines caractéristiques qu’elle devrait posséder. Par exemple, « l’ordre des raccourcis dans le lanceur doit pouvoir être modifié », ou « le démarrage de LibreOffice est rapide ». Les testeurs trouveront un moyen de le faire, et créeront des scénarios de test en parallèle des leurs.

Mais ce n’est pas suffisant, nous avons besoin de meilleurs outils pour aider les testeurs à savoir ce qu’ils testent, où et comment. Pourquoi ne pas avoir des API (interfaces de programmation) qui permettent aux développeurs d’envoyer des messages aux testeurs à propos des nouvelles fonctionnalités ou des mises à jour qui doivent être testées ? Pourquoi pas une application qui nous indique quelle partie du système doit être testée ? en fonction des tests en cours ? Dans le cas d’Ubuntu, nous avons les informations dans le Launchpad (il nous faudrait aussi des données sur les tests, mais au moins nous avons des données sur les bogues). Si je veux démarrer une session de test d’un composant en particulier j’apprécierais vraiment de savoir quelles zones n’ont pas encore été testées ainsi qu’une liste des cinq bogues comptant le plus de doublons pour cette version en particulier afin d’éviter de les documenter une fois de plus. J’aimerais avoir toutes ces informations sans avoir à quitter le bureau que je suis en train de tester. C’est quelque chose que Firefox a initié avec Test Pilot, bien qu’actuellement l’équipe rassemble principalement les données sur l’activité du navigateur.

La communication entre l’amont et l’aval et vice-versa doit aussi être améliorée. Pendant le développement d’une distribution, un bon nombre des versions amont sont également en cours de développement, et ont déjà une liste des bogues connus. Si je suis un testeur de Firefox sous Ubuntu, j’aimerais avoir une liste des bogues connus aussitôt que le nouveau paquet est poussé dans le dépôt. Cela pourrait se faire à l’aide d’une syntaxe reconnue pour les notes de versions, syntaxe qui pourrait ensuite être facilement analysée. Les rapports de bogue seraient automatiquement remplis et reliés aux bogues amont. Encore une fois, le testeur devrait avoir facilement accès à ces informations, sans quitter son environnement de travail habituel.

Les tests, s’ils étaient réalisés de cette manière, permettraient au testeur de se concentrer sur les choses qui comptent vraiment et font de la procédure de test une activité qualifiée ; se concentrer sur les bogues cachés qui n’ont pas encore été découverts, sur les configurations et environnements spéciaux, sur la création de nouvelles manières de casser le logiciel. Et, in fine, s’amuser en testant.

Récapitulons

Pour ce que j’en ai vu ces trois dernières années, les tests ont beaucoup progressé au sein d’Ubuntu et des autres projets de logiciels libres dans lesquels je suis plus ou moins impliquée, mais ce n’est pas suffisant. Si nous voulons vraiment améliorer la qualité du logiciel libre, nous devons commencer à investir dans les tests et innover dans la manière de les conduire, de la même façon que nous investissons dans le développement. Nous ne pouvons pas tester le logiciel du XXIe siècle avec les techniques du XXe siècle. Nous devons réagir. Qu’il soit open source ne suffit plus à prouver qu’un logiciel libre est de bonne qualité. Le logiciel libre sera bon parce qu’il est open source et de la meilleure qualité que nous puissions offrir.

1 http://wiki.ubuntu.com/Apport

2 http://launchpad.net

3 http://testpilot.mozillalabs.com

4 http://reports.qa.ubuntu.com/reports/desktop-testing/natty

Source : Impression 3D : une Américaine conçoit son propre disque vinyle (Numerama)

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

3. Hors du labo, au grand air

La croissance des communautés open source autour des projets universitaires

par Markus Kroëtzsch

Markus Kroëtzsch est post-doctorant au Département des Sciences Informatiques de l’Université d’Oxford. Il a soutenu son doctorat en 2010 à l’Institut d’Informatique Appliquée et Méthodes Formelles de description du Karlsruhe Institute of Technology. Ses recherches portent sur le traitement automatique de l’information, depuis les fondements de la représentation de la connaissance formelle jusqu’à leurs domaines d’application, tel le Web Sémantique. Il est le développeur principal de la plate-forme Semantic MediaWiki, application de Web sémantique, co-éditeur des spécifications W3C OWL2, administrateur principal du portail communautaire semanticweb.org, et co-auteur de l’ouvrage Foundations of Semantic Web Technologies. 

Au sein des universités, les chercheurs développent de grandes quantités de logiciels, que ce soit pour valider une hypothèse, pour illustrer une nouvelle approche, ou tout simplement comme outil en appui à une étude. Dans la plupart des cas, un petit prototype dédié fait le travail, et il est déployé rapidement tandis que l’enjeu de la recherche évolue. Cependant, de temps à autres, une nouvelle approche ou une technologie émergente a le potentiel de changer complétement la manière de résoudre un problème. Ce faisant, cela génère de la réputation professionnelle, du succès commercial, et la gratification personnelle d’amener une nouvelle idée à son plein potentiel. Le chercheur qui a fait une découverte de ce genre est alors tenté d’aller au-delà du prototype vers un produit qui sera réellement utilisé. Il est alors confronté à une toute nouvelle série de problèmes pratiques.

La peur de l’utilisateur

Dans l’un de ses célèbres essais sur l’ingénierie logicielle, Frederick P. Brooks, Jr. permet de se faire une bonne idée des efforts liés à la maintenance d’un vrai logiciel et nous met en garde contre l’utilisateur :

« Le coût total de la maintenance d’un programme largement utilisé est habituellement de 40% ou plus de son coût de développement. De façon surprenante, ce coût est fortement influencé par le nombre d’utilisateurs. Plus il y a d’utilisateurs, plus il y a de bugs » [1]

Bien que les chiffres soient probablement différents dans le contexte actuel, la remarque reste fondamentalement vraie. Elle pourrait même avoir été confirmée par l’usage généralisé de la communication instantanée. Pire encore : davantage d’utilisateurs ne produit pas seulement davantage de bugs ; en général, ils expriment aussi plus de demandes. Qu’il s’agisse d’une véritable erreur, d’une demande de fonctionnalité, ou tout simplement d’une mauvaise compréhension du fonctionnement du logiciel, les demandes de l’utilisateur lambda ne ressemblent en rien à un rapport de bug précis et technique. Et chaque demande requiert l’attention des développeurs et occupe un temps précieux qui n’est plus disponible pour écrire du code.

Avec son esprit d’analyse, le chercheur anticipe sur ce problème. Dans sa lutte naturelle pour éviter un avenir sombre dans le service client, il peut carrément développer de la peur envers l’utilisateur. Dans le pire des cas, cela peut le mener à prendre des décisions qui vont à l’encontre du projet dans son ensemble ; sous des formes plus légères, cela peut tout de même mener le chercheur à cacher des produits logiciels brillants à ses utilisateurs potentiels. Plus d’une fois, j’ai entendu des chercheurs dire : « Nous n’avons pas besoin de plus de visibilité : nous recevons déjà suffisamment d’emails ! ». Il est vrai que parfois la communication pour un outil logiciel nécessite un effort supérieur à celui que peut fournir un chercheur sans laisser tomber son emploi principal.

Pourtant, cette issue tragique aurait bien souvent pu être évitée. Brooks pouvait difficilement l’anticiper. Quand il a écrit ses essais, le fait est que les utilisateurs étaient des clients et que la maintenance logicielle faisait partie du produit qu’ils achetaient. Il fallait trouver un équilibre entre l’effort de développement, la demande du marché, et le prix. C’est toujours le cas pour de nombreux produits logiciels commerciaux de nos  jours, mais ça a peu de choses à voir avec la réalité du développement à petite échelle de l’open source. Les utilisateurs habituels de l’open source ne paient pas pour le service qu’ils reçoivent. Leur attitude n’est donc pas celle d’un client exigeant, mais bien plus souvent celle d’un partisan enthousiaste et reconnaissant. Transformer cet enthousiasme en un soutien plus que nécessaire n’est pas négligeable pour réussir dans l’art de la maintenance d’un logiciel open source : l’intérêt croissant de l’utilisateur doit aller de pair avec une contribution croissante.

Reconnaitre que les utilisateurs de logiciels open source ne sont pas que « des consommateurs qui ne paient pas » est une notion importante. Mais cela ne doit pas mener à surestimer leur potentiel. Le contre-pied optimiste de la peur irrationnelle de l’utilisateur est la croyance que des communautés actives croissent naturellement avec pour seule base la licence choisie pour publier le code. Cette grave erreur de jugement est bizarrement toujours aussi commune, et a scellé le destin de bien des tentatives de création de communautés ouvertes.

Semer et récolter

Le pluriel d’ « utilisateur » n’est pas « communauté ». Si l’un peut s’accroître en nombre, l’autre ne grandit pas d’elle-même, ou alors elle grandit sans direction et surtout sans fournir le soutien espéré au projet. La mission du responsable de projet qui cherche à profiter de l’énergie brute des utilisateurs ressemble à celle d’un jardinier qui doit préparer un terrain fertile, planter et arroser les semis, et peut-être élaguer les pousses non désirées avant de pouvoir récolter les fruits. Par rapport aux récompenses, l’investissement global est minime, mais il est essentiel de faire les bonnes choses, au bon moment.

Préparer le support technologique

Créer une communauté commence avant même que le premier utilisateur n’apparaisse. D’emblée, le choix du langage de programmation va déterminer le nombre de personnes qui pourront déployer et déboguer notre code. Objective Caml est sans doute un beau langage, mais si l’on utilise plutôt Java, la quantité d’utilisateurs et de contributeurs potentiels augmentera de plusieurs ordres de grandeur. Les développeurs doivent donc faire des compromis puisque la technologie la plus répandue est rarement la plus performante ou la plus élégante. Cela peut être une démarche particulièrement difficile pour des chercheurs qui privilégient souvent la supériorité formelle du langage. Quand je travaillais sur Semantic MediaWiki, on m’a souvent demandé pourquoi nous utilisions PHP alors que Java côté serveur serait tellement plus propre et performant. Comparons la taille de la communauté de Semantic MediaWiki et les efforts que demanderait le même développement basé sur du Java : voilà peut-être un début de réponse. Cet exemple illustre aussi que l’audience ciblée détermine le meilleur choix de la technologie de base. Le développeur lui-même devrait avoir le recul nécessaire pour prendre la décision la plus opportune.

Préparer minutieusement le terrain

Dans le même ordre d’idées, il faut créer un code lisible et bien documenté dès le début. Dans un environnement universitaire, certains projets logiciels rassemblent de nombreux contributeurs temporaires. Les changements dans les plannings et les projets des étudiants peuvent nuire à la qualité du code. Je me souviens d’un petit projet de logiciel à l’Université technique de Dresde qui avait été très bien maintenu par un assistant étudiant. Après son départ, on a constaté que le code était minutieusement documenté… en turc. Un chercheur ne peut être programmeur qu’à temps partiel, une discipline particulière est donc nécessaire pour mettre en œuvre le travail supplémentaire indispensable à l’élaboration d’un code accessible. En retour il y aura de bien meilleures chances par la suite d’avoir de bons rapports de bogues, des patchs utiles ou même des développeurs extérieurs.

Semer les graines des communautés

Les développeurs open source inexpérimentés considèrent souvent comme un grand moment la publication ouverte de leur code. En réalité, personne d’autre qu’eux ne la remarquera. Pour attirer aussi bien des utilisateurs que des contributeurs, il faut faire passer le mot. La communication publique d’un vrai projet devrait au moins inclure des annonces à chaque nouvelle version. Les listes de diffusion sont probablement le meilleur canal pour cela. Il faut un certain talent social pour trouver le juste équilibre entre le spam indésirable et la litote timide. Si un projet est motivé par la conviction sincère qu’il aidera les utilisateurs à résoudre de vrais problèmes, ce devrait être facile de lui faire une publicité convenable. Les utilisateurs feront vite la différence entre publicité éhontée et information utile. Bien évidemment, les annonces actives devront attendre que le projet soit finalisé. Cela ne concerne pas seulement le code, mais aussi la page d’accueil et la documentation d’utilisation basique.

Au cours de sa vie, le projet devrait être mentionné dans tous les endroits adéquats, y compris des sites web — à commencer par votre page d’accueil ! — des conférences, des papiers scientifiques, des discussions en ligne. On ne dira jamais assez le pouvoir du simple lien qui conduira un futur contributeur important sur le site du projet dès sa première visite. Les chercheurs ne doivent pas non plus oublier de publier leur logiciel en dehors de leur communauté universitaire proche. Les autres chercheurs sont rarement la meilleure base pour une communauté active.

Fournir des espaces pour grandir

Banal mais souvent négligé, le devoir des personnes qui maintiennent le projet est de fournir des espaces de communication afin que la communauté puisse se développer. Si un projet n’a pas de liste de discussion dédiée, alors toutes les demandes d’aide seront envoyées en message privé à la maintenance. S’il n’y a pas de bugtracker (NdT : logiciel de suivi de problèmes), les rapports de bogues seront moins nombreux et moins utiles. Sans un wiki éditable par tout un chacun pour la documentation utilisateur, le développeur est condamné à étendre et à réécrire la documentation en permanence. Si la version de développement du code source n’est pas accessible, alors les utilisateurs ne seront pas dans la capacité de tester la dernière version avant de se plaindre de problèmes. Si le dépôt de code est intrinsèquement fermé, il n’est alors pas possible d’accueillir des contributeurs externes. Toute cette infrastructure est disponible gratuitement par l’intermédiaire d’un certain nombre de fournisseurs de service. Toutes les formes d’interaction ne sont pas forcément désirées, par exemple, il y a des raisons de garder fermé le cercle des développeurs. Mais il serait inconscient d’espérer le soutien d’une communauté sans même préparer des espaces de base pour celle-ci.

Encourager et contrôler la croissance

Les développeurs inexpérimentés sont souvent préoccupés par le fait que l’ouverture de listes de diffusions, de forums et de wikis pour les utilisateurs nécessitera une maintenance supplémentaire. C’est rarement le cas, mais certaines activités de base sont bien entendu indispensables. Cela commence par la mise en œuvre rigoureuse des usages de communication publique. Les utilisateurs ont besoin d’apprendre à poser des questions publiquement, à consulter la documentation avant de poser des questions, et à rapporter les bogues à l’aide du bugtracker plutôt que par e-mail. J’ai tendance à rejeter toutes les demandes d’aide privées, ou à répondre via des listes publiques. Cela garantit au passage que les solutions sont disponibles sur le web pour les futurs utilisateurs qui les chercheront. Dans tous les cas, les utilisateurs doivent être remerciés explicitement pour toutes les formes de contributions : il faut beaucoup d’enthousiasme et des gens bien intentionnés pour construire une communauté solide.

Quand on atteint un certain nombre d’utilisateurs, une aide mutuelle commence à se mettre en place entre eux. C’est toujours un moment magique pour un projet et c’est un signe évident qu’il est sur la bonne voie. Dans l’idéal, les responsables du projet devraient continuer d’apporter leur aide pour les questions délicates, mais à un moment donné certains utilisateurs vont faire preuve d’initiative dans les discussions. Il est important de les remercier (personnellement) et de les impliquer d’avantage dans le projet. À l’inverse, les évolutions malsaines doivent être stoppées dès que possible, en particulier les comportements agressifs qui peuvent être un véritable danger pour le développement de la communauté. De même, l’enthousiasme le mieux intentionné n’est pas toujours productif et il faut parfois savoir dire non — gentiment mais clairement – pour éviter les dérapages possibles.

Le futur est ouvert

Construire une communauté initiale autour d’un projet contribue fortement à transformer un prototype de recherche en un logiciel open source. Si ça porte ses fruits, il existe de nombreuses options pour le développer en fonction des buts fixés par le mainteneur du projet et la communauté. Voici quelques indications :

Persévérer dans l’expansion du projet et de sa communauté open source, augmenter le nombre de personnes ayant des droits de contributions « directs », en réduisant la dépendance à son origine universitaire. Par ce biais, vous impliquez plus fortement la communauté – notamment au travers d’événements dédiés –;et vous pourrez établir un soutien organisationnel.

Créer une entreprise commerciale pour exploiter le projet, basée, par exemple, sur une double licence ou un business model de consultant. Des outils ayant fait leurs preuves et une communauté active sont des atouts majeurs dès le lancement d’une entreprise, et peuvent être bénéfiques dans chacune de vos stratégies d’entreprise sans abandonner le produit original open source.

Se retirer du projet. Il y a de nombreuses raisons pour qu’on ne puisse plus maintenir de lien avec le projet. Le fait d’avoir établi une communauté saine et ouverte maximise les chances pour que le projet continue de voler de ses propres ailes. Dans tous les cas, il est plus correct de faire une coupure nette que d’abandonner silencieusement le projet, en le tuant par une activité en chute libre au point qu’on ne trouve plus personne pour le maintenir.

Le profil de la communauté sera différent selon qu’on opte pour telle ou telle stratégie de développement. Mais dans tous les cas, le rôle du chercheur évolue en fonction des objectifs du projet. Le scientifique initial et le programmeur pourront prendre le rôle de gestionnaire ou de directeur technique. En ce sens, la différence principale entre un projet de logiciel open source d’importance et la recherche perpétuelle d’un prototype n’est pas tant la quantité de travail mais le type de travail nécessaire pour y arriver. Cela compte pour beaucoup dans sa réussite. Une fois qu’on l’a compris, il ne reste plus qu’à réaliser un super logiciel.

[1] Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on  Software Engineering. Anniversary Edition. Addison-Wesley, 1995.

3. Hors du labo, au grand air

La croissance des communautés open source autour des projets universitaires

par Markus Kroëtzsch

Markus Kroëtzsch est post-doctorant au Département des Sciences Informatiques de l’Université d’Oxford. Il a soutenu son doctorat en 2010 à l’Institut d’Informatique Appliquée et Méthodes Formelles de description du Karlsruhe Institute of Technology. Ses recherches portent sur le traitement automatique de l’information, depuis les fondements de la représentation de la connaissance formelle jusqu’à leurs domaines d’application, tel le Web Sémantique. Il est le développeur principal de la plate-forme Semantic MediaWiki, application de Web sémantique, co-éditeur des spécifications W3C OWL2, administrateur principal du portail communautaire semanticweb.org, et co-auteur de l’ouvrage Foundations of Semantic Web Technologies. 

Au sein des universités, les chercheurs développent de grandes quantités de logiciels, que ce soit pour valider une hypothèse, pour illustrer une nouvelle approche, ou tout simplement comme outil en appui à une étude. Dans la plupart des cas, un petit prototype dédié fait le travail, et il est déployé rapidement tandis que l’enjeu de la recherche évolue. Cependant, de temps à autres, une nouvelle approche ou une technologie émergente a le potentiel de changer complétement la manière de résoudre un problème. Ce faisant, cela génère de la réputation professionnelle, du succès commercial, et la gratification personnelle d’amener une nouvelle idée à son plein potentiel. Le chercheur qui a fait une découverte de ce genre est alors tenté d’aller au-delà du prototype vers un produit qui sera réellement utilisé. Il est alors confronté à une toute nouvelle série de problèmes pratiques.

La peur de l’utilisateur

Dans l’un de ses célèbres essais sur l’ingénierie logicielle, Frederick P. Brooks, Jr. permet de se faire une bonne idée des efforts liés à la maintenance d’un vrai logiciel et nous met en garde contre l’utilisateur :

« Le coût total de la maintenance d’un programme largement utilisé est habituellement de 40% ou plus de son coût de développement. De façon surprenante, ce coût est fortement influencé par le nombre d’utilisateurs. Plus il y a d’utilisateurs, plus il y a de bugs » [1]

Bien que les chiffres soient probablement différents dans le contexte actuel, la remarque reste fondamentalement vraie. Elle pourrait même avoir été confirmée par l’usage généralisé de la communication instantanée. Pire encore : davantage d’utilisateurs ne produit pas seulement davantage de bugs ; en général, ils expriment aussi plus de demandes. Qu’il s’agisse d’une véritable erreur, d’une demande de fonctionnalité, ou tout simplement d’une mauvaise compréhension du fonctionnement du logiciel, les demandes de l’utilisateur lambda ne ressemblent en rien à un rapport de bug précis et technique. Et chaque demande requiert l’attention des développeurs et occupe un temps précieux qui n’est plus disponible pour écrire du code.

Avec son esprit d’analyse, le chercheur anticipe sur ce problème. Dans sa lutte naturelle pour éviter un avenir sombre dans le service client, il peut carrément développer de la peur envers l’utilisateur. Dans le pire des cas, cela peut le mener à prendre des décisions qui vont à l’encontre du projet dans son ensemble ; sous des formes plus légères, cela peut tout de même mener le chercheur à cacher des produits logiciels brillants à ses utilisateurs potentiels. Plus d’une fois, j’ai entendu des chercheurs dire : « Nous n’avons pas besoin de plus de visibilité : nous recevons déjà suffisamment d’emails ! ». Il est vrai que parfois la communication pour un outil logiciel nécessite un effort supérieur à celui que peut fournir un chercheur sans laisser tomber son emploi principal.

Pourtant, cette issue tragique aurait bien souvent pu être évitée. Brooks pouvait difficilement l’anticiper. Quand il a écrit ses essais, le fait est que les utilisateurs étaient des clients et que la maintenance logicielle faisait partie du produit qu’ils achetaient. Il fallait trouver un équilibre entre l’effort de développement, la demande du marché, et le prix. C’est toujours le cas pour de nombreux produits logiciels commerciaux de nos  jours, mais ça a peu de choses à voir avec la réalité du développement à petite échelle de l’open source. Les utilisateurs habituels de l’open source ne paient pas pour le service qu’ils reçoivent. Leur attitude n’est donc pas celle d’un client exigeant, mais bien plus souvent celle d’un partisan enthousiaste et reconnaissant. Transformer cet enthousiasme en un soutien plus que nécessaire n’est pas négligeable pour réussir dans l’art de la maintenance d’un logiciel open source : l’intérêt croissant de l’utilisateur doit aller de pair avec une contribution croissante.

Reconnaitre que les utilisateurs de logiciels open source ne sont pas que « des consommateurs qui ne paient pas » est une notion importante. Mais cela ne doit pas mener à surestimer leur potentiel. Le contre-pied optimiste de la peur irrationnelle de l’utilisateur est la croyance que des communautés actives croissent naturellement avec pour seule base la licence choisie pour publier le code. Cette grave erreur de jugement est bizarrement toujours aussi commune, et a scellé le destin de bien des tentatives de création de communautés ouvertes.

Semer et récolter

Le pluriel d’ « utilisateur » n’est pas « communauté ». Si l’un peut s’accroître en nombre, l’autre ne grandit pas d’elle-même, ou alors elle grandit sans direction et surtout sans fournir le soutien espéré au projet. La mission du responsable de projet qui cherche à profiter de l’énergie brute des utilisateurs ressemble à celle d’un jardinier qui doit préparer un terrain fertile, planter et arroser les semis, et peut-être élaguer les pousses non désirées avant de pouvoir récolter les fruits. Par rapport aux récompenses, l’investissement global est minime, mais il est essentiel de faire les bonnes choses, au bon moment.

Préparer le support technologique

Créer une communauté commence avant même que le premier utilisateur n’apparaisse. D’emblée, le choix du langage de programmation va déterminer le nombre de personnes qui pourront déployer et déboguer notre code. Objective Caml est sans doute un beau langage, mais si l’on utilise plutôt Java, la quantité d’utilisateurs et de contributeurs potentiels augmentera de plusieurs ordres de grandeur. Les développeurs doivent donc faire des compromis puisque la technologie la plus répandue est rarement la plus performante ou la plus élégante. Cela peut être une démarche particulièrement difficile pour des chercheurs qui privilégient souvent la supériorité formelle du langage. Quand je travaillais sur Semantic MediaWiki, on m’a souvent demandé pourquoi nous utilisions PHP alors que Java côté serveur serait tellement plus propre et performant. Comparons la taille de la communauté de Semantic MediaWiki et les efforts que demanderait le même développement basé sur du Java : voilà peut-être un début de réponse. Cet exemple illustre aussi que l’audience ciblée détermine le meilleur choix de la technologie de base. Le développeur lui-même devrait avoir le recul nécessaire pour prendre la décision la plus opportune.

Préparer minutieusement le terrain

Dans le même ordre d’idées, il faut créer un code lisible et bien documenté dès le début. Dans un environnement universitaire, certains projets logiciels rassemblent de nombreux contributeurs temporaires. Les changements dans les plannings et les projets des étudiants peuvent nuire à la qualité du code. Je me souviens d’un petit projet de logiciel à l’Université technique de Dresde qui avait été très bien maintenu par un assistant étudiant. Après son départ, on a constaté que le code était minutieusement documenté… en turc. Un chercheur ne peut être programmeur qu’à temps partiel, une discipline particulière est donc nécessaire pour mettre en œuvre le travail supplémentaire indispensable à l’élaboration d’un code accessible. En retour il y aura de bien meilleures chances par la suite d’avoir de bons rapports de bogues, des patchs utiles ou même des développeurs extérieurs.

Semer les graines des communautés

Les développeurs open source inexpérimentés considèrent souvent comme un grand moment la publication ouverte de leur code. En réalité, personne d’autre qu’eux ne la remarquera. Pour attirer aussi bien des utilisateurs que des contributeurs, il faut faire passer le mot. La communication publique d’un vrai projet devrait au moins inclure des annonces à chaque nouvelle version. Les listes de diffusion sont probablement le meilleur canal pour cela. Il faut un certain talent social pour trouver le juste équilibre entre le spam indésirable et la litote timide. Si un projet est motivé par la conviction sincère qu’il aidera les utilisateurs à résoudre de vrais problèmes, ce devrait être facile de lui faire une publicité convenable. Les utilisateurs feront vite la différence entre publicité éhontée et information utile. Bien évidemment, les annonces actives devront attendre que le projet soit finalisé. Cela ne concerne pas seulement le code, mais aussi la page d’accueil et la documentation d’utilisation basique.

Au cours de sa vie, le projet devrait être mentionné dans tous les endroits adéquats, y compris des sites web — à commencer par votre page d’accueil ! — des conférences, des papiers scientifiques, des discussions en ligne. On ne dira jamais assez le pouvoir du simple lien qui conduira un futur contributeur important sur le site du projet dès sa première visite. Les chercheurs ne doivent pas non plus oublier de publier leur logiciel en dehors de leur communauté universitaire proche. Les autres chercheurs sont rarement la meilleure base pour une communauté active.

Fournir des espaces pour grandir

Banal mais souvent négligé, le devoir des personnes qui maintiennent le projet est de fournir des espaces de communication afin que la communauté puisse se développer. Si un projet n’a pas de liste de discussion dédiée, alors toutes les demandes d’aide seront envoyées en message privé à la maintenance. S’il n’y a pas de bugtracker (NdT : logiciel de suivi de problèmes), les rapports de bogues seront moins nombreux et moins utiles. Sans un wiki éditable par tout un chacun pour la documentation utilisateur, le développeur est condamné à étendre et à réécrire la documentation en permanence. Si la version de développement du code source n’est pas accessible, alors les utilisateurs ne seront pas dans la capacité de tester la dernière version avant de se plaindre de problèmes. Si le dépôt de code est intrinsèquement fermé, il n’est alors pas possible d’accueillir des contributeurs externes. Toute cette infrastructure est disponible gratuitement par l’intermédiaire d’un certain nombre de fournisseurs de service. Toutes les formes d’interaction ne sont pas forcément désirées, par exemple, il y a des raisons de garder fermé le cercle des développeurs. Mais il serait inconscient d’espérer le soutien d’une communauté sans même préparer des espaces de base pour celle-ci.

Encourager et contrôler la croissance

Les développeurs inexpérimentés sont souvent préoccupés par le fait que l’ouverture de listes de diffusions, de forums et de wikis pour les utilisateurs nécessitera une maintenance supplémentaire. C’est rarement le cas, mais certaines activités de base sont bien entendu indispensables. Cela commence par la mise en œuvre rigoureuse des usages de communication publique. Les utilisateurs ont besoin d’apprendre à poser des questions publiquement, à consulter la documentation avant de poser des questions, et à rapporter les bogues à l’aide du bugtracker plutôt que par e-mail. J’ai tendance à rejeter toutes les demandes d’aide privées, ou à répondre via des listes publiques. Cela garantit au passage que les solutions sont disponibles sur le web pour les futurs utilisateurs qui les chercheront. Dans tous les cas, les utilisateurs doivent être remerciés explicitement pour toutes les formes de contributions : il faut beaucoup d’enthousiasme et des gens bien intentionnés pour construire une communauté solide.

Quand on atteint un certain nombre d’utilisateurs, une aide mutuelle commence à se mettre en place entre eux. C’est toujours un moment magique pour un projet et c’est un signe évident qu’il est sur la bonne voie. Dans l’idéal, les responsables du projet devraient continuer d’apporter leur aide pour les questions délicates, mais à un moment donné certains utilisateurs vont faire preuve d’initiative dans les discussions. Il est important de les remercier (personnellement) et de les impliquer d’avantage dans le projet. À l’inverse, les évolutions malsaines doivent être stoppées dès que possible, en particulier les comportements agressifs qui peuvent être un véritable danger pour le développement de la communauté. De même, l’enthousiasme le mieux intentionné n’est pas toujours productif et il faut parfois savoir dire non — gentiment mais clairement – pour éviter les dérapages possibles.

Le futur est ouvert

Construire une communauté initiale autour d’un projet contribue fortement à transformer un prototype de recherche en un logiciel open source. Si ça porte ses fruits, il existe de nombreuses options pour le développer en fonction des buts fixés par le mainteneur du projet et la communauté. Voici quelques indications :

Persévérer dans l’expansion du projet et de sa communauté open source, augmenter le nombre de personnes ayant des droits de contributions « directs », en réduisant la dépendance à son origine universitaire. Par ce biais, vous impliquez plus fortement la communauté – notamment au travers d’événements dédiés –;et vous pourrez établir un soutien organisationnel.

Créer une entreprise commerciale pour exploiter le projet, basée, par exemple, sur une double licence ou un business model de consultant. Des outils ayant fait leurs preuves et une communauté active sont des atouts majeurs dès le lancement d’une entreprise, et peuvent être bénéfiques dans chacune de vos stratégies d’entreprise sans abandonner le produit original open source.

Se retirer du projet. Il y a de nombreuses raisons pour qu’on ne puisse plus maintenir de lien avec le projet. Le fait d’avoir établi une communauté saine et ouverte maximise les chances pour que le projet continue de voler de ses propres ailes. Dans tous les cas, il est plus correct de faire une coupure nette que d’abandonner silencieusement le projet, en le tuant par une activité en chute libre au point qu’on ne trouve plus personne pour le maintenir.

Le profil de la communauté sera différent selon qu’on opte pour telle ou telle stratégie de développement. Mais dans tous les cas, le rôle du chercheur évolue en fonction des objectifs du projet. Le scientifique initial et le programmeur pourront prendre le rôle de gestionnaire ou de directeur technique. En ce sens, la différence principale entre un projet de logiciel open source d’importance et la recherche perpétuelle d’un prototype n’est pas tant la quantité de travail mais le type de travail nécessaire pour y arriver. Cela compte pour beaucoup dans sa réussite. Une fois qu’on l’a compris, il ne reste plus qu’à réaliser un super logiciel.

[1] Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on  Software Engineering. Anniversary Edition. Addison-Wesley, 1995.

Le saviez-vous ? On trouve désormais l’intégralité de notre collection de livres libres Framabook dans les rayons d’une sympathique librairie parisienne au nom fort bien choisi : « A Livr’Ouvert » qui se situe 171 bis boulevard Voltaire.

Pour fête dignement cela, nous vous invitons samedi 8 décembre entre 16h et 18h30 à une rencontre dédicace avec trois auteurs de la collection : Simon Gee Giraudot (ci-dessous sur la photo), Benjamin Jean et Pouhiou (ci-dessus sur la photo).

Ils partagent le même engagement en faveur du Libre mais leurs ouvrages respectifs s’inscrivent ici dans la diversité puisqu’on a une BD, un essai et un roman.

• Simon Gee Giraudot : Au temps pour moi. tome 4 BD Geektionnerd (annonce Framablog)

• Benjamin Jean : Option Libre. Du bon usage des licences libres (annonce Framablog)

• Pouhiou : #Smartarded — Le cycle des NoéNautes, tome I (annonce Framablog)

Alexis Kauffmann (aKa) et d’autres membres de la dream team Framasoft seront également présents, sans oublier quelques chatons fraîchement sauvés du Pack Liberté.

Dernier argument : un apéro sera offert pour l’occasion 😉

Important : Si vous comptez en être merci de remplir ce framadate qui nous permettra de nous compter afin de mieux nous organiser.

• Rencontre Framabook à la Libraire « A Livr’Ouvert »
• Samedi 8 décembre de 16h à 18h30
• 171 bis boulevard Voltaire 75011 Paris (Métro Charonne)
• OpenStreetMap

Crédit photos : Pierre Selim et aKa (Creative Commons By)

Notre premier billet consacré à l’impression 3D date de 2008. Depuis cette technologie a fait de gros progrès, elle frappe déjà à la porte de nos maisons pour le plus grand bénéfice de tous. Et tous les espoirs sont permis puisque l’esprit du libre s’est penché dès le départ sur son berceau.

Sauf qu’ici comme ailleurs, nous ne sommes pas au pays de bisounours et la résistance de l’ancien monde sera à n’en pas douter dure et acharnée. C’est d’ailleurs pour être prêts en amont que nous avons déjà publié ces deux articles : L’impression 3D, ce sera formidable… s’ils ne foutent pas tout en l’air ! et Ils tenteront de nous pourrir l’impression 3D avec leurs DRM.

Comme cela est déjà le cas pour le logiciel, de nombreuses attaques viendront du côté des brevets (et la récente affaire Apple Samsung n’est pas faite pour nous rassurer).

Heureusement la législation américaine a mis en place une nouvelle procédure qui permet à tout citoyen de participer au processus de validation (ou non) d’un brevet. C’est ce droit de vigilance que se propose d’exercer l’Electronic Frontier Foundation (ou EFF) avec nous.

Oui, cela ne concerne (pour le moment) que les États-Unis mais dans ce domaine on sait très bien que ce sont eux qui donnent le la au niveau mondial.

Edit : Gérald Sédrati-Dinet (alias Gibus) qui en connaît un rayon sur le sujet, lire par exemple cette excellente interview sur PCInpact, nous met en garde dans les commentaires. Cette procédure ne fait pas le jeu de ceux qui réclamment purement et simplement la suppression des brevets logiciels. Ce serait même contre-productif et l’EFF a tort de s’engager sur cette voie.

Rejoignez les efforts de l’EFF pour que l’impression 3D reste libre

Join EFF’s Efforts to Keep 3D Printing Open

Julie Samuels – 24 octobre 2012 – EFF.org
(Traduction : KoS, Ward, PostBlue, tibs, Simounet, Ag3m, Damien, Jeff_, HgO, Aylham, 4nti7rust)

Grâce à la communauté « open hardware » (NdT : ou matériel libre), vous pouvez maintenant posséder une imprimante 3D pour quelques centaines de dollars, avec des douzaines de modèles disponibles. Ces imprimantes conçues par la communauté surclassent déjà les modèles propriétaires qui coûtent pourtant 30 fois plus cher. Cette innovation incroyable est possible grâce à l’expiration, il y a plusieurs années, du brevet principal couvrant les technologies de l’impression 3D, ce qui a permis à des projets comme RepRap de prouver ce que nous savions déjà, à savoir que le libre dépasse souvent le système de brevets pour stimuler l’innovation.

Les matériels d’impression libres ont déjà été utilisés pour le prototypage rapide de nouvelles inventions, pour imprimer des pièces de remplacement d’objets d’appareils domestiques, par des maîtres du bricolage pour transformer une perceuse en centrifugeuse, pour des jeux où nous pouvons créer nos propres pièces, et pour des milliers d’autres choses par des gens de tous horizons. Des projets comme MakerBot et Solidoodle ont rendu les imprimantes 3D aussi faciles d’accès qu’un dispositif plug&play, où vous n’avez même plus à souder quoi que se soit pour commencer à manufacturer des objets que vous avez dessiné ou dont vous avez téléchargé les plans sur Internet. Avec l’expiration des brevets, la communauté de l’open hardware sera en mesure de libérer son esprit créatif sur les nouvelles technologies, des technologies qui ont déjà été utilisées pour concevoir des prothèses personnalisées, des guitares, des chaussures, et plus encore. Les possibilités sont illimitées (NdT : traduit ici par le Framablog).

Le Problème

Alors que les principaux brevets restreignant l’impression 3D ont expiré ou sont sur le point de l’être, il existe un risque que les creative patent (NdT : brevets sur les idées) continuent de verrouiller les idées au-delà des 20 ans initialement prévus pour ces brevets, ou qu’ils ne restreignent les avancées futures de la communauté open source. Alors même que, nous le savons, la nature incrémentielle des innovations sur l’impression 3D la rend particulièrement inéligible pour les brevets.

Le projet

Comme nous l’avons dit précédemment , l’America Invents Act n’a pas réussi à corriger le problème de l’excessive brevetabilité. Malgré on y trouve au moins une clause récente qui, nous le pensons, pourra être utile : le Preissuance Process.

Cette procédure autorise des tiers à participer au processus de dépôt de brevets en ayant la possibilité d’informer les examinateurs de l’état antérieur de la technique en question. Nous sommes fiers de voir que le Patent Office (NdT : Bureau des Brevets) a ouvert le processus à ceux qui ne déposeront probablement pas de brevets eux-même, mais qui en seront impactés dans leur vie quotidienne. Nous sommes content de savoir que ce nouvelle procédure pourra aider à endiguer la déferlante de brevets illégitimes.

L’EFF et la Cyberlaw Clinic au Centre Berkman de Harvard pour l’Internet et la Société travaillent ensemble pour utiliser cette nouvelle procédure afin de mettre à l’épreuve les dépôts de brevets qui menacent particulièrement les technologies d’impression 3D en plein développement. En premier lieu, nous évaluons les dépôts de brevets sur l’impression 3D qui sont actuellement en cours devant le Patent Office pour identifier de potentiels dangers. Nous avons besoin de vous ! Si vous connaissez des applications qui couvrent les technologies d’impression 3D et qui selon vous devraient être contestées, faites-le nous savoir par mail à 3Dprinting@eff.org (indiquez nous également tous les précédents pertinents que vous connaîtriez).

Pour s’impliquer, il est possible de se rendre sur l’outil de recherche du USPTO (NdT : Bureau de gestion des brevets et des marques déposées des États-Unis), du PAIR (NdT : Récupération d’informations des dépôt de brevets) et/ou de Google Patents. Chacune de ces sources contient de nombreux détails sur les brevets actuellement en attente de validation au USPTO.

Voilà le problème : avec les lois en vigueur, un dépôt de brevet ne peut être contestée par la Preissuance Submission que dans les six mois suivant sa publication (ou avant la date du premier rejet, si cette action se passe après). Ce qui signifie que le compte à rebours a déjà commencé pour les rejets concernant les dépôts de brevet en cours.

Une fois les cibles identifiées, nous nous renseignerons sur les précédents pertinents. Nous vous demanderons à nouveau votre aide à ce moment là, alors, s’il vous plait, soyez vigilants. Tout document disponible publiquement avant le dépôt d’un brevet est considéré comme un précédent; cela peut inclure des e-mails sur des listes publiques, des sites internet, et même des thèses universitaires. En raison de la limite temporelle, nous devons effectuer ces recherches très rapidement.

Il est heureux d’avoir à disposition cette nouvelle façon de combattre le dépôt de brevets dangereux avant qu’ils ne deviennent réellement dangereux. Mais l’America Invents Act et les capacités de recherche du site du Patent Office ne nous rendent pas la tâche aisée. Nous avons besoin de votre aide pour pouvoir accomplir cela, alors s’il vous plaît, faites ce que vous pouvez pour aider à protéger la communauté de l’impression 3D des brevets flous et nocifs qui peuvent menacer de passionnantes innovations.

Crédit photo : Fdecomite (Creative Commons By)

Nous sommes en 2023. Vous cassez malencontreusement une assiette. Vous allez tout naturellement chercher son fichier numérique sur le Net pour en créer une nouvelle sur votre imprimante 3D, en la modifiant éventuellement au passage pour l’adapter à vos besoins. Mais deux minutes plus tard la Police du Copyright sonne à votre porte et vous embarque en flagrant délit d’effraction de propriété intellectuelle et contournement de mesure de protection…

En mai 2011 nous publiions une longue et riche traduction : L’impression 3D, ce sera formidable… s’ils ne foutent pas tout en l’air !.

Nous y sommes désormais. Et ils vont chercher à bloquer le système et le partage tout comme ils ont cherché (et partiellement réussi) à le faire avec le logiciel, la musique ou le cinéma.

Sauf qu’ici nous avons déjà nos propres imprimantes, logiciels et formats libres et ouverts. En se débrouillant un peu, et luttant beaucoup, on devrait pouvoir s’épargner un nouveau Napster ou Megaupload de l’impression 3D.

Comment les DRM vont infester la révolution de l’impression 3D

How DRM will infest the 3D printing revolution

Ryan Whitwam – 16 octobre 2012 – ExtremeTech.com
(Traduction : Kurze, Dryt, Gatitac, goofy, Sylvain, Kiwileaks)

Alors que vous étiez tout occupés à vous exciter et à déclarer que l’impression 3D est le début d’une nouvelle époque, une nouvelle loi sur les brevets s’apprête à pourrir l’ambiance.

En effet, Nathan Myhrvold, ancien DSI chez Microsoft et fondateur d’Intellectual Ventures, société détentrice de nombreux brevets, a réussi à obtenir un brevet étendu sur les DRM de l’impression 3D. Cette révolution de l’impression 3D que nous avons tant espérée s’en trouve tout d’un coup fort contrariée.

Le système envisagé par Myhrvold sera utilisé afin d’empêcher les utilisateurs d’imprimante 3D de violer les « droits de production des objets ». Pour utiliser son imprimante il faut d’abord la charger avec le fichier numérique de l’objet à imprimer. Or ici, avant qu’une quelconque impression ne soit lancée, on va vous obliger à vous connecter à un serveur distant qui vérifiera que vous avez l’autorisation d’imprimer cet objet. Si cela vous semble familier c’est parce que c’est ce qui était arrivé à la musique en son temps dans le sillage de Napster.

La loi sur le droit d’auteur est une grosse machine compliquée et elle n’est pas applicable traditionnellement aux objets. Cependant, un nouvel appareil, une invention ou une nouvelle conception peuvent être brevetés. C’est justement ainsi que ceux d’Intellectual Ventures gagnent de l’argent et c’est probablement la raison pour laquelle ils sont intéressés par ce genre de DRM. L’entreprise acquiert les brevets sur différentes technologies et inventions, se construit ainsi son petit portefeuille, et ensuite elle poursuit tous ceux qui pourraient être en infraction. C’est cela qui a conduit de nombreuses personnes à surnommer ces sociétés des « troll à brevets » (NdT : Patent Troll), et elles ont probablement raison.

Alors comment passe t-on de la situation actuelle à une sorte de dystopie où votre imprimante vous dénonce à la police du copyright ? Il y aura, je pense, deux forces négatives qui nous pousseront dans ce sens.

La première est le risque d’amalgame avec le P2P (échange de fichier peer-to-peer). Plus les imprimantes gagneront en précision, plus les entreprises qui vous vendent ces imprimantes seront comparées à celles qui proposent les logiciels de peer-to-peer. Voilà le premier casse-tête légal auquel ces entreprises devront faire face. Nombreux sont les auteurs de ces applications de partage de fichiers qui ont fini devant les tribunaux et je ne serais pas surpris que quelque chose de similaire arrive un jour ou l’autre aux constructeurs de type MakerBot.

La seconde force qui va s’opposer au développement de l’impression 3D est un peu plus inquiétante. Il y a déjà des gens qui étudient la faisabilité de l’impression de composants d’armes à feu. Ce n’est peut-être pas encore faisable pour le moment, mais ça le sera un jour. Avant que cela n’arrive, des armes plus simples comme des « poings américains » réalisés avec du plastique super résistant vont être susceptibles de poser des problèmes aux gouvernements des pays où ces objets sont illégaux. Les lois sur les armes ne sont pas celles de la propriété intellectuelle mais elles nous amèneront au même point : la restriction de l’usage de l’impression 3D. Les lobbies de copyright pourraient s’appuyer et s’appuieront sur ce problème pour justifier un contrôle plus général.

Les vendeurs d’imprimantes 3D ne seront probablement pas obligés directement par la loi de mettre en place des restrictions, mais le déluge de poursuites pour des armes et des objets brevetés imprimés pourrait les pousser à le faire. Même Google n’a pas eu d’autre choix que de mettre en place des algorithmes sévères de détection automatisée de contenus sous droits d’auteur sur Youtube pour limiter sa responsabilité. Nous avons cependant vu ce système automatisé échouer maintes et maintes fois.

Chaque système de DRM implémenté jusqu’à aujourd’hui a été piraté d’une façon ou d’une autre. C’est vraiment une mauvaise blague pour l’utilisateur moyen : les DRM les bride dans leur vie numérique. Les autres, plus calés, contourneront les règles et pourront imprimer tous les objets brevetés qu’ils voudront. Les DRM ne résoudront véritablement aucun problème. Ils ne le font jamais. Mais ce sera peut-être un élément inévitable de l’avenir de l’impression 3D.

Crédit photo : FdeComite (Creative Commons By)

Le matériel libre, ou open hardware, en général et l’impression 3D en particulier, cela fait longtemps qu’on en parle sur le Framablog (notre premier article sur la RepRap date de 2008).

Nous y croyons parce qu’avec une imprimante 3D libre, vous pouvez non seulement créer des objets en partageant leurs fichiers numériques sous format et licence libres mais également concevoir l’imprimante elle-même, puisque ses sources (c’est-à-dire ses plans de fabrication) sont aussi sous licence libre.

À partir de là, vous voici potentiellement prêt pour… changer le monde (ou tout du moins, ne nous emballons pas, pour dessiner lentement mais sûrement les contours d’un nouveau paysage industriel). Évidemment cela ne se fera pas sans peine et l’on peut déjà anticiper de terribles batailles du côté de la propriété intellectuelle (pire encore que pour la culture), d’où notre long (mais passionnant) article : L’impression 3D, ce sera formidable… s’ils ne foutent pas tout en l’air !.

Or que se passe-t-il aujourd’hui ? L’un des fers de lance de l’impression 3D, la société MakerBot, a récemment annoncé la sortie de son nouveau modèle, la « Replicator 2 » (cf photo ci-dessous). Et à en croire cette percutante vidéo promotionnelle elle semble en effet bien plus mieux que les précédentes, d’ailleurs le célèbre magazine Wired s’en est tout de suite extasié : The New MakerBot Replicator Might Just Change Your World (rien que ça !)

Mais, car il y a un mais, il semblerait que ce nouveau modèle ne soit tout simplement plus libre, aussi bien dans ses sources de fabrication que (et c’est peut-être le plus choquant) dans le format de fichier numérique permettant de créer les objets en 3D (qui se partagent du reste sur le site Thingiverse de MakerBot qui lui aussi a récemment changé ses conditions d’utilisation dans le sens de la fermeture, d’où l’apparition d’alternatives). Tout ceci reste au conditionnel mais force est de reconnaître que MakerBot navigue en ce moment entre flou et silence quant à la réponse à donner à ce début de polémique.

Si cela s’avérait fondé, cela serait très mal vécu par la communauté qui y verrait là comme une sorte de trahison avec les principes du matériel libre, d’autant que la société MakerBot s’est fait connaître dans l’enthousiasme justement parce qu’elle proposait des modèles d’imprimantes 3D libres (quand vous vous rendez sur l’article Imprimante 3D de Wikipédia, MakerBot est cité en exemple de matériel libre).

Ceci étant dit, la question sous-jacente est aussi celle de la viabilité des entreprises de matériels libres. MakerBot a levé des fonds (dix millions de dollars), a investi, vient d’ouvrir un magasin à New York, etc. MakerBot a donc le vent en poupe et est en train de changer de dimension industrielle. Cela peut-il se faire tout en restant totalement libre ? Peut-être que les investisseurs ont fait pression vers la fermeture (par rapport au profit, à la concurrence, etc. quid d’un petit malin qui prendrait les sources délocaliserait en Chine et inonderait le marché ? d’ailleurs on y a déjà plus que pensé !).

Pour rentre compte de cette polémique nous vous proposons coup sur coup trois traductions ci-dessous (une fois de plus, merci à tous les traducteurs bénévoles).

La première émane de Josef Prusa, développeur tchèque pionnier (et passionné) du projet RepRap que l’on peut considérer comme la première imprimante 3D libre (et qui elle, on en est sûr, l’est restée). C’est d’ailleurs sur cette RepRap que s’est construit MakerBot et ils ne s’en cachent pas. C’est lui qui a levé le lièvre et il réagit ici avec véhémence et émotion (d’où le style parfois confus, flottant et familier sachant que l’anglais n’est pas sa langue maternelle non plus).

La seconde est un réponse directe à Josef Prusa. Son auteur est Bre Pettis, l’un des fondateurs de MakerBpot. Il semblerait qu’elle soit destinée avant tout à éteindre l’incendie.

La dernière traduction provient lui aussi de l’un des fondateurs de MakerBot, sauf qu’il a été viré de l’entreprise depuis ! On peut estimer qu’il y a de la rancœur dans son propos mais il n’a pas forcément tort de qualifier la réponse de Bre Pettis de « tas de conneries issu du double langage d’entreprise » en rappelant la définition de l’open hardware.

Et pour finir cette (longue) introduction, un lien vers un petit dessin qui résume amèrement la situation.

Crédit photo : Louis Seigal (Creative Commons By)

Le sens de l’Open Hardware

Open Hardware meaning

Josef Prusa – 20 Septembre 2012 – Blog personnel
(Traduction : fcharton, KoS, Smonff, Pascal, Alex, Gatitac, @jfomhover, ProgVal, Dam, Ag3m, tanguy)

Je voulais écrire sur ce sujet depuis longtemps. Certains d’entre vous le savent peut-être, d’autres non, mais j’ai lancé ma propre société de RepRap. Elle se nomme Prusa Research, et c’est sans doute la première entreprise basée sur l’open hardware en République Tchèque, mais certainement pas la première au monde. Il y a plusieurs projets qui le font très bien, par exemple Arduino (à qui je dois tellement que, grâce à RepRap, je peux maintenant considérer Massimo comme mon ami car j’ai commencé à faire du hardware grâce à lui et Arduino), Adafruit, Sparkfun, etc.

La RepRap et surtout l’impression 3D sont pleine de conneries actuellement, c’est vrai. Il y a ainsi tous les jours de nouvelles entreprises qui se montent. La majorité des gens n’y ont pas contribué d’un yotta, pas apporté la moindre contribution et pourtant ils se prétendent inventeurs, mais fini le troll. Je fais partie de la communauté RepRap depuis vraiment longtemps et je puis affirmer sans fausse modestie que j’ai beaucoup aidé à le diffuser. La Prusa Mendel est probablement le modèle d’imprimante 3D le plus répandu sur la planète.

Croyez moi, c’est parfois vraiment tentant de prétendre avoir réalisé des choses que vous n’avez pas vraiment faites, n’est-ce pas ? Comme « Hé, mon imprimante peut imprimer à une résolution de 50 microns! » LOL. J’ai conçu un putain de tatouage pour me défendre de ça. C’est le logo de l’Open Hardware avec la goutte standard de RepRap dedans. C’est directement sur mon avant-bras droit, tout le monde peut le voir quand on me serre la main, quand je rencontre quelqu’un ou que je signe un contrat, peu importe. C’est un symbole pour moi. L’Open Hardware et RepRap ont fait de moi ce que je suis.

Un triste évènement qui s’est produit aujourd’hui m’a finalement motivé à écrire cet article. Makerbot a fermé ses sources, du moins tout semble le laisser présager. Makerbot a été lancé par plusieurs développeurs principaux du projet RepRap, Zach Smith, Bre Pettis (NdT : lire sa réponse juste après) et Adam Mayer. Adrian Bowyer, le fondateur du projet RepRap, leur a donné, comme d’autres, de l’argent pour démarrer. Makerbot est basé sur la RepRap, et ils n’ont jamais eu honte de cela. Mais cela a changé et Makerbot a commencé à prendre de la distance. Les gens m’ont accusé de dénigrer Makerbot lorsque je donne des conférences sur la RepRap. Je me suis dit « qu’est-ce que c’est que ce délire ! ». J’ai même échangé quelques e-mails avec Bre. Je vois toujours Makerbot comme un ami important de l’univers Open Hardware, également comme un bouclier qui protègerait de potentielles poursuites judiciaires.

Bre a donné une conférence l’an dernier à l’Open Hardware Summit, bla bla…. « une entreprise qui montre aux autres que le chemin de l’open source est possible ». J’avoue que je grinçais des dents en entendant le directeur des relations publiques laisser penser qu’ils avaient inventé la chose, vous savez, cette connerie que Makerbot a créé : l’extrudeur pas à pas. Ils en ont même fait une vidéo sympa. Plus tard, ils ont levé la bagatelle de 10 millions de dollars et les choses ont commencé à changer.

Et surprise, surprise, maintenant on a la Replicator 2 et sa version en source fermée. Hé, regardez, on a récupéré toutes les améliorations que vous avez partagé sur Thingiverse, compilé le tout dans un paquet et on l’a fermé. Pareil avec le logiciels MakerWare. (Ils ont finalement, après des années, arrêté d’utiliser Skeinforge, un logiciel libre créé par un brésilien qui n’avait même pas d’imprimante).

Et vous savez ce qui est le plus sournois ? Ne pas en parler lorsqu’ils l’ont annoncé, pas même lorsque les premières commandes sont parties ou juste après l’Open Hardware Summit où Bre Pettis est allé faire un beau discours (relayé par des magazines comme Make: faisant de MakerBot l’un des héros de l’Open Hardware).

J’ai demandé des précisions sur leur page Facebook, demandé à Bre directement et à d’autres employés, mais je n’ai eu aucune réponse. Si c’est vraiment ouvert, pourquoi ne pas le dire ?

Lettre ouverte à Bre Pettis.
Salut Bre,
On se connait depuis un moment. Je voulais te demander si la Replicator 2 est fermée ou non. Et si oui, pourquoi ? J’aimerais aussi t’interviewer pour mon émission RepRap sur Youtube, je te promets de rester neutre. Mais il faudra t’expliquer sur ton comportement bizarre que je mentionne dans cet article.
Jo Prusa, core développeur du projet RepRap

Crédit photo : Ddurant123 (Creative Commons By)

Corriger la désinformation avec de l’information

Fixing Misinformation with Information

Bre Pettis – 20 septembre 2012 – MakerBot.com
(Traduction : fcharton, KoS, Smonff, Pascal, Alex, Gatitac, @jfomhover, ProgVal, Dam, Ag3m, tanguy)

Il y a de fausses informations que j’aimerais éclaircir.

Question 1 : Le MakerBot Replicator 2 est-il open source ?

Nous travaillons dessus et allons être aussi ouvert que possible tout en ayant une activité viable. Nous allons continuer à respecter les licences et à contribuer à la technologie ouverte des imprimantes 3D, dont certaines sont de notre initiative. Nous ne voulons pas abuser de la bonne volonté et du soutien de notre communauté. Nous aimons ce que nous faisons, nous aimons partager et nous aimons ce que notre communauté invente. J’ai l’intime conviction que les entreprises qui partagent seront celles qui réussiront demain et je ne pense pas que ce soit un secret. Ces jours-ci, même des sociétés comme Google et IBM se lancent dans l’open source et trouvent de nouvelles manières de partager.

J’attends avec impatience de pouvoir parler avec les gens du Open Hardware Summit pour voir comment MakerBot peut partager autant que possible, donner du travail à ses 150 employés, produire du hardware fabuleux, et rester pérenne. Est-ce que nous devrons expérimenter pour rendre cela possible ? Oui, et cela va demander beaucoup de collaboration, de coopération, et de compréhension.

J’aimerais qu’il y ait plus d’exemples de grandes entreprises prospères dans le domaine du matériel « ouvert ». D’un point de vue commercial, nous avons été ouvert de manière absurbe, plus ouverte que n’importe quelle autre entreprise que je connais. Il n’y a pas de modèles ou de sociétés que je connaisse qui ait plus de 150 employés et qui soient plus ouverte que nous (je serais ravi d’avoir tort, mais je ne le pense pas). Nous expérimentons la manière d’être aussi ouvert que possible tout en ayant toujours un travail à la fin de la journée. Allons-nous réussir ? Je l’espère, mais même si ce nest pas le cas, tout le monde va découvrir qu’être aussi ouvert que possible est une bonne chose pour les affaires ou bien que personne ne devrait le faire, ou quelque chose entre les deux.

Personnellement, j’espère que nous réussirons, et pas seulement parce que j’aime ce que les gens font avec produits MakerBot et que j’adore les employés qui fabriquent ces machines, mais parce que je crois que MakerBot en tant qu’entreprise peut créer un nouveau modèle riche d’enseignements. Mais je n’ai pas l’intention de laisser les vulnérabilités de l’open hardware détruire ce que nous avons créé.

Des business que je connais, liés à l’open source hardware, ceux qui ont du succès sont ceux qui créent des projets éducatifs. Adafruit, Evil Mad Science et Sparkfun font des choses fabuleuses. Des entreprises comme Chumby et OpenMoko n’y sont pas parvenus, malgré le fait que des gens vraiment intelligents y étaient impliqués. Un grand nombre des projets hardware sur Kickstarter sont open source, mais je n’en ai vu aucun qui tienne le passage à la production industrielle. Encore une fois, je suis preneur de n’importe quel exemple réussi d’une grande entreprise de matériel open source. Il y a quelque chose de très intéressant à observer là dedans. Les entreprises hardware qui ont le plus de succès sont celles qui font des projets en étant open source.

Nous allons continuer à contribuer aux projets que nous avons démarré et à d’autres projets open source. J’ai été un fan de l’EFF et la FSF depuis suffisamment longtemps pour respecter les licenses. J’ai été prof depuis plusieurs années et je sais que quand on partage avec une communauté respectueuse, tout le monde dans cette communauté y gagne.

Nous sommes en train de travailler activement à un programme de développement pour créer des trucs super disruptifs et innovants. Nous attendons vraiment de pouvoir trouver des moyens de créer des situations gagnant/gagnant avec des développeurs et des entreprises. Heureusement, tout le monde n’est pas là pour manger gratos, à la fois Ultimaker et plusieurs projets RepRap ont contribué à la technologie et montrent que nous pouvons bosser ensemble et reposer sur les épaules les uns des autres.

Ce n’est pas le premier changement que nous avons effectué pour devenir professionnels et ça ne sera pas le dernier.

Question 2 : Est-ce que les conditions d’utilisation de Thingiverse ont changé pour « voler » les choses des gens

Thingiverse ne vole pas. Nous avons créé Thingiverse afin qu’il soit le meilleur endroit pour partager des choses en utilisant des licences libres. Les nouvelles conditions d’utilisation, que nous avons mis en place en février de cette année, nous permettent avant tout de partager vos créations sur notre site mais aussi de nous protéger contre les entreprises et leurs avocats. Peut-on la rendre plus conviviale ? Oui, mais les honoraires d’avocats sont chers et rendre cela plus simple prend beaucoup de temps.

J’ai mis sur notre liste de choses à faire en 2013 : rendre les conditions d’utilisation plus faciles à comprendre et éviter les malentendus. Si vous êtes préoccupés par cela, faites en sorte de lire le billet que j’ai écrit plus tôt cette année sur les conditions d’utilisation de Thingiverse.

Crédit photo : Bre Pettis (Creative Commons By-Nc)

MakerBot contre Open Source – Du point de vue d’un fondateur

MakerBot vs. Open Source – A Founder Perspective

Zachary Smith – 21 septembre 2012 – Hoektronics.com
(Traduction : fcharton, KoS, Smonff, Pascal, Alex, Gatitac, @jfomhover, ProgVal, Dam, Ag3m, tanguy)

Je m’appelle Zachary Smith (aussi connu sous le pseudo de Hoeken), je fabrique des imprimantes 3D depuis 2007 en prenant part au projet RepRap. J’ai créé une organisation à but non lucratif (la RRRF, RepRap Research Foundation) dédiée à la promotion des imprimantes 3D. En 2009, j’ai convié mes amis Adam Mayer et Bre Pettis à se lancer dans la fabrication d’imprimantes 3D. Partant de là, MakerBot Industries était né. Revenons-en à avril 2012, quand j’ai été poussé à la porte de l’entreprise du même nom. Aujourd’hui, je n’ai aucune information sur le fonctionnement interne de l’entreprise que j’ai créé. Allez voir cet article de Chris Thompson pour plus d’informations.

Je ne soutiens aucun mouvement qui restreint la nature libre du MakerBot, qu’il s’agisse de matériel, d’électronique, de logiciel, de firmware, ou d’aucun autre projet ouvert. MakerBot a été créé sur les bases de projets de matériel libre, tels que RepRap ou Arduino, aussi bien que d’autres projets logiciels libres pour le développement de notre propre logiciel. Je reste dévoué au mouvement de l’open source, et je crois aux idéaux et buts de l’Open Source Hardware. Je n’ai jamais dévié de cette position et j’espère que je ne le ferai jamais.

Je réserve mon jugement jusqu’à ce qu’on entende quelque chose d’officiel de la part de MakerBot sur la nature open source (ou pas) de sa dernière imprimante. J’essaie de rentrer en contact avec les gens pour comprendre, mais jusqu’à présent personne ne parle, et mes ex-partenaires n’ont pas répondu à mes appels téléphoniques ou mes e-mails. Cela ne sent pas bon. La meilleure information que j’ai trouvée est un tas de conneries issues du double langage d’entreprise (NdT : le « tas de conneries » c’est justement la traduction ci-dessus « Corriger la désinformation avec de l’information » !).

Si ces allégations se révèlent vraies, ce serait une triste journée pour le mouvement du matériel libre. Non seulement ce serait la perte d’un grand fabriquant de matériel ouvert, mais ce serait aussi la perte d’un exemple pour le mouvement. Beaucoup de gens se sont tournés vers Makerbot en disant : « Oui, le matériel ouvert est un secteur viable, regardez la réussite de MakerBot ». S’ils ferment ces portes, alors cela donnera des arguments à ceux qui disent que le matériel ouvert n’est pas viable. Cela va aussi décourager d’autres entreprises de se lancer dans le matériel ouvert. Ce serait effectivement une bien triste nouvelle.

Personnellement, je considère les migrations vers les formats propriétaires comme la trahison ultime. Quand on m’a chassé ce n’était dû qu’à un malheureux mais classique clash de personnalités, où une personne devait partir et l’autre rester. J’ai ravalé mon égo et je suis parti parce que je savais que la société que j’avais fondé porterait mes idéaux plus loin dans le monde. Sans m’attarder sur nos différences, j’avais pensé que Bre aurait continué à suivre les principes sur lesquels nous avions fondé notre société et les mêmes principes qui avaient joués un rôle de premier plan dans le succès de notre société. Passer d’un format libre à un format propriétaire est contraire à tout ce que je défends et en tant que co-fondateur de MakerBot Industries, j’ai honte d’y voir mon nom associé.

Bre Pettis, je t’en prie, montre-moi que j’ai tort en clarifiant exactement sous quelle license Makerbot va diffuser les fichiers de conception et le logiciel. C’est tout ce que nous (la communauté) souhaitons.

Enfin, je voudrais rappeler et souligner la définition de l’Open Source Hardware, que MakerBot a approuvé. Ce document énonce en des termes très clairs ce que cela signifie être une entreprise d’open hardware. Je le laisse ici à votre jugement :

Open source hardware regroupe les conceptions Hardware réalisées publiquement et disponibles de manière à ce que n’importe qui puisse étudier, modifier, distribuer, créer et vendre un design ou un produit basé sur ce design. La source du produit hardware, le design duquel le produit est issu, est disponible sous un format choisi pour permettre de faire des modifications. Idéalement, open source hardware utilisera des composants et matériaux facilement approvisionnables, des procédés de fabrication standard, des infrastructures libres, des contenus libres de droit et des outils de design open source pour maximiser la possibilité donnée à d’autres de concevoir ou utiliser un produit hardware. Open source hardware permet à quiconque d’avoir le contrôle sur leur technologie du moment qu’elles partagent leur savoir et encourage le commerce au travers de l’échange de design libre.

Crédit photo : Mark Demers (Creative Commons By-Nc-Nd)