C’est ce qui arrive à un développeur britannique.

Il s’en réjouit et nous avec 😉

Le gouvernement britannique me paye pour faire de l’open source toute la journée

The UK government pays me to write open source all day

Jake Benilov – 17 mai 2013 – QuickPeopleBlog
(Traduction : RyDroid, goofy, @zessx, Sylvain, MFolschette, Asta, Chuckman + anonymes)

Je suis développeur. Voici le graphique récapitulant mes contributions open source sur Github pour les 12 derniers mois (les carrés verts représentent les jours où j’ai fait des commits dans des dépôts open source) :

Bien que je fasse aussi de l’open source pendant mon temps libre, la plupart de ces points verts apparaissent pendant mes heures de travail au Government Digital Service (NdT. unité gouvernementale chargée de revoir le fonctionnement des services gouvernementaux en ligne), une équipe du Bureau du Cabinet britannique.

Je ne suis pas un cas isolé dans mon équipe. Si vous jetez un coup d’œil à la page Github du GDS, vous trouverez beaucoup de code. Mieux encore, notre travail ne se déroule pas seulement en marge des TIC gouvernementales : nous sommes responsables du site GOV.UK, la principale plateforme de publication du gouvernement britannique, et l’accès principal à toutes les opérations gouvernementales.

Un point où j’ai peut être exagéré : comme James Stewart (un des directeurs développement du GDS) le souligne, le GDS fait aujourd’hui du « code ouvert » plutôt que de « l’open source ». Cela signifie que le GDS rend les sources disponibles sous une licence de libre diffusion (LLD), mais ne soutient ou n’établit aucune communauté autour. Dans tous les cas, le « code ouvert » est génial pour de nombreuses raisons.

Équité envers le contribuable

Les sources gouvernementales devraient être ouvertes. Après tout, si le code a été écrit grâce aux impôts du contribuable, ce n’est que justice que le contribuable puisse l’avoir en retour. Fait intéressant, le critère n°15 du Digital by Default Service Standard (NdT. document explicitant les critères auxquels doivent répondre les services gouvernementaux en ligne) récemment publié devrait institutionnaliser cela et faire en sorte que tous les futurs projets du gouvernement britannique soient mandatés pour ouvrir leurs sources par défaut :

Rendez tout nouveau code source ouvert et réutilisable, et publiez-le sous les licences appropriées (ou fournissez une raison valable pour laquelle ce n’est pas possible pour certaines parties spécifiques du code source)

Équité envers la communauté de l’open source

Nous utilisons des langages et frameworks open source (la majorité de GOV.UK est écrite en Ruby et Scala), des serveurs web open source, nous gérons et configurons nos sources avec des outils open source (Git et Puppet), et nous déployons sur les systèmes d’exploitation open source (tournant sous Linux). Redistribuer n’est que justice.

Transparence

Disposer de mon code source GDS sur GitHub facilite ma vie de développeur au GDS. Si j’ai besoin d’intégrer, de réutiliser ou d’étendre un autre composant du GDS, j’ai juste à cliquer dans mon navigateur ou à cloner le dépôt.

La transparence bénéficie aussi à ceux en dehors du GDS. Besoin de connaître les règles pour calculer une pension d’État ? Regardez les sources. Vous avez trouvé un bug dans la page des jours fériés ? Vous pouvez soumettre une pull request pour le corriger.

Je connais des sociétés qui ont des programmes open source internes, et c’est certainement un pas dans la bonne direction, mais le fait de rendre presque tout disponible nous rapproche de l’idéal d’une propriété commune du code.

En bonus, puisque les bidouilles et les raccourcis sont visibles par tout le monde, il en résulte une diminution des bricolages hasardeux.

Réutilisation

Bien qu’une bonne partie du code que nous écrivons est spécifique à nos problématiques, une large part est générique, et pourrait facilement être adaptée à l’usage d’autres administrations centrales, régionales ou locales, ou dans le secteur privé. En fait, les gens commencent déjà à le faire. Vous voulez du bon code pour un front-end ? Le voici. Vous voulez un système de login unique de qualité gouvernementale ? Le voilà. Vous voulez construire vos propres réponses intelligentes ? Ne vous gênez pas.

Marketing

Le « code ouvert » est un bon argument marketing pour l’image de marque du GDS. Quand je dis à d’autres hackers que je fais de l’open source au travail, les sourcils se lèvent. J’ai entendu des gens extérieurs au GDS en parler en termes de « startup gouvernementale » ; il est évident que l’open source améliore l’image de la marque.

Pour le CV

Pour des raisons purement égoïstes, il est vraiment agréable d’avoir un portfolio de mon travail, un endroit où je peux apporter aux gens une preuve tangible de ma capacité (ou mon incapacité ?) à coder en Ruby.

J’aimerais que davantage d’employeurs fassent cela (et pas seulement le secteur public). Si le vôtre ne le fait pas, peut-être que les raisons évoquées ci-dessus pourront aider à le convaincre de changer d’avis ?

L’un des auteurs que l’on traduit le plus sur le Framablog, Glyn Moody, choisit ici de mettre les pieds dans le libre plat.

Et si on n’utilisait plus les licences libres, qui ne sont pas sans poser problèmes, en plaçant directement le code dans le domaine public ?

Les avantages pourraient finalement dépasser les inconvénients !

Remarque : Sur le même thème on pourra également lire (ou acheter) notre framabook Un monde sans copyright… et sans monopole. Sans oublier notre auteur Pouhiou qui place directement ses romans dans le domaine public et s’en explique ici dans un fort intéressant dialogue avec Lionel Maurel aka Calimaq.

Pourquoi il est temps d’arrêter d’utiliser les licences libres

Why it’s time to stop using open source licences by Glyn Moody

Glyn Moody – 13 février 2013 – The H Open
(Traduction : Tr4sK, aKa, Sphinx, Isdf, Penguin, ProgVal, lamessen, Shanx, Amargein, ronane, MFolschette, Isser)

Les logiciels libres reposent sur un paradoxe. Afin que les utilisateurs puissent être libres, les licences libres utilisent quelque chose remettant en cause la liberté : le copyright. Ce dernier est un monopole intellectuel se basant sur la restriction de la liberté des gens à partager, la liberté est donc restreinte et non pas étendue. Quand Richard Stallman, en 1985, a créé la GNU Emacs General Public License, cela représentait un bidouillage brillant, maintenant il est peut-être temps de passer à autre chose.

Nous y sommes déjà et des éléments le montrent. Il y a 18 mois, les gens ont commencé à remarquer le déclin des licences copyleft vers des licences plus permissives comme la licence Apache ou BSD. Plus récemment, la croissance de GitHub a attiré l’attention, montrant également que de plus en plus de gens n’utilisent plus de licences sur GitHub (ce qui peut s’avérer problématique d’une certaine manière).

Je ne pense pas que le déclin des licences copyleft soit la preuve d’un échec, bien au contraire ! Je l’écrivais dans mon édito précédent, le logiciel libre a au fond gagné, prenant le pouvoir dans la plupart des secteurs clés de l’informatique. De la même manière, le passage à des licences permissives n’a été rendu possible que grâce au succès du copyleft : les idées participant à la création collaborative et à la contribution à un projet que l’on utilise sont maintenant généralisées. Il n’y a donc plus besoin de licences copyleft « fortes » pour faire respecter ces valeurs, elles font désormais partie de l’ADN des codeurs. Ian Skerrett le déclarait ainsi en 2011 :

« On n’a plus besoin de s’assurer que les développeurs ou les entreprises soient honnêtes. Ils contribuent aux projets open source parce que cela les aide dans leur travail. S’il fallait s’assurer que les développeurs sont honnêtes, pourquoi y aurait-il autant de projets Apache réussis ? Prenons l’exemple du projet Eclipse qui utilise un copyleft faible. Je ne connais que très peu de contributions ayant été intégrées à Eclipse parce que le développeur avait été forcé de contribuer à cause des obligations de licence. Les gens contribuent aux projets qu’ils utilisent parce qu’ils ont saisi le bénéfice qu’ils pouvaient recevoir grâce à leur contribution. »

C’est aussi pourquoi nous ne devons pas nous n’inquiéter du cloud computing — parfois présentée comme la tueuses des licences libres — puisqu’il n’y a pas de distribution obligeant à publier les éventuelles modifications du code. Mais une fois de plus, nous n’avons pas besoin de cette obligation : si une entreprise d’informatique de cloud computing veut pleinement tirer les bénéfices du logiciel libre, elle y contribuera de toute façon. Si elle ne le fait pas, elle n’a rien compris.

Quelle licence devons-nous donc adopter si on n’utilise pas une licence copyleft ? Apache ? BSD ? Pourquoi pas aucune licence du tout , c’est à dire mettre le logiciel dans le domaine public ? Après tout, c’est la conclusion logique du mouvement vers des licences de plus en plus permissives — une qui permet tout.

Compte tenu des discussions passionnées qui ont tendance à se produire lorsqu’on émet l’idée qu’il y a un mouvement des licences copyleft traditionnelles vers des licences légèrement plus permissives, je soupçonne que l’idée d’évoluer vers une licence complètement permissive sera choquante pour certains. À l’évidence, cela semblerait impossible, car conduisant « certainement » à l’effondrement du logiciel libre lui-même si celle-ci était largement adopté.

Un article intéressant de Clark Asay, maître de conférences à la Penn State Univerity Dickinson School of Law (et aussi frère de Matt Asay, personnalité connue de tous dans le logiciel libre) étudie cette idée en profondeur et présente quelques arguments convaincants sur le fait que placer les logiciels libres dans le domaine public fonctionne et s’avère bénéfique.

Asay (Clark et non Matt) remarque qu’il y a un coût à utiliser des licences libres en termes de conformité. Les entreprises dépensent énormément d’argent en se préoccupant de faire les choses bien, mais les programmeurs, eux aussi, perdent du temps à s’occuper de détails légaux alors qu’ils pourraient être en train d’écrire davantage de lignes de code. En particulier, l’incompatibilité entre les nombreuses licences et leurs variantes est une barrière importante à de plus larges réutilisations et collaborations. Ces problèmes signifient que les logiciels libres ne sont pas utilisés aussi largement et efficacement qu’ils le pourraient, commercialement ou non. Ces difficultés peuvent expliquer en partie le glissement vers des licences plus « permissives », guidé par le désir d’éviter justement ces problèmes.

Asay se met alors à examiner les deux objections majeures à rendre le code disponible librement, sans aucune licence. La première tient au fait que les entreprises risquent de récupérer du code puis de l’enfermer, ce qui selon lui a peu de chance de se passer puisque, en faisant ainsi, elles écarteraient beaucoup des bénéfices que seuls les logiciels libres offrent :

« Si une société devait prendre la responsabilité d’un projet et le rendre fermé, elle n’obtiendrait certainement pas le travail bénévole que les contributeurs du monde entier ont envie d’offrir aux projets disposant de licences ouvertes. Sans ce travail bénévole, les sociétés perdraient un des avantages les plus significatifs des modèles ouverts d’innovation, et ce travail bénévole resterait probablement fidèle à la version ouverte du projet. C’est pourquoi les sociétés encouragent d’ores et déjà à ouvrir le plus de projets possibles et à y contribuer. Car en faisant ainsi, cela va attirer une force de travail bénévole et déclenchera une innovation correspondant mieux à à leurs besoins et stratégies.

Est-ce que la réciprocité (c’est-à-dire l’obligation de contribuer au projet en contre-partie) permet d’éviter la désertion des contributeurs individuels ? Il semble peu probable que, dans la plupart de cas, les contributeurs individuels aient le temps, l’intérêt et les ressources pour s’emparer d’un projet non-réciproque et d’en créer un équivalent fermé. La littérature suggère que les buts espérés par les individus qui contribuent à des projets aux licences ouvertes, ont peu à voir avoir avec un avantage financier direct. Leurs intérêts pour la contribution résident plutôt dans la créativité, l’amélioration de sa réputation, et les bénéfices financiers indirects. Bien qu’il soit toujours possible pour des contributeurs de s’emparer d’un projet ouvert et de le rendre fermé pour l’intégrer dans leurs propres produits (et ainsi contrevenir à ce modèle ouvert d’innovation), les mêmes raisons qui suggèrent que les sociétés ne le feront pas s’appliquent également aux contributeurs individuels. Les contributeurs individuels sont encore moins à même d’abandonner les buts qu’ils espèrent atteindre dans la contribution à des projets ouverts, en plus de n’avoir que des ressources limitées pour réussir à fermer et maintenir un projet. »

L’autre objection majeure qu’il met en avant est que si le logiciel est placé dans le domaine public, il n’existe aucune exigence pour que tous les programmeurs reçoivent la reconnaissance qu’ils méritent pour leur contribution à un projet. Cette reconnaissance peut être importante en raison de l’estime des pairs dont ils jouissent en retour et peut même aboutir à des compensations économiques sous la forme d’offres d’emploi et d’augmentations de salaire.

Attribution et réputation

Je suis d’accord pour dire qu’attribuer le mérite d’un projet est important, et cela de manière cruciale. En fait, je pense que cela représente la clé du problème concernant les produits numériques partagés sur Internet, étant donné que les bénéfices économiques dépendent de cela. Toutefois, forcer cette attribution grâce à des licences ne représente peut-être pas le meilleur moyen. Asay l’explique ainsi :

« Dans une large mesure, l’approche de la gestion de la propriété intellectuelle choisie par les modèles d’innovation ouverts (c’est-à-dire les licences classiques des projets open source) échoue à remplir ses missions. Par exemple, le respect des licences attribution-only (mention de l’auteur original du projet) provoque l’enfouissement d’une telle reconnaissance dans les documents légaux ; cela fait que la reconnaissance d’une telle paternité devient minime. Cette réalité montre que ceux qui contribuent en utilisant des licences attribution-only, bien qu’étant motivés par une certaine forme de reconnaissance, obtiendront un tout autre type de reconnaissance que celui engendré par la propriété intellectuelle. Dans le monde du logiciel libre et open source, des outils comme GitHub, utilisé largement comme outil social de développement, peuvent fournir plus efficacement la reconnaissance que cherchent les programmeurs. Le fait que de plus en plus de contributions à des logiciels effectuées via GitHub se font sans avertissement de non-respect de la propriété intellectuelle ou des clauses de licences montre que le « prix » d’un tel avertissement à cause d’une documentation légale obscure n’en est pas un, du moins pour ceux qui contribuent. »

En effet, les personnes et les entreprises ont déjà commencé à utiliser les profils GitHub comme un moyen d’afficher et de mesurer la capacité à coder. Je soupçonne que cela deviendra bientôt la norme, avec des moyens plus formels d’établir sa réputation dans le monde du développment, apparaissant aux côtés de ceux informellement dictés par les normes sociales au sein de la communauté du logiciel libre.

Après avoir abordé les deux principales objections de se passer de licences open source traditionnelles, Asay examine ensuite ce que le domaine public signifierait en pratique :

« Une approche du style domaine public devrait remplacer efficacement les droits d’auteurs automatiques, supprimer tous les droits liés aux brevets (les deux respectant les droits des brevets déjà obtenus ainsi que de façon prospective), et renoncer à tous les recours possibles venant avec eux. Les droits liés au secret commercial, le cas échéant, devraient êtres supprimés dès que le titulaire des droits a publié le logiciel ou le contenu au public. On peut dire que renoncer à tout droit de marques est non seulement inutile mais déconseillé, car les autres pourraient utiliser les marques pour embrouiller les consommateurs quant à la source du logiciel ou du contenu. En effet, c’est exactement pourquoi la licence CC (Creative Commons), qui inclut une licence dédiée au domaine public dans son répertoire légal, exclut expressément les droits de marque dans son outil. »

Ce dernier point sur les marques est important, bien qu’il puisse sembler étrange de prétendre que tous les monopoles intellectuels et marques doivent être conservés, parce qu’ils servent un but très différent de celui du droit d’auteur ou des brevets. Les marques sont conçues pour protéger les consommateurs contre la fraude, plutôt que de chercher à exclure les concurrents, même si c’est la façon dont elles sont souvent utilisées aujourd’hui.

Mais pour les projets open source, les marques sont purement une question de réputation — c’est à dire qu’elles deviennent des garanties de qualité lorsqu’elles sont appliquées à un programme. N’importe qui peut prendre le code et l’utiliser et l’adapter de différentes façons. Mais il ne pourra pas utiliser la marque du projet, car cela impliquerait qu’il s’agit d’une version officielle « approuvée ». Ce qui serait évidemment problématique pour une variété de raisons, à commencer par celle de la sécurité.

Asay aborde également une objection importante dans sa thèse selon laquelle placer un logiciel dans le domaine public serait la meilleure façon de le distribuer : si c’était le cas, pourquoi tout le monde s’en tiendrait à la licence GPL ou Apache ? Comme il le souligne :

« Dans le monde du logiciel libre et open source, par exemple, il n’existe aucun outil reconnu ou largement utilisé dévoué au domaine public. A la place, l’Open Source Initiative et la Free Software Foundation — les deux principales organisations de défense des logiciels libres dans le monde — refusent ou approuvent les licences ouvertes utilisées dans la communauté. S’il est vrai que divers projets pourraient tout simplement ignorer ces licences recommandées et d’adopter une approche par domaine public — certaines ayant essayé de faire exactement cela — cette approche suppose que les organisateurs de ces projets comprennent comment le faire. »

Le fait est qu’il est actuellement assez difficile de placer un logiciel dans le domaine public, premièrement parce qu’il y a un biais culturel contre une telle attitude, même au sein de la la communauté du logiciel libre, et deuxièmement parce que légalement c’est un processus délicat. En effet, Asay suggère que nous avons besoin d’une nouvelle législation — ce qu’il appelle Public Domain Act (NdT, en français : « Loi du Domaine Public ») — pour rendre ce processus plus facile. Il faudra évidemment prendre en compte les différents systèmes de copyright ayant cours dans le monde — par exemple, ceux qui mettent plus l’accent sur les « droits moraux ».

Il y a quelques années, j’ai demandé à Richard Stallman ses points de vue sur la manière dont le copyright devrait être réformé, particulièrement concernant l’aspect logiciel. Voici ce qu’il a répondu :

« Pour la plupart des types de travaux, je pense que le droit d’auteur serait acceptable si nous l’avions (1) fait plus court (je suggère 10 ans), (2) permis la redistribution de copies dans un but non commercial et sans modification, (3) défini comme fair use les réutilisations sous forme de remix. Cependant, je pense que les logiciels et autres œuvres d’usage pratique doivent être libres. »

Notez qu’il pense, lui aussi, que le logiciel devrait être exempt de tout copyright — en d’autres mots, dans le domaine public — mais il a ajouté quelques mises en garde :

« Je serais heureux de voir l’abolition du copyright dans le logiciel si c’était fait de façon à s’assurer que le logiciel est libre. Après tout, l’objectif du copyleft est d’atteindre ce but pour les dérivés de certains programmes. Si tous les logiciels étaient libres, le copyleft ne serait plus nécessaire.

Cependant, l’abolition du copyright peut aussi être faite de manière erronée et pourrait n’avoir aucun effet sur les logiciels propriétaires typiques (qui sont restreints par des CLUF, Contrats de Licence Utilisateur Final, et le secret du code source plus que par le copyright), et ne ferait que porter atteinte à l’utilisation du copyleft. J’y serais naturellement opposé. »

Placer les logiciels libres dans le domaine public serait équivalent à abolir le droit d’auteur pour ces programmes tout en laissant le code propriétaire intact. Est-ce vraiment un problème ? Personnellement, je ne le pense pas, pour les raisons que j’ai mentionnées : toute entreprise prenant du code dans le domaine public et se l’appropriant perd tous les avantages de son ouverture. Il est vrai qu’il reste des programmes hérités des maisons de logiciels à l’ancienne qui ont toujours été propriétaires, mais leurs existence n’affecte pas vraiment le monde plus large du logiciel libre, qui est maintenant arrivé à l’indépendance et à l’autosuffisance. Ce que Microsoft et ses semblables font en ce moment est quelque peu hors de propos.

Bien sûr, le passage au domaine public ne signifiera pas la disparition des licences libres actuelles — elles seront toujours là pour ceux qui souhaitent les utiliser. Comme toujours, le choix et la liberté personnelle sont capitaux. Mais j’espère que les gens y réfléchiront à deux fois avant d’introduire de nouvelles licences, ou même avant d’en mettre à jour d’anciennes. En particulier, j’espère qu’il n’y aura jamais de GNU GPL version 4. Au contraire, nous devons parachever la révolution que Richard Stallman a commencée il y a près de trois décennies en rendant le logiciel libre véritablement libre, en le plaçant dans le domaine public et en brisant les chaînes qui le lient encore à ce monopole vieux de trois cents ans nommé copyright.

« Le magazine américain New Yorker a annoncé la création d’une boîte informatique sécurisée nommée Strongbox, destinée à recevoir des informations en protégeant l’anonymat des sources » pouvait-on lire récemment sur le site des Écrans, qui ajoute : « La technologie utilisée a été développée par le jeune militant d’Internet et hacker Aaron Swartz, qui était poursuivi par la justice pour avoir pénétré une base de données universitaires et s’est suicidé en janvier ».

Nous avons voulu en savoir plus en traduisant l’article ci-dessous. Difficile de se départir d’une certaine émotion quand on sait ce qu’il lui est arrivé par la suite…

Strongbox et Aaron Swartz

Strongbox and Aaron Swartz

Kevin Poulsen – 15 mai 2013 – The New Yorker
(Traduction : anneau2fer, Penguin, Sky, lgodard, Rudloff, Asta, Jere, KoS + anonymes)

Aaron Swartz n’était pas encore une légende lorsque, il y a presque deux ans, je lui ai demandé de développer une boîte aux lettres anonyme et open source. Ses réussites étaient réelles et variées, mais les événements qui allaient le faire connaître du grand public faisaient encore partie de son futur : sa mise en cause dans une affaire criminelle au niveau fédéral ; son essor en tant que leader du mouvement contre la liberticide Sopa ; son suicide dans un appartement de Brooklyn. Je le connaissais comme programmeur et comme activiste, un membre de la tribu relativement restreinte de gens qui savent transformer des idées en code — un autre mot pour « action » — et qui ont la sensibilité nécessaire pour comprendre instantanément ce que je cherchais : un moyen sûr pour les journalistes de communiquer avec leurs sources.

Il existe une fracture technologique grandissante : les écoutes de téléphones et d’emails, le piratage d’ordinateurs, sont des armes pour quiconque cherche à identifier les sources d’un journaliste. À quelques exceptions, la presse a peu fait pour se protéger : nos efforts en matière de sécurité de l’information tendent à se concentrer sur la partie des infrastructures qui accepte les cartes de crédit.

Aaron était au fait de ce genre de problème. Je l’avais d’abord rencontré en 2006, lorsqu’avec deux autres codeurs, il avait vendu le site d’info communautaire Reddit à Condé Nast, la maison mère de Wired, où je travaille, et du New Yorker. Tous trois se sont retrouvés dans une salle de conférence improvisée près du siège de Wired à San Francisco. Aaron se distinguait de ses collègues — il était angoissé, silencieux, et a expliqué dans un billet de blog à quel point il n’aimait pas travailler là.

Un lundi, il a quitté le bureau pour passer la journée au tribunal tout proche, où une audience avait lieu dans l’affaire Kahle contre Gonzales, une bataille constitutionnelle autour du copyright menée par le professeur de droit Lawrence Lessig. Lorsqu’il est revenu, il m’a demandé, un peu timidement, s’il pouvait écrire quelque chose sur le sujet dans Wired. Le billet de blog de 700 mots qui en résultât était bien écrit et énonçait clairement le sujet. Je me suis posé des questions sur ce jeune patron de start-up qui mettait son énergie dans le débat sur le copyright. Ça, et sa co-création d’un projet d’anonymisation appelé Tor2Web, était ce que j’avais en tête lorsque je l’ai approché pour mon projet de boîte aux lettres sécurisée. Il a accepté de le faire, tout en sachant que le code serait open source — la licence autorisant n’importe qui à l’utiliser librement — lorsque le système serait lancé.

Il se mit à coder immédiatement, pendant que je cherchais les serveurs et la bande passante nécessaires chez Condé Nast. Les normes de sécurité imposaient que le système soit sous le contrôle physique de la société, mais avec sa propre infrastructure isolée. Des autorisations ont du être demandées. Les cadres avaient des questions. Les juristes avaient encore plus de questions.

En octobre 2011, Aaron est venu dans les bureaux de Wired et nous avons travaillé sur quelques détails. Durant les années qui ont suivi, le mutisme tranquille d’Aaron s’est mué en confiance provisoire, sa morosité remplacée par un sourire désarmant et une douce générosité. Avant qu’il ne parte, je suis allé avec lui dans les nouveaux locaux, bien plus grands, de Reddit, qui se trouvaient à côté. Il entra, regarda autour de lui, et ressortit sans que personne ne l’ait reconnu.

Entre-temps, Aaron avait été inculpé pour le téléchargement de 4 millions d’articles de JSTOR, une base de données académique, depuis le réseau public du MIT. Cette affaire a dû lui peser. Mais il n’en parlait pas.

Il vivait a New York à cette époque, mes contacts avec lui étaient donc essentiellement électroniques. Le système, que nous appelions DeadDrop, était, pour nous deux, un projet secondaire, et Aaron en avait beaucoup de prioritaires. J’ai appris son protocole : quand il avait le temps de programmer, je pouvais le joindre par téléphone ou sur Skype. Nous avions de long échanges à propos de sécurité et de fonctionnalités ; Aaron rejetait ceux dont il pensait qu’ils compliqueraient trop le système — clés de chiffrement individuelles pour chaque reporter, par exemple.

À New York, un expert en sécurité informatique nommé James Dolan convainquit un trio de collègues de son industrie de rencontrer Aaron pour examiner l’architecture, et plus tard, le code. Nous voulions être raisonnablement assurés que le système ne serait pas compromis, et que les sources pourraient déposer des document de manière anonyme, afin que même l’organe de presse qui les recevrait ne serait pas capable de dire au gouvernement d’où ils venaient. James a écrit un guide de sécurité pas à pas très détaillé pour les organisations qui implémentent le code. « Il va un peu trop loin », disait Aaron dans un email, « mais ce n’est peut-être pas une mauvaise chose ».

En décembre 2012, le code d’Aaron était stable, et une date approximative de lancement avait été définie. Puis, le 11 janvier, il se suicida. Dans les jours qui suivirent, il était difficile de penser à autre chose que la perte et la douleur de sa mort. Un lancement, comme beaucoup d’autres choses, était secondaire. Son suicide a également fait apparaître de nouvelles questions : à qui appartient le code désormais ? (Réponse : ses dernières volontés indiquaient qu’il voulait que toutes ses propriétés intellectuelles reviennent à Sean Palmer, qui donna sa bénédiction au projet). Est-ce que ses amis proches et sa famille approuveraient de poursuivre le lancement ? (Son ami et exécuteur testamentaire, Alec Resnick, a signalé que c’était le cas). Le New Yorker, qui a un long passé de travail d’enquête sérieux, apparut comme le premier foyer pour le système. La version du New Yorker s’appelle Strongbox et a été mise en ligne ce matin.

Neuf jours après la mort d’Aaron, son avatar Skype si familier, est apparu sur mon écran. Quelqu’un, quelque part, probablement un membre de sa famille, avait démarré son ordinateur. J’ai dû combattre l’envie irrationnelle de cliquer sur l’icône et reprendre notre conversation. Puis il a disparu à nouveau de mon écran.

On le savait déjà mais un présumé développeur Microsoft vient le confirmer avec précision : GNU/Linux est plus rapide que Windows.

Et les raisons qu’il avance font que cela semble difficilement réversible…

Remarque : Le développeur reste anonyme donc le doute subsiste, sur son identité pas sur la lenteur de Windows 😉

Un developpeur Microsoft admet que Linux est plus rapide que Windows

Anonymous MSFT developer admits Linux is faster than Windows

Steven J. Vaughan-Nichols – 12 mai 2013 – ZDNet
(Traduction : alct, goofy, Le_Hobbit, Kurze, Sylvain, Axl, tcit, ProgVal, Jose, Eijebong, Sinma, lmorel3, nano-plink, JLoDoesIT, Cyrille L., MFolschette + anonymes)

Résumé : Ce n’est pas une grande surprise, mais Linux est plus rapide que Windows, et au moins un développeur anonyme de Microsoft est d’accord pour l’admettre et il explique pourquoi c’est le cas.

Linux est bien plus rapide que Windows. Cette constatation n’est pas neuve. C’est pourquoi Linux fait tourner 90 pourcents des 500 plus rapides super-calculateurs, alors que Windows ne fait tourner qu’un pourcent d’entre eux. La nouvelle « nouvelle » est qu’un présumé développeur du système d’exploitation de Microsoft a récemment admis que Linux est en effet plus rapide, et explique pourquoi c’est le cas.

Cette personne anonyme, supposée être un programmeur du noyau de Windows a d’abord publié ses commentaires dans une conversation sur « Hacker News ». Il a poursuivi avec plusieurs commentaires sur le blog de Marc Bevand. Marc Bevand est un ingénieur logiciel pour Adconion, spécialisé dans les calculs à haute performance.

Le présumé développeur déclare en introduction : « Windows est en effet plus lent que les autres systèmes d’exploitation dans beaucoup de situations, et cela ne va pas en s’améliorant. La cause de ce problème est sociale. Aucune amélioration n’est apportée au système pour elle même, pour sa « gloire » telle que celles que vous voyez dans l’univers de Linux. »

Ce n’est pas que les développeurs Windows ne veulent pas améliorer les performances de leur système d’exploitation; le problème est que la culture de développement de logiciel chez Microsoft décourage les améliorations. Le prétendu programmeur écrit :

« Certes, on voit parfois des personnes naïves tenter d’améliorer les choses. Elles échouent presque systématiquement. Nous pouvons — et nous le faisons — améliorer les performances de certaines fonctionnalités spécifiques lorsque les personnes chargées d’allouer les ressources considèrent que cela aura une influence sur les objectifs commerciaux, mais c’est un travail vain. Il n’y a aucun plan global officiel ou officieux pour l’amélioration des performances du système. Nous avons commencé à nous soucier des problématiques liées à la sécurité parce que Windows XP, avant la sortie du Service Pack 3, devenait une menace vitale pour les affaires. Nos mauvaises perfomances, quant à elles, ne menacent pas les affaires.

Voyez-vous, les producteurs de composants sont généralement ouvertement hostiles aux modifications par des tiers. Si vous êtes un développeur, accepter un patch de l’extérieur met votre chef en colère (parce qu’il faut maintenir ce patch et justifier auprès des collaborateurs le changement de conception non prévu), les testeurs en colère (car les testeurs ont pour responsabilité d’assurer que le changement ne brise rien et vous leur avez créé du travail) et le gestionnaire de projet est en colère (à cause des conséquences en termes de planification du bout de code). Il n’y a en fait rien qui encourage à accepter les changements venus de l’extérieur de votre propre équipe. Vous pouvez toujours trouver une raison de dire « non » et très peu d’intérêt à dire « oui ».

Il y a aussi peu d’incitation au changement tout court. Dans le noyau Linux, si vous améliorez la performance du parcours d’un répertoire de 5%, vous êtes félicité et remercié. Ici, si vous le faites et que vous n’êtes pas dans l’équipe qui s’occupe de ce sujet, dès lors même si votre code est approuvé par les tenants du sujet et intégré, votre hiérarchie s’en moque. Oui, faire des améliorations importantes va vous permettre d’être remarqué par les plus expérimentés et pourrait être une aubaine pour votre carrière, mais l’amélioration doit être vraiment énorme pour attirer ce genre d’attention. Les améliorations progressives ne font qu’ennuyer les gens et sont, au mieux, sans impact sur votre carrière. Si vous êtes malchanceux et que vous parlez à votre supérieur de comment vous avez amélioré la performance d’autres composants du système, il va juste vous demander si vous pouvez accélérer votre activité de résolution de bug. »

D’après lui, Microsoft est en train de perdre ses meilleurs talents chez la concurrence. Il écrit : « Une autre raison qui explique l’écart de qualité est que nous avons eu du mal à garder les gens talentueux. Google et les autres grosses compagnies de la région de Seattle continuent à piquer nos meilleurs développeurs, ainsi que nos plus expérimentés et nous embauchons des jeunes tout droit sortis de l’université pour les remplacer. Vous trouvez ainsi des SDE (NdT : Microsoft Software Development Engineer pour Ingénieurs de développement logiciel Microsoft) qui maintiennent des systèmes énormes. Ces développeurs sont bien intentionnés, et sont en général suffisamment intelligents, mais ils ne comprennent pas pourquoi certaines décisions ont été prises, ils n’ont pas une compréhension approfondie des détails complexes de la manière dont leurs systèmes fonctionnent et, plus important, ils ne veulent rien changer qui fonctionne déjà. »

De plus, assure-t-il, les développeurs juniors de Microsoft ont une tendance à apporter des améliorations au système en implémentant des fonctionnalités flambant neuves plutôt que d’améliorer les anciennes. Si l’on observe les dernières sorties de Microsoft, le constat est sans appel : nous n’améliorons pas les anciennes fonctionnalités, nous en ajoutons de nouvelles. En l’état actuel des choses, à l’heure du bilan, le développement de nouvelles fonctionnalités est mieux considéré que l’amélioration des anciennes (c’est littéralement l’explication de Powershell. Beaucoup d’entre nous souhaitaient améliorer cmd.exe mais ne pouvaient pas).

Juste pour le plaisir de baver, il est difficile de battre ses pensées concernant le système de fichiers NT (NTFS) : « Oh mon dieu, le code NTFS est un livre d’horreur victorien réécrit sous opium violacé qui utilise des verrous récursifs et SEH (gestion structurée des exceptions) pour le contrôle des flux. Ecrivons plutôt ReFs (système de dossiers résistant à la place (et, ouais, copions et collons le code source de NTFS et enlevons la moitié de ses fonctionnalités ! Et ajoutons des sommes de contrôle, parce c’est cool, n’est-ce pas, et maintenant avec ça c’est tout aussi bien que dans ZFS (Z File System) ? D’accord ? Et qui a besoin de quotas de toute façon ?) »

Ces « révélations » n’ont rien de nouveau. N’importe qui ayant suivi « Mini-Microsoft », un employé anonyme de l’entreprise proposant une vue de l’intérieur des open spaces à gogo du pôle du développement Microsoft, ou qui a lu les commentaires d’un ex-développeur Microsoft mécontent comme Hamilton Verissmo, sait comment la bureaucratie du développement chez Microsoft se met en travers de l’innovation. Comme Brian Cody, un ancien ingénieur Microsoft, disait dans le Magazine Forbes en 2012, être un développeur logiciel Microsoft qui réussit « a toujours été beaucoup moins sur comment je pourrais devenir un meilleur ingénieur et beaucoup plus sur comment améliorer ma visibilité auprès des managers ».

En résumé, Microsoft est devenu une « vieille » entreprise. Ce n’est pas une surprise qu’aujourd’hui, Microsoft tente de se rattraper au niveau des tablettes et smartphones avec des ratés tels que Windows 8 Metro plutôt que l’amélioration de ses performances logicielles de base.

Les personnes réagissent comme si ce nouveau regard sur le fonctionnement de Microsoft était choquant. Ça ne l’est pas. Le développeur le dit lui-même, dès que l’histoire s’est répandue sur la blogosphère, « c’était devenu hors de contrôle. J’ai été trop sévère, et je ne voulais pas que cela ressemble à une sorte d’exposé géant. C’était juste du ronchonnement ».

En particulier, il s’excuse à moitié pour ses commentaires sur NTFS: « NTFS utilise bien SEH en interne, mais le système de fichiers est très robuste et bien testé. Les gens qui le maintiennent comptent parmi les plus talentueux et expérimentés que je connaisse. (Certes, je pense qu’ils maintiennent du code laid, mais le code laid peut faire des composants bons et fiables, de plus la laideur est nécessairement subjective.) »

Dans une tentative de résumer toutes ses plaintes de manière plus positive, il a ajouté, « Windows et Microsoft ont toujours beaucoup de talents techniques. Nous ne livrons pas de code que personne ne peut maintenir et comprendre, même si quelques fois ça peut prendre un peu de temps pour les nouvelles personnes pour contribuer. Bien que j’ai des droits de lecture et d’écriture sur le code source de Windows ainsi que des dizaines de milliers de personnes à travers le monde, je ne suis pas une exception. On ne prend quasiment aucune décision individuelle, et bien que je maintienne que la dynamique sociale décourage la prise de risque et l’action individuelle, je veux insister sur le fait que nous ne sommes ni fous ni anormaux. La force sociale telle que je l’ai décrite promeut l’innovation, et bien que je pense que l’on devrait pouvoir améliorer les aspects de notre culture que j’ai précisés, nous sommes loin d’être paralysés.

Les effets négatifs sont davantage comme ceux encourrus lors du montage d’un béquet non nécessaire sur une voiture plutôt qu’arracher le bloc moteur. Un fait incontestable, c’est que notre division d’ingénieurs fabrique et distribue des logiciels fiables qui fonctionnent partout dans le monde. Qu’importe ce que vous pensez de la nouvelle interface utilisateur de Windows 8, le système qui se cache en dessous est solide comme le roc, tout comme l’était Windows 7, et je suis fier d’avoir été une petite pièce de tout ce processus. »

Solide comme le roc ? Les patchs mensuels du mardi de Microsoft et la sortie constante de corrections pour des failles zero-day, comme la correction en mai d’IE 8, me laissent perplexe, comme toujours, sur la sécurité et la stabilité de Windows, mais que peut dire d’autre un employé de Microsoft ? Dans tous les cas, lorsqu’on parle de vitesse, c’est Linux, et non Windows, comme il l’a admis lui-même, qui reste le champion évident.

Crédit photo : Thawt Hawthje (Creative Commons By)

GitHub est aujourd’hui la plus dynamique forge de développement de logiciels libres. Mais n’y aurait-il pas, dans sa conception même, quelques problèmes de gouvernance et de circulation du code qui menacent l’efficacité, voire la viabilité, des projets ?

Remarque : Pull request, issue, commit… nous présupposons que vous êtes familier avec le vocable GitHub, mais si un gentil lecteur veut nous les préciser dans les commentaires, qu’il/elle n’hésite surtout pas 😉

De la citoyenneté dans le développement de logiciels open source

On Citizenship in Open-source software development

Christophe Maximin – 8 mai 2013 – Blog personnel
(Traduction : ProgVal, Melchisedech, nano-plink, TheCamel, Al + anonymes)

Comment GitHub peut révolutionner la question en donnant le pouvoir aux utilisateurs dans les dépôts auxquels ils contribuent.

TL;DR : En donnant un véritable statut social aux personnes contribuant à un dépôt, GitHub résoudrait le problème des projets-zombies ayant une communauté éparpillée. En permettant à ces citoyens de collaborer réellement les uns avec les autres, et non avec le seul propriétaire, les dépôts seront vivants tant que leur communauté existera, de manière complètement auto-régulée.

L’année a très bien commencé pour GitHub. Après avoir levé cent millions de dollars d’Andreesen-Horowitz et atteint les trois millions d’utilisateurs en janvier (3,4 millions et plus à présent), ils sont sur une dynamique qu’il sera difficile d’arrêter.

Néanmoins, le service a aussi ses défauts, et si certaines personnes pointent du doigt de tous petits problèmes liés aux services et aux applications, le problème que je m’apprête à décrire touche à la nature même de nos interactions sur la plate-forme.

1. État actuel d’un dépôt

Chaque dépôt que vous créez est un petit pays avec une très faible population : 1 habitant, vous, le créateur/roi/commandant suprême.

Même si votre dépôt a des centaines de rapports de bugs créés par d’autres, et des centaines de pull requests, il n’y a qu’une seule personne aux commandes.

Bien sûr, vous pouvez ajouter des collaborateurs à votre dépôt, mais il ne seront que des collaborateurs, des membres du cabinet, choisis juste parce que vous le souhaitez. Bien sûr, dans le cas des organisations, vous pouvez ajouter des co-commandeurs suprêmes.

Mais c’est tout. Vous n’atteindrez probablement pas cinquante collaborateurs/membres; même si votre dépôt est vraiment populaire, et même si des centaines de personnes y contribuent. Est ce que cela vous parait normal ?

Ce ne serait pas un problème si ce n’était pas la cause de…

2. La fragmentation des dépôts et de leurs fonctionnalités

J’ai vu la chose suivante arriver bien trop souvent :

• Le développeur abandonne graduellement un projet à cause de nouveaux engagements dans sa vie, ou juste parce qu’il n’est plus intéressé. Et donc il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas.
• Le développeur est dépassé par les rapports de bugs et les pull requests qu’il reçoit. Et bien qu’il sache qu’il a une solide communauté autour de ce projet, il ne peut pas juste ajouter quelqu’un comme collaborateur car il devra quand même lire chaque ligne pour être sûr que tout est en ordre. Et donc, il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas vraiment.

Et vous vous dites : « Qui s’en soucie ? N’importe qui peut forker le dépôt et donner une nouvelle vie au projet autre part ! »
Bien entendu, mais combien de fois avez-vous vu cela se faire réellement ?
La plupart du temps, les gens forkent le projet pour régler « le » bug qu’ils voulaient régler, et c’est tout.

Maintenant, si vingt personnes agissent de la sorte, cela devient une vraie tragédie : le projet est en fait encore mis à jour, mais à vingt autres endroits. Vous devrez fusionner les commits de 20 dépôts différents pour être à jour de toutes les nouvelles choses cools que vous pouvez faire avec le projet. Mais vous ne le ferez jamais. Certains forks sont incompatibles de toute façon.

D’autre part, comme le projet « semble vivant », personne ne se presse pour essayer de le remplacer. La léthargie se poursuit alors encore et encore, et va créer la confusion chez n’importe quel nouveau venu quant à l’état du projet, sur l’emplacement des dernières mises à jour, et sur leur éventuelle acceptation par la communauté.

Je ne vais pas donner de noms (ce n’est pas bien de pointer du doigt publiquement) , mais je suis sûr que vous voyez à quoi je fais référence.

3. Le pouvoir au peuple, le pouvoir à la cité

Sans entrer dans un débat sur les multiples définitions du mot citoyenneté, vous trouverez ici une liste de quelques fonctionnalités qui en feront une réalité. Rien de ce qui est listé ici n’est absolu, et ce sera à l’administrateur de définir les règles.

• Tout le monde peut voter pour une issue.
• Tout le monde peut voter pour une pull request, avec un merge automatique quand une majorité (ou quelque chose d’autre à définir) est atteinte.
• Les citoyens se voient attribuer des « points de karma » suivant les votes positifs ou négatifs qu’ils reçoivent sur leurs commits et leurs réponses aux issues. Les citoyens ont un total de points pour ce dépôt, et pour le reste de GitHub.
• Tous les commits qui sont approuvés par le peuple vont dans un branche spécifique préfixée « par_le_peuple_* » .
• Les administrateurs ont toujours le droit de veto sur ce qu’ils veulent, et peuvent complètement couper ce mode « auto-pilote » .

Conclusion

Il est temps que les gens qui contribuent à des projets acquièrent enfin une réelle existence. Il n’y a vraiment rien à perdre, et cela semble pour moi être une évolution naturelle et inévitable de toute façon.

La question est : combien de temps devrons nous attendre ?

Aujourd’hui, tout le monde a le cloud à la bouche. C’est vrai que ne rien installer et avoir un logiciel collaboratif à portée de main, c’est pratique… Mais nous sommes de plus en plus nombreux à nous inquiéter de savoir où passent nos données…. qui gère les serveurs… comment être autonomes… Le Framacloud est né avec Framapad, un service connu et utilisé par de nombreuses personnes. Aujourd’hui, Framadate connait aussi un grand succès comme alternative libre aux « doodles ». Mais il existe d’autres services qui n’attendent que votre utilisation, vos retours, votre participation.

Tous les projets Framasoft, qu’ils soient culturels, cloudesques, logiciels ou les trois, demandent des lignes de code… Bien sûr, les salariés ainsi que des bénévoles enrôlé-e-s de force dans l’association mettent les mains dans la source. Mais, encore une fois, l’apport de la communauté est essentiel. C’est pourquoi Framasoft a ouvert un dépôt GitHub. Afin que chacun-e puisse étudier, reproduire, modifier et diffuser du code que nous créons ensemble… Mais laissons Quentin nous le présenter.

— Pouhiou

Framablog : Dis-moi, c’est quoi un GitHub ? A quoi cela peut-il servir pour le développeur en herbe ? La codeuse volontaire ?

Quentin : Je ne vais pas m’embêter et je vais reprendre la définition de Wikipédia : GitHub est un service web d’hébergement et de gestion de développement de logiciels, utilisant le programme Git. En fait, c’est un site web où les développeurs du monde entier peuvent héberger le code source de leurs applications et ainsi le partager s’ils le veulent avec le reste du monde. Chaque membre de GitHub peut faire des propositions pour de nouvelles fonctionnalités, ouvrir des bogues, les corriger et les soumettre au projet initial. Il peut également copier le projet pour travailler sur une copie de celui-ci. On appelle cela un « fork ».

Pour le développeur en herbe ou la codeuse volontaire, cela permet de lire du code écrit par d’autres, de pouvoir le modifier et ensuite, d’en faire part à l’équipe qui développe le projet. Celle-ci peut alors commenter ce qu’a fait ce nouveau développeur et lui dire ce qui est bien et ce qui n’est pas bon dans son code. C’est ainsi que l’on apprend… C’est également comme cela que se créé une communauté autour d’un logiciel, que ce dernier s’enrichit et devient de plus en plus stable. Toutes les contributions sont bénéfiques !

Mais un code, c’est pas un peu personnel ? Je veux dire, c’est facile de mettre le nez dans un projet développé par quelqu’un d’autre ?

Ce n’est pas toujours facile en effet de se plonger dans le code de quelqu’un d’autre, surtout s’il est mal documenté, comprend trop peu de commentaires… il ne faut donc pas hésiter à poser des questions, ni craindre de commettre des erreurs ! Les développeurs sont aussi là pour expliquer le fonctionnement de leur logiciel.

Chez Framasoft, le code n’a rien de personnel puisqu’il est développé soit par les bénévoles, soit par les salariés de Framasoft, il est donc normal qu’il soit mis à la disposition de tous.

Framablog : Du coup quelle est la meilleure méthode pour participer à l’amélioration d’un projet Frama présent sur GitHub ?

Il y a plusieurs façons de participer à un projet Frama, je vais aller de la plus basique (mais non la moins importante) à la plus complexe :

1. Dire merci. Oui, c’est tout bête, mais quand on utilise un logiciel libre qui nous plaît, il est très facile d’écrire un petit courriel pour dire merci. Ça ne coûte rien, ça fait plaisir à entendre et ça motive encore plus…
2. Remonter des bogues : c’est également quelque chose de simple, mais ce n’est pas souvent fait. Lorsque vous apercevez un problème sur l’une des applications Framasoft, n’hésitez pas à ouvrir un bogue (rubrique “Issues”) dans GitHub (si vous avez un compte sur ce site) ou tout simplement à nous contacter par courriel pour nous faire de votre problème
3. Proposer des améliorations : vous avez une idée pour améliorer les applications Framasoft, alors proposez-la (de la même façon qu’au point 2). Pour cela, il faut être un petit peu développeur c’est vrai, mais vous pouvez nous aider en corrigeant les bogues, en apportant votre savoir-faire sur tel ou tel langage, en codant une nouvelle fonctionnalités… Il vous suffit de « forker » les projets Framasoft présents sur GitHub, modifier le code et faire ce que l’on appelle un Pull request :  il s’agit une demande d’intégration du nouveau code soumis par le développeur dans l’application.

En conclusion, il n’y a pas de meilleure méthode pour participer, elles sont toutes intéressantes et permettent d’améliorer les applications.

Framablog : Quels sont les projets Frama disponibles sur notre dépôt Github ? Il y en a d’autres qui vont s’y loger bientôt ?

Donc sur GitHub, Framasoft est représentée par l’équipe Framasoft : si vous ouvrez le lien, vous voyez toutes les applications dont le code source est partagé avec la communauté.

On y trouve a par exemple le code source de Framapad ainsi que celui de Framadate.

…mais aussi d’autres projets qui sont principalement utilisés en interne dans l’association comme Gesdon qui comme son nom l’indique, nous permet de gérer les dons et l’envoi des reçus fiscaux. Pour le moment, il n’y a que quelques applications dont nous partageons le code source. Nous souhaitons bien sûr partager le maximum, mais le manque de temps ne nous a pas encore permis d’organiser et d’ajouter le code source d’autres applications.

Vous en voulez encore ? Découvrez aussi celles-ci :

Framacalc : Framacalc est à Framapad ce que Calc est à Writer. Il s’agit donc d’un tableur en ligne collaboratif. Même s’il est pour l’instant moins complet que Framapad, Framacalc est tout à fait fonctionnel et vous permettra de travailler à plusieurs et en temps réel sur une feuille de calcul.

Framindmap : Besoin de faire un brainstorming ? Framamind est l’outil qu’il vous faut. Avec sa prise en main intuitive, il vous permettra de structurer vos réflexions pour en faire une superbe carte heuristique. Choisissez les positions de vos idées, les couleurs, et repartez avec vos idées mises au clair, sous forme d’image ou de fichier exportable, que vous pourrez toujours importer plus tard, pour le modifier et le compléter.

Gégé (rien que pour le lulz) : S’il y a un outil du Framaverse qu’on a fait en se disant : « ce pourrait être un délire sympa de le faire », c’est bien celui-ci. L’idée est venue est voyant une démo sur le site de Mozilla (). Et si on faisait pareil avec les personnages de Gee ? Il a suffit de quelques personnalisations du CSS par Bouts et Gégé, le Générateur de Geektionerd, était né. L’outil, simple d’utilisation permet de créer simplement, sans talent de dessinateur, ses BD de Geektionerd en proposant des jeux de mots tellement pourris que même Gee n’aurait pas pu les écrire.

Il y a un an Microsoft annonçait la création de Microsoft Open Technologies, filiale open source du groupe.

Cela avait surpris. Mais il n’y a que les imbéciles (et les non pragmatiques) qui ne changent pas d’avis 😉

Toujours est-il qu’on est encore loin du compte si, telle la conclusion de cet article, on souhaite la libération de Windows et d’Office.

La division open source de Microsoft a un an, mais qu’est-ce que c’est ?

Microsoft’s Open Source Company Is a Year Old. But What Is It?

Robert McMillan – 17 avril 2013 – Wired.com
(Traduction : Peekmo, aKa, 5h3d0, Brandelune, Moosh, yostral, Gatitac, Sky)

La semaine derniere, Microsoft Open Technologies S.A. a fêté son premier anniversaire, tranquillement, sans fanfare, mais la semaine prochaine, Microsoft prévoit d’organiser une réception sur son campus de la Silicon Valley.

Microsoft Open Technologies est un drôle de canard à trois pattes : une filiale indépendante destinée à soutenir l’effort open source, poussée par l’acteur le plus connu du logiciel propriétaire (NdT : ou privateur/privatif). Quand sa création a été annoncée, la nouvelle en a atterré plus d’un — nous y compris.

Après tout, Microsoft avait déjà mis en place une autre organisation — un organisme indépendant à but non lucratif, la Fondation Outercurve — pour gérer l’effort open source.

La différence réside dans le fait que même si la Fondation Outercurve est financée par Microsoft, elle est régie par ses propres règles. Et si l’on en croit Paula Hunter, directrice exécutive de la Fondation, plus de la moitié des projets d’Outercurve est dirigée par des membres qui ne font pas partie de Microsoft.

Open Technologies est gérée par Microsoft. La société gagne ainsi plus de contrôle — un concept qui ne colle pas vraiment avec la façon de faire de l‘open source — et plus de crédit pour les logiciels libérés.

Microsoft continue à envoyer des projets à la Fondation Outercurve, nous apprend Hunter. Mais ils ont maintenant un autre endroit où déposer le code. « Certaines fois ils veulent maintenir un contrôle plus fort sur le projet et faire en sorte qu’il soit plus proche de la marque Microsoft » ajoute-t-elle. « Quand un projet est plus lié à leurs technologies propriétaires, cela a plus de sens de le déposer au sein d’Open Technologies. »

Ces entités indépendantes sont importantes pour les projets open source — elles donnent aux entreprises une manière de partager leur code source sans se peindre une gigantesque cible à procès pour violation de brevets sur le dos. La fondation ou la société indépendante agissent comme une sorte de bac à sable où les développeurs peuvent partager et distribuer des logiciels, et si quelqu’un dit que ce code viole un brevet, c’est le bac à sable, pas Microsoft, qui est poursuivi.

En février dernier, Gianugo Rabellino de Microsoft nous a dit qu’Open Technologies sert surtout à accélérer le développement open source au sein de l’entreprise. « Nous nous sommes rendus compte qu’avoir une filiale différente serait quelque chose qui fonctionnerait mieux, d’une part en nous assurant que nous soyons agiles, flexibles et plus rapides, et d’autre part en travaillant avec les communautés open source à la vitesse qu’elles requièrent » a ajouté Rabellino, directeur de communauté chez Microsoft Open Technologies.

Jusqu’à aujourd’hui, Open Technologies a hébergé nombre de projets qui aident les gens qui utilisent Windows Azure, le concurrent de Microsoft à Amazon Web Services. Azure est une manière pour les développeurs et les entreprises de construire et faire fonctionner toutes sortes de logiciels, et Microsoft a réalisé que ces personnes se reposent énormément sur les technologies open source.

Mais cela ne signifie pas que Microsoft soit en train de devenir une entreprise open source.

Phil Haack, un ancien de chez Microsoft qui travaille désormais sur l’outil pour développeurs open source fourni par GitHub, dit que la filiale Microsoft n’a pas grande importance à moins de vraiment travailler à rendre les logiciels au cœur du métier de Microsoft open source, ce qui les améliorerait eux-mêmes, et la façon dont ils fonctionnent avec d’autres logiciels.

Il affirme pour conclure qu’Open Technologies sera un succès uniquement si elle aide Microsoft à libérer Windows et Microsoft Office.

Comment des hackers adultes peuvent-ils s’assurer de faire émerger une nouvelle génération de hackers libres ?

La réponse d’un père de famille dynamique et avisé 😉

Former la prochaine génération de bidouilleurs open source

Growing the next generation of open source hackers

Dave Neary (Red Hat) – 26 février 2013 – OpenSource.com
(Traduction Framalang : Antoine, cherry, psychoslave, Jeff_, Eijebong, biglittledragoon, goofy, Vero, mathilde, tcit, Quentin, Metal-Mighty, jtanguy, Penguin, Pat, Asta, arnaudbey + anonymes)

En tant que père de trois enfants de 5, 7 et 10 ans, j’ai hâte de partager avec eux les valeurs qui m’ont attiré vers l’open source : partager et créer ensemble des choses géniales, prendre le contrôle de son environnement numérique, adopter la technologie comme moyen de communication plutôt qu’un média de consommation de masse. En d’autres termes :

Comment des bidouilleurs adultes peuvent-ils s’assurer de faire émerger une nouvelle génération de bidouilleurs open source ?

Une des choses que j’ai apprise est qu’il ne faut pas aller trop vite. J’ai mis mes enfants devant Scratch et Sugar à l’âge de 5 et 8 ans, et, bien qu’ils se soient amusés à changer les nombres sur un petit programme que je leur ai montré et aient aimé dessiner leurs propres voitures pour ensuite les diriger sur l’écran, ils étaient trop petits pour comprendre le concept de lier des fonctions entres elles pour arriver à obtenir des comportements plus sophistiqués.

Voici quelques-unes des leçons que j’ai apprises en tant que parent qui, je crois, peuvent être adaptées selon l’âge et les centres d’intérêt de vos enfants.

Un espace à vivre bidouillable

Nous avons encouragé nos garçons à décorer leur chambre, à organiser leurs meubles comme ils voulaient et à avoir leurs propres petits fiefs. Parfois cela nous rend complètement dingues en tant que parents, et, régulièrement, nous devons les aider à ranger, mais leur espace leur appartient.

De même, chaque enfant de plus de 7 ans peut avoir un vrai couteau qu’il peut utiliser pour tailler du bois et couper de la ficelle.

Ingénierie préscolaire

J’adore les jouets qui permettent aux enfants de donner libre cours à leur imagination. En plus c’est génial, parce qu’en tant qu’adulte, je prends autant de plaisir qu’eux à jouer ensemble ! Mes jeux de construction préférés (achetés à peu près au moment où les enfants ont l’habileté nécessaire pour les manipuler) sont les Kapla, les trains en bois, les lots de Duplo, Playmobil, Lego et les voitures Meccano.

Lego et Meccano notamment font un super boulot pour faire des kits adaptés aux enfants de tout âge. Une autre petite astuce est d’encourager le mélange et d’assembler différentes marques de jouets. Nous avons des ponts Kapla passant par-dessus des trains Ikea et des camions Lego qui transportent des personnages Playmobil.

Les Kapla aussi sont très intéressants. Ce sont des planchettes en bois découpées selon des proportions très précises ; elles sont trois fois plus larges qu’épaisses, et cinq fois plus longues que larges. Avec ces simples proportions et la précision des découpes, il est possible de construire des objets très complexes, comme la Tour Eiffel ou une maison Kapla.

Se lancer dans l’électronique

Nous avons un kit Arduino, et mon aîné commence à avoir le niveau pour comprendre comment câbler un circuit, mais il n’a pas encore découvert comment programmer dans le dialecte C propre à Arduino.

Mais même avant quelque chose de ce genre, les arts et les activités artisanales sont un excellent entraînement pour le DIY (NdT : Do It Yourself, c’est-à-dire « Faites-le vous-même »), et nous avons toujours quelques bâtonnets de glaces ou des pinces à linge et un pistolet à colle pour des cadeaux « faits main ».

Puis vous pouvez laisser traîner des tournevis, pinces, multimètres et autres fers à souder, pour que les enfants puissent désosser leurs vieux jouets, ou des appareils électroniques cassés, réparer les choses par eux-mêmes avec de simples circuits électriques, lorsque que quelque chose ne marche pas, et récupérer des pièces détachées pour les intégrer dans leurs futurs projets. Une supervision parentale est recommandée avec le fer à souder jusqu’à ce qu’ils maîtrisent son utilisation.

Apprendre aux enfants à bidouiller

J’adorerais entendre parler de ressources pour que les enfants apprennent à maîtriser la programmation ! Je connais l’existence de la Code Academy et la Khan Academy qui apprennent aux enfants à coder ; et Scratch and Sugar, que j’ai déjà mentionné.

Merci de partager vos propres conseils sur la manière d’endoctriner la prochaine génération de bidouilleurs open source !

Crédit photo : See-Ming Lee (Creative Commons By-Sa)