Parce que Tata Jeanine vient de recevoir une machine neuve pour Noël, parce que Tonton Paul a la sienne tellement vérolée (sic !) qu’il valait mieux repartir de zéro que de tenter de la nettoyer, parce que Cousin Léonard administre les postes de son lycée… nombreux peuvent être les cas de figure où l’on se trouve devant un ordinateur, qui n’est pas forcément le nôtre, dont le système d’exploitation Windows aurait besoin d’accueillir d’un coup tout plein de logiciels libres.

C’est ici que Framapack, le nouveau projet du réseau Framasoft, peut vous être potentiellement utile.

Vous vous rendez sur le site dédié à l’opération (qui n’abrite en fait qu’une seule page). Vous choisissez vos logiciels libres comme on fait son marché, parmi la sélection proposée qui compte déjà une bonne cinquantaine d’unités. Enfin vous cliquez sur la grosse flêche verte qui vous proposera de télécharger un tout petit exécutable que vous… exécuterez, et puis c’est tout !

Vous n’avez plus qu’à attendre tranquillement, comme le pingouin de notre illustration, puisque le boulot de cet unique fichier exécutable sera d’aller automatiquement chercher les logiciels un à un et de les installer tout seul sur votre ordinateur (avec la dernière version stable et l’installation par défaut de chaque logiciel choisi).

Ceci implique de nous faire confiance lorsque l’on vous assure que l’on ne rajoute évidemment aucun spyware et autres conchoncetés au passage (ce serait même plutôt le contraire puisqu’avec PDF Creator par exemple, on vous propose l’installation sans la suspicieuse barre d’outils et l’inopportun changement de moteur de recherche). Et pour accroitre la confiance, rien de tel que de placer l’application Framapack elle-même sous licence libre (GNU/GPL) sur SourceForge.

Animé par Simon Leblanc, le projet Framapack est tout jeune, avec sa version actuelle 1.0 (ou plutôt 1.0.1 pour être précis). Tous les avis, remarques, critiques, tests, rapport de bugs et propositions de participation sont bien entendu les bienvenus.

Découvrir Framapack…

Ah qu’il était doux et rassurant le temps de l’informatique à grand-papa où nous avions nos ordinateurs fixes qui se connectaient de temps en temps et où nous luttions avec confiance et enthousiasme contre le grand-méchant Microsoft !

Ce temps-là est révolu. Nous entrons dans une autre décennie et il se pourrait bien que le principal sujet de conversation de la communauté du logiciel libre dans les dix ans à venir ne soit plus Microsoft (symbole du logiciel propriétaire, j’ai mal à mes fichiers !) mais Google (symbole de l’informatique dans les nuages, j’ai mal à mes données personnelles !)^[1].

Firefox, bouffé par Chrome ? Ubuntu, court-circuité par Chrome OS ? Le Web tout entier se transformant petit à petit en un fort joli Minitel 2.0 bourré de services Google à tous les coins de rue ? Ces différents scénarios ne relèvent pas forcément de la science-fiction.

Le problème c’est que nous n’avons plus un Microsoft en face d’une limpide ligne de démarcation. Le problème c’est que nous avons affaire à rien moins qu’au premier contributeur open source de la planète. Et cela rend légèrement plus complexe le positionnement…

La plus grande entreprise mondiale de l’open-source ? Google

World’s biggest open-source company? Google

Matt Asay – 16 septembre 2009 – Cnet news
(Traduction Framalang : Julien et Cheval boiteux)

Red Hat est généralement considérée comme la principale société open source de l’industrie, mais c’est une distinction dénuée de sens parce qu’elle est inexacte. Alors que les revenus de Red Hat proviennent des logiciels open source que la société développe et distribue, d’autres entreprises comme Sun, IBM et Google écrivent et contribuent en réalité à beaucoup plus de code open source. Il serait temps d’arrêter de parler d’entreprises open source et de revenir à l’importance du code open source.

L’open source est de plus en plus le socle sur lequel reposent les entreprises d’internet et du logiciel. Myspace a dernièrement fait des vagues en ouvrant les sources de Qizmt, un framework de calcul distribué (qui curieusement tourne sur Windows Server) qui active la fonction « Personnes que tu pourrais connaître » du site. Mais Myspace, comme l’a noté VentureBeat, n’a fait que rattraper la récente ouverture des sources de Tornado par Facebook.

Aucun d’eux ne le fait pour marquer des points auprès des utilisateurs branchés. S’ils le font, c’est motivé par leurs propres intérêts, qui nécessitent de plus en plus souvent d’inciter des communautés de développeurs à adopter et étendre leurs propres applications et services Web.

C’est également un moyen d’améliorer la qualité des logiciels. En adoptant les projets open source d’une entreprise, puis en l’étendant à travers ses propres logiciels open source, la qualité collective de l’open source est forte et croissante, comme le note Kit Plummer d’Accenture.

C’est cette compréhension de l’intérêt qu’il apporte et la qualité qui en découle qui a fait de l’open source une architecture essentielle pour potentiellement tous les logiciels commerciaux, ce qui signifie que Red Hat et d’autres entreprises qui ne font que de l’open source ne sont désormais plus le centre de cet univers.

Le noyau Linux est composé de 11,5 millions de lignes de code, dont Red Hat est responsable à hauteur de 12% (mesuré en termes de lignes de code modifiées). Même si l’on y ajoute le serveur d’applications JBoss Application Server (environ 2 autres millions de lignes de code) et d’autres projets Red Hat, on obtient toujours un total inférieur à d’autres acteurs.

Prenons Sun, par exemple. C’est le principal développeur derrière Java (plus de 6.5 millions de ligne de code), Solaris (plus de 2 millions de lignes de code), OpenOffice (environ 10 millions de lignes) et d’autres projets open source.

Ou bien IBM, qui a contribué à lui seul à 12,5 millions de lignes pour Eclipse, sans parler de Linux (6.3% du total des contributions), Geronimo, et un large éventail d’autres projets open source.

Google, cependant, est la société la plus intéressante de toutes, car elle n’est pas une entreprise de logiciels en soi. J’ai interrogé Chris DiBona, responsable des programmes open source et secteur public de Google, à propos des contributions de la société dans le domaine de l’open source (NdT : Cf Tout, vous saurez tout sur Google et l’Open Source sur le Framablog). Voici sa réponse :

Au bas mot, nous avons libéré environ 14 millions de lignes de code. Android dépasse les 10 millions de lignes, puis vous avez Chrome (2 millions de lignes, Google Web Toolkit (300 000 lignes), et aux alentours d’un projet par semaine sorti au cours des cinq dernières années. Vous avez ainsi quelques centaines d’employés Google qui patchent sur une base hebdomadaire ou mensuelle.

Si DiBona se garde bien de suggérer que Google soit devenu le premier contributeur open source (« disons que nous sommes parmi les premiers »), c’est néanmoins probablement le cas, en particulier lorsque l’on considère ses autres activités open source, incluant Google Code, l’hébergement du plus grand dépôt peut-être de projets open source, avec plus de 250 000 projets hébergés, dont au moins 40 000 sont actifs, sans parler de son Summer of Code. Après tout, les lignes de code, bien que fondamentalement utiles, ne sont pas nécessairement la meilleure mesure de la valeur d’une contribution à l’open source.

En fait, Patrick Finch de la fondation Mozilla estime que la meilleure contribution de Google à l’open source n’a probablement rien à voir avec l’écriture de nouveau code :

La plus grande contribution de Google à l’open-source n’est sans doute pas du code, mais de prouver que vous pouvez utiliser Linux à grande échelle sur des machines démarquées (NdT : whitebox hardware).

C’est une étape importante, et qui souligne le fait que le label « entreprise open source » est devenu quelque peu obsolète. Google ne se présente pas, à juste titre, comme une entreprise open source. L’open source fait simplement partie de leur stratégie pour distribuer des logiciels qui vont aider à vendre davantage de publicité.

Sun a tenté de se transformer en entreprise open source, mais une fois que son acquisition par Oracle aura été finalisée, cette dernière ne va certainement pas prendre ce label. Pas parce que c’est un mauvais label, mais simplement parce qu’il n’est plus pertinent.

Toutes les entreprises sont désormais des entreprises open source. Ce qui signifie aussi qu’aucune ne l’est. L’open source est simplement un élément parmi d’autres de la politique de développement et de croissance de ces entreprises, que l’on s’appelle Red Hat, Microsoft, Google ou Facebook.

Et étant donné que les entreprises du Web comme Google n’ont pas besoin de monétiser directement l’open source, on va en fait avoir l’occasion à l’avenir de voir encore plus de code open source émerger de la part de ces sociétés que ce qui a déjà été réalisé par ces traditionnelles « entreprises de logiciels open-source » que sont Red Hat, Pentaho ou MySQL.

En janvier 2008, Bruce Byfield écrivait, dans un article que nous avions traduit ici-même (Ce qui caractérise les utilisateurs de logiciels libres) : « La communauté du Libre peut se targuer d’être une méritocratie où le statut est le résultat d’accomplissements et de contributions ».

Deux ans plus tard, le même nous propose de sonder plus avant la véracité d’une telle assertion, qui ne va finalement peut-être pas de soi et relève parfois plus du mythe savamment auto-entretenu.

Et de poser en guise de conclusion quelques pertinentes questions qui si elles trouvaient réponse participeraient effectivement à combler l’écart constaté entre la théorie et la pratique.

Nos propres discours n’en auraient alors que plus de consistance et de maturité^[1].

Les projets open source et le mythe de la méritocratie

Open Source Projects and the Meritocracy Myth

Bruce Byfield – 2 décembre 2009 – Datamation
(Traduction Framalang : Olivier et Cheval boiteux)

« Ce n’est pas une démocratie, c’est une méritocratie. »

On trouve cette déclaration sur la page de gouvernance d’Ubuntu, mais les notes de version de Fedora présentent quelque chose de similaire, tout comme la page Why Debian for developers et partout où l’essence des projets libres et open source (NdT : FOSS) est débattue.

La méritocratie est un mythe, une de ces histoires que la communauté des logiciels libres et open source aime se conter. Par mythe je n’entends pas mensonge, mais cette méritocratie est une histoire que les développeurs se racontent à eux-mêmes pour les aider à se forger une identité commune.

En d’autres termes, l’idée que les logiciels libres et open source sont une méritocratie est aussi vraie que de dire que les États-Unis sont une terre d’opportunité, ou que les scientifiques sont objectifs. Pour les membres de la communauté des logiciels libres et open source cette idée est primordiale dans leur perception du système et leur perception d’eux-même, car ils ont foi en cette idée que le travail est récompensé par la reconnaissance de leurs pairs et l’attribution de plus de responsabilités

Afin de perdurer, il faut que le mythe renferme une part de vérité, et ainsi personne ne le remet en question. Des exceptions peuvent survenir, mais elles seront justifiées, voire niées.

Cependant, si les mythes de la communauté ne sont pas des mensonges, ils ne révèlent pas toute la vérité non plus. Ils sont souvent des versions simplifiées de situations bien plus complexes.

La méritocratie dans les logiciels libres et open source n’échappe, à mon avis, pas à ce constat. Selon le contexte, si vous contribuez dans un bon projet et faites les choses biens, l’aspect méritocratique des logiciels libres et open source s’ouvrira à vous, c’est souvent le cas.

Mais de là à dire que les communautés ne fonctionnent qu’au mérite, il y a un pas que je ne franchirai pas. Le mérite n’est qu’un facteur à prendre, parmi tant d’autres, le mérite seul ne vous accordera ni reconnaissance, ni responsabilités. Bien d’autres considérations, souvent ignorées, entrent en jeu.

Hypothèses contestables

En invoquant l’argument du mérite on tourne rapidement en rond, c’est l’un des problèmes d’une méritocratie. Une hiérarchie est déjà établie, oui, mais comment ? Au mérite. S’ils n’avaient pas de mérite, ils n’auraient pas leur place.

Pas besoin de chercher bien loin pour voir que seul le mérite ne compte pas dans la hiérarchie des logiciels libres et open source. Les fondateurs du projet, en particulier, ont tendance à conserver leur influence, peu importe l’importance de leurs dernières contributions… si tant est qu’ils contribuent toujours au développement.

Par exemple, lorsque Ian Murdock fonda Progeny Linux Systems (entreprise pour laquelle j’ai travaillé) en 2000, il n’avait pas participé au projet Debian depuis quelques années. Et malgré cela, lorsque l’entreprise s’intéressa à Debian, son statut n’avait pas bougé. Tout portait à croire qu’il n’allait pas s’impliquer personnellement dans le projet et pourtant, s’il n’avait pas refusé la proposition, on lui aurait malgré tout attribué le titre de Debian Maintainer sans passer par le processus habituel.

Plus récemment, Mark Shuttleworth est devenu dictateur bienveillant à vie pour Ubuntu et Canonical, non pas à cause de ses contributions aux logiciels libres, mais parce qu’il disposait de l’énergie et de l’argent pour se propulser à ce rang. Sa position au sein d’Ubuntu ou de Canonical n’est pas remise en cause, mais toujours est-il qu’elle ne doit rien au mérite (au sens où l’entend la communauté), mais plutôt à son influence.

Et les leaders ne sont pas les seuls à gagner de l’influence pour des raisons autres que leur mérite. Dans les projets où certains contributeurs sont rémunérés et d’autres bénévoles, les contributeurs rémunérés ont presque toujours plus d’influence que les bénévoles. Dans certains cas, comme sur le projet OpenOffice.org, les contributeurs salariés peuvent presque entièrement éclipser les bénévoles.

D’autres projets, comme Fedora, repartissent l’influence plus équitablement, mais les contributeurs payés occupent souvent des postes à responsabilité. Par exemple, des dix membres du comité d’administration de Fedora, sept sont des salariés de Red Hat. Idem pour openSUSE où trois des cinq membres du comité sont des employés de Novell, le principal sponsor du projet, et un autre est consultant spécialisé dans les produits Novell. Et la situation est similaire dans bon nombre d’autres projets.

Alors oui, vous allez me dire que les membres payés ont plus de temps à accorder à ces responsabilités. C’est juste, mais ce n’est pas le sujet. Le fait est que les membres payés occupent statistiquement plus de postes à responsabilité que les bénévoles. Et c’est toute le postulat de départ qui est remis en cause, on constate alors que votre statut dans le projet n’est pas directement déterminé par votre mérite.

D’autres moyens de se faire remarquer

La méritocratie semble être le système parfait en théorie. Mais le fait est que la théorie est rarement mise en pratique. Avant de le reconnaître, encore faut-il déjà définir ce qu’est le mérite, la communauté des logiciels libres et open source ne fait pas exception.

Bâtie sur le code, la communauté des logiciels libres et open source valorise principalement la capacité à coder, bien que les plus gros projets soient beaucoup plus variés : tests, rédaction de la documentation, traduction, graphisme et support technique. De nombreux projets, comme Fedora et Drupal, évoluent et tentent de gommer cet a priori, mais cela demeure vrai pour la plupart des projets. Ainsi, les noms connus dans les projets ou les personnes qui font des présentations lors des conférences sont majoritairement des développeurs.

Cet a priori est cependant justifié. Après tout, sans le code, le projet de logiciel libre ou open source n’existerait pas. Et pourtant, le succès du projet dépend autant des autres contributions que du code lui-même.

Et comme le fait remarquer Kirrily Robert, blogueur chez Skud, même si certaines contributions sont moins estimées que d’autres, ça n’est pas une raison de les occulter complètement.

Par exemple, la personne la mieux placée pour écrire la documentation pourrait bien être le chef du projet, mais peut-être alors a-t-il mieux à faire que de rédiger la documentation. Il vaut peut-être mieux qu’une autre personne, même moins douée, rédige la documentation. Dans ce cas, celui qui écrit la documentation devrait être remercié, non seulement pour son travail, mais aussi parce qu’il libère l’emploi du temps du chef du projet. Et pourtant ceci est rarement reconnu dans les projets de logiciels libres ou open source.

L’idée que le mérite soit remarqué, reconnu et recompensé est rassurante dans notre culture industrielle moderne. J’aurai même tendance à penser que c’est encore plus rassurant dans le cercle des logiciels libres et open source, dont de nombreux membres admettent être introvertis, voire même se diagnostiquent eux-mêmes comme étant victime du syndrome d’Asperger.

Mais le mérite est-il toujours reconnu dans les logiciels libres et open source ? Voici ce que Noirin Shirley écrit à propos des obstacles à franchir par les femmes pour participer à cet univers :

Souvent, les valeurs reconnues dans une méritocratie deviennent rapidement le couple mérite/confiance en soi et obstination, dans le meilleur des cas. « Le travail bien fait ne vous apporte pas d’influence. Non, pour gagner de l’influence il faut faire du bon travail et bien s’en vanter, ou au minimum le rappeler à tout le monde régulièrement. » Les femmes échouent à cette étape là.

Shirley suggère ici qu’il faut non seulement être bon et régulier, mais il faut aussi savoir se rendre visible sur les forums, chats et listes de discussion, ainsi qu’aux conférences. Puisque les femmes sont apparemment conditionnées culturellement pour ne pas se mettre en avant, elles sont nombreuses à ne pas être à leur avantage dans un projet de logiciel libre ou open source (idem pour les hommes manquant de confiance en eux). Si elles ne peuvent ou ne souhaitent pas s’auto-promouvoir un minimum, leurs idées peuvent passer inaperçues, être sous-estimées ou carrément écartées.

À l’inverse, selon la même logique, certains gagnent en autorité plus parce qu’ils sont sociables ou opiniâtres que pour ce qu’ils réalisent concrètement (j’ai quelques exemples en tête, mais je ne veux pas faire d’attaque personnelle).

Tout comme la démagogie peut pervertir la démocratie, l’auto-promotion peut pervertir la méritocratie. Si un projet n’y prend pas garde, il se retrouvera bien vite à accepter des contributions, non pas sur la base de leur qualité, mais à cause de la visibilité et de l’insistance de celui qui les propose.

L’attraction sociale et comment s’y soustraire

Dans Le mythe de la méritocratie, Stephen J. McNamee et Robert K. Miller, Jr. avancent que la méritocratie aux États-Unis est influencée par ce qu’ils nomment l’attraction sociale. Ce sont des facteurs comme l’origine sociale ou l’éducation qui peuvent modifier positivement ou négativement la perception qu’ont les autres de nos contributions.

D’après moi, l’attraction sociale touche aussi la communauté des logiciels libres et open source, pas simplement parce qu’elle fait partie de notre société industrielle moderne, mais pour des facteurs qui lui sont propres. Reconnaître son existence n’est pas forcément facile, mais ça n’est pas pour autant une remise en cause de la méritocratie dans les logiciels libres et open source. L’importance du travail réalisé par les contributeurs n’en est pas non plus amoindrie.

Au contraire, reconnaître l’existence de l’attraction sociale peut être un premier pas pour améliorer la méritocratie dans le monde des logiciels libres et open source.

Kirrily Robert émet une idée intéressante. À l’instar des auditions anonymes où les musiciennes sont plus facilement choisies lorsque le sexe de la personne qui postule n’est pas connu, Robert propose que les soumissions soient également anonymes afin que leur évaluation ne soit pas biaisée. Si l’augmentation des contributions féminines lui tient à cœur, ces soumissions anonymes pourraient aussi garantir que seul le mérite entre en ligne de compte pour chaque contribution.

Mais ce n’est là qu’une proposition. Si vous voulez que la communauté des logiciels libres et open source devienne véritablement méritocratique, alors elle doit avoir le courage se poser quelques bonnes questions.

Pour commencer, par quel autre moyen peut-on réduire l’importance de l’auto-promotion ? Comment peut-on s’assurer que les employés et les bénévoles soient réellement au même niveau ? Peut-on redéfinir le mérite pour qu’il ne reflète pas uniquement ce qui est lié au code, mais au succès global du projet ?

Répondre à ces questions n’affaiblira pas le principe du mérite. Au contraire, ce principe de base de la communauté devrait en ressortir renforcé, et mieux utilisé. Et c’est, sans aucun doute, ce que souhaite tout supporter des logiciels libres et open source.

Paint.NET^[1] est un très bon logiciel libre de retouches d’images pour Windows. De l’avis de beaucoup, bien plus « sexy » et accessible au grand public que Gimp par exemple.

Sauf qu’il possède deux défauts, un petit et un bien plus grand, éliminatoire même. Il nécessite, comme son nom l’indique, l’implémentation préalable du framework .NET de Microsoft, mais surtout il a très vite été un logiciel libre contesté qui n’avait en fait de logiciel libre que le nom, ou plutôt « que » la licence (en l’occurrence la licence MIT).

Contrôle du code, communauté inexistante et absence des dernières version des sources à télécharger, faisaient en effet de ce logiciel un exemple emblématique de « fauxpen source ». De l’aveu même de Rick Brewster, son unique développeur : « le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non sollicitées ». Il appelle d’ailleurs cela un logiciel « released sources ».

Aujourd’hui les choses sont clarifiées. Rick Brewster a décidé il y a un mois de changer la licence pour en faire un vrai logiciel propriétaire gratuit (ou freeware). « You may not modify, adapt, rent, lease, loan, sell, or create derivative works based upon the Software or any part thereof », peut-on lire sur l’article de son blog qui annonce la nouvelle.

Cette nouvelle n’est pas forcément bonne (un logiciel qui quitte la lumière pour rejoindre le côté obscur de la force) mais elle est logique et cohérente vue l’évolution de l’application. Il nous a cependant semblé intéressant de traduire cet article, d’abord pour mieux comprendre les motivations de cette migration à contre-courant, mais aussi parce que les arguments avancés sont autant de justifications plus ou moins convaincantes qui vous feront peut-être réagir dans les commentaires.

Une nouvelle licence pour Paint.NET 3.5

A new license for Paint.NET v3.5

Rick Brewster – 9 novembre 2009 – Blog personnel
(Traduction Framalang : Jimbo)

Au fil des années, j’ai été obligé de me battre avec un certain nombre de personnes, et de sociétés, qui tentaient de plagier Paint.NET en recompilant le programme sous une dénomination commerciale différente et en insérant leur propre nom dans les crédits. Parfois, ils se faisaient payer pour ce service. J’ai même créé mon propre terme pour désigner cela : un « backspaceware » (NdT : en français cela donnerait quelque-chose comme « effaciciel », le backspace étant la touche « retour en arrière », qui permet d’effacer le dernier caractère tapé). En outre, de temps en temps, on trouve Paint.NET en vente sur eBay.

Et, comme beaucoup d’entre vous le savent, Paint.NET était open source. Ou plutôt, il était « released sources » (NdT : C’est-à-dire « sources publiées ») : le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non-sollicitées. J’aimais publier le code source, parce qu’il me semblait bon de permettre à d’autres de l’étudier. Il y a environ un an, fatigué de voir ces versions plagiées de Paint.NET et j’ai décidé de retirer le code source du site Web. Cependant le code source était toujours dans la nature en différents endroits d’Internet (ce qui n’est guère illégal). Même sans le code source, une personne maline et douée pouvait probablement encore décompiler, modifier puis recompiler le programme, afin de lui faire dire ou faire ce qu’elle voulait.

Le plus gros problème était que, même si ces actions déplorables manquaient clairement d’éthique, le licence MIT autorisait tout cela. Ou, du moins, dans certains cas particuliers, ce qu’elle interdisait n’était pas clair. Donc, d’un point de vue juridique, ce qui pouvait précisément être entrepris à ce sujet n’était pas clair. Je ne suis pas juriste et je ne voulais pas dépenser des milliers de dollars pour avoir une explication de tout cela. Quelques personnes ont affirmé que j’avais choisi la mauvaise licence et, avec le recul, c’est sans aucun doute exact.

En outre, tout ceci va plus loin que le plagiat ou ma propre tension artérielle. La publication de copie dérivées de Paint.NET est source de confusion et perturbe la plupart des utilisateurs. J’ai reçu des e-mail de personnes troublées parce qu’elles pensaient que Paint.NET avait été renommé et que des fonctions manquaient dans « la nouvelle version ». Ces copies dérivées provoquent du désordre puisque souvent elles désinstallent le vrai Paint.NET (avec la même interface graphique que pour l’installation Windows) tout en conservant le système de mise à jour d’origine. Ce qui signifie que lorsque vous installez une telle copie dérivée, elle supprime Paint.NET, et puis lorsque Paint.NET est mis à jour, il désinstalle la version dérivée et la remplace par Paint.NET, etc… Ou la version modifiée plante, et le rapport de bugs indique à l’utilisateur de l’envoyer à mon adresse mail. Il y a aussi a risque réel de trojans et de virus.

Tout est désormais fini.

Pour la version finale de Paint.NET 3.5, qui ne devrait plus tarder, j’ai modifié la licence. Pour la plupart des utilisateurs, cela n’aura aucun impact. C’est toujours un freeware. Il n’y a toujours aucune prétention sur les fichiers créés, ouverts ou sauvés avec Paint.NET. Vous pouvez toujours établir un miroir du fichier zippé à télécharger sur votre site web (par exemple Betanews, Download.com, etc.) sans en demander la permission. Vous pouvez toujours vendre des trucs que vous créez avec Paint.NET (pour autant que vous ayez le droit de le faire bien sûr). Vous pouvez continuer à utiliser dans un contexte commercial, et à l’installer sur autant de machines que vous le désirez.

Cependant, la licence spécifie que vous ne pouvez plus modifier Paint.NET lui-même, ou créer une œuvre dérivée basée sur le logiciel Paint.NET (c’est-à-dire un logiciel dérivé). Vous ne pouvez pas non plus le vendre. Je ne pense pas que cela aura un impact sur quiconque d’autre que ceux qui désirent plagier ou détrousser Paint.NET. Je ne vais implémenter aucune restriction quant au reverse engineering ou la décompilation, par exemple à l’aide de Reflector. Je pense que ce serait bête, et je crois encore de tout mon cœur qu’il est bon qu’on soit capable d’étudier le code de Paint.NET, quand bien même il ne s’agit que du démontage approximatif fourni par Reflector. Toutefois, vous n’êtes pas autorisé à modifier et recompiler une nouvelle version de Paint.NET à partir de ce démontage.

Cette décision créera à n’en pas douter de la confusion. Par exemple, « Est-ce que les plugins sont autorisés ? ». Oui, absolument: le programme est conçu pour accepter ces dernier et ils ne constituent pas une modification de Paint.NET lui-même. Je devrai certainement mettre la FAQ à jour sur cette question, comme sur d’autres.

Je m’attends à ce qu’il y ait une minorité bien en voix qui condamne ce changement de licence. Avant de vous exprimer, veuillez vous poser cette question : cela vous touche-t-il réellement ? Comptiez vous vraiment faire quelque chose que cette nouvelle licence interdit ? Je parie que la réponse est « non », mais, je vous en prie, postez un commentaire si la réponse est un véritable oui. Beaucoup de personnes ont condamné ma décision de supprimer le code source mais après enquête, il s’est avéré que c’était une pure question de principe : elles n’avaient jamais téléchargé le code source, jamais rencontré quelqu’un qui l’avait téléchargé, et jamais prévu de faire quoi que ce soit qui tirerait profit ou dépendrait de l’accès au code source. Je comparerai cela à être contrarié par le fait que votre passeport vous interdit de voyager en Antarctique : comptiez-vous vraiment vous rendre là-bas un jour ?^[2]

L’autre décision que je compte prendre est de publier le code source de portions de Paint.NET 3.5, probablement sous une licence de type MIT ou BSD. Les développeurs de plugins gagneraient en effet beaucoup à disposer du code source des effets graphiques et de certaines commandes relatives à l’interface WinForms. La meilleure façon de résumer les choses est de dire que la nouvelle licence (NdT : Voir les termes de la nouvelle licence sur l’article d’origine) couvre les « binaires », c’est-à-dire « ce que vous venez de télécharger et d’installer ». Je peux toujours créer des paquets à télécharger qui sont couverts par d’autres termes de licence. D’un point de vue de la philosophie, c’est peut-être déroutant, mais je suis prêt à en payer le prix.

Le code informatique écrit par des femmes serait-il plus « utile » que celui des hommes ?

C’est en tout cas ce qui ressort de ce récent article d’un blog du Wall Street Journal.

Il serait en effet mieux documenté et par là-même plus facilement exploitable par d’autres développeurs^[1].

L’occasion d’évoquer aussi peut-être dans les commentaires la problématique de l’écart des sexes dans le secteur informatique en général et dans la communauté du logiciel libre en particulier…

Les hommes écrivent du code provenant de Mars, et les femmes du code plus utile venant de Vénus.

Men Write Code from Mars, Women Write More Helpful Code from Venus

Rebecca Buckman – 6 juin 2008 – The Wall Street Journal
(Traduction Framalang : GaeliX et Burbumpa)

Nous savons tous que les hommes détestent demander leur chemin. Apparemment, ils détestent tout autant indiquer les directions dans le code informatique.

Emma McGrattan, première vice-présidente en ingénierie de la société Ingres spécialisée en bases de données, l’une des femmes développeuses les plus cotées de la Silicon Valley, insiste sur le fait qu’hommes et femmes ne codent pas de la même façon. Les femmes sont plus sensibles et plus attentives à ceux qui pourraient utiliser leur code ultérieurement. Elles parsèment leur code, vous savez, ces lignes d’instructions qui donneront naissance à d’astucieuses applications et programmes, de commentaires et consignes, expliquant avec précision pourquoi elles ont écrit leur code de cette façon là.

Le code devient alors une sorte de « feuille de route » pour ceux qui voudraient le modifier ou l’étendre par la suite, ajoute McGrattan, irlandaise de souche ayant rejoint Ingres en 1992.

Les hommes, d’un autre côté, n’ont pas les mêmes motivations. Souvent, « ils essayent de montrer combien ils sont intelligent en produisant du code cabalistique » dit-elle sur le blog Business Technology. « Ils essayent de dissimuler des choses dans le code », et ne laissent pas de consignes claires pour les futurs utilisateurs. McGrattan se targue de pouvoir, dans 70% à 80% des cas, déterminer à partir d’un morceau de code s’il a été écrit par un homme ou par une femme.

Par souci de rendre le code d’Ingres plus facile à utiliser et dépourvu de genre sexuel, McGrattan a aidé à la mise en œuvre de nouveaux standards de programmation au sein de la société. Elle demande aux développeurs d’inclure un certain nombre de commentaires précis avant chaque portion de code, expliquant ce que chacun fait et pourquoi; les développeurs doivent aussi fournir un historique détaillé de chaque changement effectué. Ces règles s’appliquent aussi bien aux employés d’Ingres qu’aux membres de la communauté Open Source qui participent au code des produits Ingres.

Il y a grand besoin de modifier le code à haute teneur en testostérone chez Ingres car seulement 20% des ingénieurs sont des femmes, précise McGrattan, la plupart d’entre elles ayant des postes liés à l’assurance qualité ou à l’adaptation à un nouveau pays et non à la programmation de haut vol.

Elle s’est donnée comme mission d’intéresser plus de femmes aux carrières dans le développement. Mais « cela s’avère très difficile » conclut-elle.

Petite traduction pédagogique sans prétention illustrant la paralysie qui affecterait Internet si le logiciel libre n’était plus là, permettant par là-même au grand public de se rendre compte par la négative de son importance et de sa diffusion^[1].

En fait si le logiciel libre n’existait pas il faudrait l’inventer…

A Day Without Open Source

William Hurley – 9 mai 2007
(Traduction Framalang : HL et Don Rico)

J’étais à une conférence quand deux techniciens entrèrent dans la salle de bar, l’un favorable au logiciel libre, l’autre résolument contre. Ils mirent le moulin en route après quelques verres et Mr Contre remarqua d’une voix forte : « Le logiciel libre, je voudrais bien que ça dégage ! Ça crée plus de problèmes que ça n’a d’avantages.» Déclarations avec lesquelles, de toute évidence, j’ai quelques difficultés. Bon, je sais que la plupart des gens ne comprennent pas le rôle du logiciel libre dans notre monde, ou ignorent combien de services que nous tenons pour acquis disparaitraient sans sa présence. Si vous êtes membre du club, vous voyez probablement où je veux en venir.

Imaginons qu’au douzième coup de minuit, tout logiciel libre s’évapore comme par magie. Qu’est-ce qui fonctionnerait encore demain ? Pour commencer, Internet « disparaîtrait » pour l’utilisateur moyen. La plupart des serveurs de nom de domaines (DNS) fonctionnent sous des logiciels libres comme BIND, qui transforme www.framablog.org en une adresse IP du serveur adéquat. On perdrait en route la majorité des utilisateurs de base d’Internet. Bien sûr, BIND n’est pas le seul logiciel libre pour les DNS. Et toutes les solutions logicielles pour DNS ne sont pas libres.

Mais supposons que les DNS fonctionnent toujours, ou que par hasard vous avez mémorisé 72.14.207.99 au lieu de www.google.com. Même si les serveurs de noms de domaines fonctionnaient, Google disparaîtrait complètement d’Internet. Google tourne essentiellement sous Linux – qui est sans doute le plus populaire des systèmes d’exploitation libres de la planète. Pas de souci. Vous n’avez qu’à aller voir chez Yahoo!, Pas vrai ? Eh bien non. Yahoo! est l’un des plus grands consommateurs d’un autre système d’exploitation très répandu issu du libre : FreeBSD. A présent, vous vous êtes résigné à essayer 207.68.172.246. Nous savons tous qu’ils n’utilisent pas de logiciel libre, et qu’ils s’échinent depuis un bout de temps sur cette fonction de recherche.

OK, MSN est là, paré à la manoeuvre, alors maintenant lançons une recherche. J’ai entendu un remix sympa de Shakira à la radio ce matin, c’est ce que je vais rechercher. MSN me renvoie une liste de sites qui proposent la chanson… Je clique dessus… et… rien. Pas de dance music ? Pas de rythmes latinos ? Plus de 60% des sites Internet tournent sous Apache, un serveur web issu du libre. Avant même que je ne clique sur un lien, mes chances de succès ont été réduites à 4 sur 10.

Sur les 118 023 363 sites recensés jusqu’à présent par NetCraft ce mois de mai, un petit peu plus de 70 millions ne fonctionneraient plus si le logiciel libre venait à disparaître. Certes, Apache n’est pas le seul seveur web issu du libre et… Vous connaissez la suite. Je pourrais continuer des heures et des heures sur vos transactions en ligne, qui ne pourraient être sécurisées sans OpenSSH et OpenSSl et tous les autres services auxquels des utilisateurs ont recours tous les jours et qui, selon ce scénario, n’existeraient pas.

Le logiciel libre n’est pas une nouvelle tendance. Ce n’est pas un phénomène de mode éphémère. Il est partout, que vous le reconnaissiez ou non. De Linux intégré aux nouveaux routeurs sans fil en passant par Firefox, le navigateur libre le plus utilisé au monde, le logiciel libre est la force motrice d’Internet et d’innombrables autres technologies.

Vous savez déjà que je suis un inconditionnel du libre, mais vous, qu’en pensez-vous ? J’aimerais connaître votre avis sur la façon dont la disparition du logiciel libre vous affecterait.

Pensez-vous par exemple que la pléthore de distributions GNU/Linux soit une qualité de l’OS et le témoignage de la vivacité de sa communauté ou bien au contraire qu’on aboutit à une situation confuse où trop de choix tue le choix ?

Sur cette thématique assez classique de la pertinence de la pluralité du choix, voici la traduction d’un article (un peu technique mais fort intéressant) d’un développeur américain James Turner sur le site d’O’Reilly.

Extrait :

Alors, quels sont les avantages d’une monoculture et pourquoi Microsoft gagne-t-il si souvent quand les gens doivent choisir une plateforme ? C’est en grande partie à cause de ce que la communauté open source voit comme une force mais que ceux qui essaient de faire leur boulot dans le monde réel voient comme une faiblesse. Nous célébrons la diversité de choix disponibles pour résoudre un problème et nous appelons cela la liberté. Les directeurs informatiques et les patrons de la branche informatique (IT managers et CIOs en anglais) y voient du chaos, de la confusion et des doutes.

Pour ceux qui comme nous sont attachés à la liberté, avoir le choix est bien entendu une valeur fondamentale. Mais il peut en aller autrement dans le monde pragmatique de l’informatique professionnelle où c’est souvent l’efficacité qui est privilégié. Et alors dans ce contexte Microsoft conserve de sérieux atouts avec ses offres monoculturelles sécures et rassurantes^[1].

Les vertus de la monoculture

The Virtues of Monoculture

James Turner – 24 avril 2007 – Opinion
(Traduction Framalang : Don Rico et Yostral)

Je ne dis certainement rien de nouveau ici, mais j’ai pensé que je pourrai partager quelques réflexions sur les raisons qui poussent les gens à suivre la voie Microsoft. J’ai récemment fait quelque chose dans mon travail de tous les jours auquel je pensais depuis longtemps, mais pour lequel je n’ai jamais vraiment pris la peine d’aller jusqu’au bout, je me suis inscrit pour participer à un projet Microsoft-centrique et pour apprendre le .NET.

J’avais fait des tentatives avortées par le passé pour apprendre à coder dans l’Univers Microsoft. J’avais fait un essai à la sale époque des COM, mais le nombre de numéros qu’on me demandait d’exécuter me demandait trop d’effort par rapport à ce que j’étais alors prêt à consentir. Depuis j’ai gardé ce mauvais goût au fond de la bouche et j’ai refusé d’ajouter une seul compétence Microsoft à mon répertoire, même si cela représentait parfois un vide dans mon curriculum vitæ.

J’ai souvent travaillé dans des environnements où il y avait ce Monsieur Microsoft, l’évangéliste qui vous répète sans cesse à quel point ça aurait été plus facile en .NET. Je les ai classés dans la catégorie adorateurs de Gates buveurs de Tang*. Mais, à la fin de la journée, je me suis dit que si je devais les critiquer je devais vraiment comprendre leur monde. Connais ton ennemi et tout ça.

J’ai passé la semaine dernière à apprendre dans l’ordre C#, .NET et VSTO (c’est Visual Studio Toolkit for Office, si les abréviations de Microsoft ne sont pas votre tasse de thé). J’ai utilisé le livre Learning C# de chez O’Reilly et j’ai fait quelque chose qui m’arrive rarement : je m’y suis mis de manière très méthodique (du moins pour la première moitié).

Et devinez quoi? Microsoft possède dans ses mains une suite de développement plutôt bonne. Pour être honnête, C# est vraiment ce que je ferai si je pouvais complètement ré-écrire Java sans me soucier de la compatibilité descendante. Il y a quelques fonctionnalités vraiment sympas, comme les mots-clés virtual, override, et new qui vous permettent de spécifier ce qu’il se passe lorsque vous transtypez une classe dans sa classe de base et que vous appelez une méthode qui est définie dans les deux.

Visual Studio est un outil habile qui vous permet vraiment de créer des applications (et avec VSTO des ajouts pour Office) en deux temps trois mouvements. ADO.NET n’est pas pire que JDBC et s’intègre de manière transparente dans Visual Studio. J’ai été capable, arrivé à la fin de la semaine, de développer des applications autonomes et des ajouts pour Office qui étaient capable de dialoguer avec les bases de données en n’ayant écrit que peu de code. D’après ce que j’en ai vu, ASP.NET réalise la même chose pour les applications web MVC (NdT : Model View Controller).

Alors, quels sont les avantages d’une monoculture et pourquoi Microsoft gagne-t-il si souvent quand les gens doivent choisir une plateforme ? C’est en grande partie à cause de ce que la communauté open source voit comme une force mais que ceux qui essaient de faire leur boulot dans le monde réel voient comme une faiblesse. Nous célébrons la diversité de choix disponibles pour résoudre un problème et nous appelons cela la liberté. Les directeurs informatiques et les patrons de la branche informatique (IT managers et CIOs en anglais) y voient du chaos, de la confusion et des doutes.

Est-ce que je devrais utiliser iBatis ou Hibernate? XFire ou AXIS? Perl, PHP ou Ruby? Debian, Fedora, Ubuntu ou Suse? Si vous prenez la mauvaise décision vous pouvez perdre énormément de temps, comme nous l’avons découvert sur un projet récent où nous avons gâché une semaine à essayer de faire marcher AXIS2 pour un projet de service web pour finalement nous rendre compte que XFire était ce qu’il nous fallait.

Pour Monsieur Microsoft cette confusion n’existe pas. Vous utilisez ADO.NET, ASP.NET, C# et Windows. Ils fonctionnent tous, ils sont tous bien documentés du point de vue des besoins des développeurs, sans un seul regarde le code source désobligeant. A chaque fois que je pensais que j’allais être bloqué il y avait une douzaine d’articles expliquant comment faire exactement ce que je voulais faire, avec un exemple de code qui était à jour avec les versions du logiciel que j’utilisais et qui répondait vraiment au problème que je cherchais à résoudre.

Microsoft apporte le confort de ne pas avoir à choisir. Avoir le choix n’est pas toujours bon et la communauté open source offre parfois bien trop de manières différentes de plumer un canard, des choix qui sont pris plus par fierté, ego ou entêtement que par une authentique nécessité d’avoir deux alternatives différentes. Je ne montrerai personne du doigt, tout le monde connaît des exemples.

En fait, à moins que vous ne pensiez que je me sois tourné vers le Côté Obscur, le GROS problème avec une monoculture, c’est que vous vendez plus ou moins votre âme pour la stabilité d’un ensemble de choix défriché pour vous. En empruntant le chemin .NET, en gros, vous vous y perdez à tout jamais, et ce malgré Mono. Vous travaillerez toujours sur une plateforme Windows. Vous avez le joli anneau en or, mais Sauron tire les ficelles et vous fait danser. Pour beaucoup d’entreprises, celles qui n’ont pas besoin de se soucier du déploiement dans un environnement hétérogène, c’est un pacte qu’elles sont plus que prêtes à conclure.

Voici ce que je retiens de toute cette réflexion : en quelque sorte, nous devons commencer à faire le tri. La massue de 350kg pour faire entrer certaines idées dans les têtes devrait être mise à disposition pour marteler les têtes de ceux qui fourchent (NdT : qui créent un fork une déviation indépendante d’un projet) pour la seule et unique raison qu’ils ne sont pas en accord avec la licence, ou de ceux qui prennent les décisions. Quand on entend parler de deux (ou plus) projets qui répondent à la même problématique, on devrait se demander « Pourquoi ne mettent-ils pas en commun leurs efforts pour fournir une très bonne solution? » plutôt que de célébrer la diversité uniquement pour l’amour de la diversité.

A-ton vraiment besoin de Ruby on Rails ET de Groovy on Grails? Quand ils ont annoncé le poisson d’avril de Python on Planes j’ai mis quelques secondes pour réaliser que c’était un canular, parce que c’est exactement le genre d’effort faire quelque chose pour l’amour de le faire qui fractionne la communauté des logiciels open source. Il n’y a aucun moyen d’empêcher les gens de commencer des projets en double, et nous ne le voudrions pas, mais bon sang, doit-on l’encourager activement ?

On passe beaucoup de temps à se plaindre des moyens démoniaques qu’emploie Microsoft pour s’imposer partout. En faisant cela, nous nous lavons automatiquement de toute responsabilité que nous pourrions nous-même porter pour leur succès ou nos échecs. Le fait est qu’il existe d’excellentes raisons pratiques qui poussent les gens dans les bras de la boîte à outil de Redmond et nous devons accepter ceci comme un fait et en tirer des leçons plutôt que d’agiter nos poings en blamant l’obscurantisme. Car nous avons trouvé notre ennemi et c’est nous, pas Microsoft, du moins pas tout le temps…

Un bon gros troll bien poilu ? Non plutôt une interrogation furtive sur le caractère réel ou mythique du logiciel libre qui serait, dit-on, principalement développé par des bénévoles passionnés^[1] sur leur temps libre.

Après une étude assez poussée des principaux contributeurs de la dernière version du noyau Linux, la 2.6.20, un récent article de LWN.net intitulé Who wrote 2.6.20? affirme :

at least 65% of the code which went into 2.6.20 was created by people working for companies

Au moins 65% du code inclu dans le noyau 2.6.20 a été créé par des personnes travaillant pour des sociétés.

C’est plus une conjecture qu’une réelle affirmation parce qu’il n’est pas toujours aisé de déterminer l’origine des contributeurs, ni de savoir si ils ont participé sur leur temps de travail ou non. La méthode de l’auteur est avant tout de prendre la terminaison de l’adresse mail des contributeurs. Si elle se termine par ibm.com alors il le fait entrer dans la catégorie "IBM". Si une telle adresse fait défaut mais qu’il est de notoriété publique qu’un tel travaille pour un tel alors il est mis lui aussi dans une case. Il va même jusqu’à envoyer directement un mail à certains contributeurs pour en savoir plus sur leur appartenance.

Cette hypothèse de travail vaut ce qu’elle vaut mais du coup l’article exhibe des tableaux avec une minorité de bénévoles (le champ None) et une majorité d’employés (pour des sociétés telles qu’IBM, Red Hat, Novell, Google, Intel, Nokia, Oracle, HP, etc..). Ce qui sous-entend que ces personnes ont développé sur leur temps de travail et donc ont été payées pour cela par leur employeur.

Il me semble évident que la majorité des logiciels libres sont encore le fruit du travail bénévole de développeurs sur leur temps libre (comme il semble tout aussi évident qu’on ne sait plus très bien ce qu’est un bénévole et son temps libre à l’ère de la société de l’information où heures de bureau et heures de travail ne coïncident plus vraiment).

Mais est-ce encore le le cas pour les gros gros projets comme le sont devenus Linux, Mozilla ou OpenOffice.org ? Et comme ce sont justement ces exemples-là qui sont le plus souvent cités pour expliquer et illustrer le logiciel libre au néophyte, ne devrions-nous pas nuancer cette image un peu romantique des développeurs bénévoles connectés les uns les autres via le réseau pour produire seuls un logiciel libre de haute qualité ?

Ne serait-il pas plus conforme à la réalité d’évoquer désormais pour eux une sorte de coopération ou convergence d’intérêts entre une communauté de bénévoles et des sociétés commerciales classiques pour produire de toutes les façons quelque chose d’ouvert qui reste dans le pot commun ?

Finalement le seul gros projet libre qui reste majoritairement bénévole ne serait-il pas… Wikipédia ?!