C’est un Geektionnerd très spécial que nous propose Gee cette semaine (cliquez sur l’image pour l’agrandir).
Vous pouvez également lire les traductions de quelques uns de ses articles que nous avons publié cette semaine, ainsi que ce Manifeste Hacker qui lui va si bien.
Crédit : Simon Gee Giraudot (Creative Commons By-Sa)
Le Framablog a pris l’habitude de suivre les travaux de Bernard Stiegler au sein d’Ars Industrialis. Il faut dire que ça n’est pas tous les jours qu’un philosophe affirme que « le logiciel libre peut redonner sens à nos vies » !
Nous vous proposons ci-dessous le réplication d’une vidéo de Simon Lincelles intitulée « Introduction à l’économie contributive » et co-écrit par Bernard Stiegler.
Malgré quelques inexactitudes, nous partageons l’hypothèse que le logiciel libre (et Wikipédia) représentent un espoir et un modèle pour l’avenir de notre économie.
Remarque : cette vidéo (lien direct Vimeo) est le troisième épisode d’une série initiée ici.
Au delà de l’émotion des circonstances, voici la traduction d’une note d’Aaron Swartz qui pose la question du devenir de nos données après notre mort.
Et pour ce qui concerne le code, le léguer à la FSF est une bonne idée 😉
Cet article est rangé dans le répertoire « 2002 » de son site. Il avait alors 16 ans !
Aaron Swartz – 2002 – Site personnel
(Traduction : Moosh, lgodard, zozio nocture (aka brandelune), aKa, Sky)
Si je me fais renverser par un camion… lisez cette page.
Il y a une vieille blague chez les programmeurs sur qui va gérer le code si son auteur se fait renverser par un camion. Cette page est ici pour assurer que tout le monde sache quoi faire si, pour une raison donnée, je ne suis plus en mesure de conserver mes services Web en fonctionnement.
Je désigne Sean B. Palmer comme mon exécuteur testamentaire virtuel pour l’organisation de ces choses (et Sean, si tu effaces quoi que ce soit, je te hanterai de ma tombe !)
Je demande que le contenu de tous mes disques durs soit rendu public sur aaronsw.com.
Web.Resource.org Sean (ou la personne qu’il désignera) deviendra le nouveau webmaster. Continue de mettre à jour le site et la liste des miroirs, et garantis la persistance des URLs. (Ceci implique que rien de controversé ou d’illégal ne doive être ajouté, à part pour Cryptome.)
Code Source Le copyright pour mon code source sous GPL doit être transféré à la Free Software Foundation. Elle semble avoir une politique raisonnable concernant la mise à disposition du code.
Sites Web Merci de laisser les sites Web opérationnels quand c’est possible, sans modifier les contenus que j’ai écrit quand approprié. Des pages dédiées (par exemple sur aaronsw.com) pourront contenir une note sur ce qui m’est arrivé avec un lien vers des plus d’information. La page d’accueil sur aaronsw.com devra être modifiée avec un lien vers l’ancienne page.
Tombe Je voudrais reposer dans un endroit qui ne me tuera pas. Ce qui veut dire avoir un accès à de l’oxygène (bien qu’un accès direct serait probablement une mauvaise chose), et ne pas avoir à traverser 6 pieds de saleté.
Pour le reste, envoyez un e-mail à Sean. Je suis certain qu’il fera quelque chose de raisonnable.
Si quelque chose m’arrive, merci de mettre à jour le pied de page de cette note avec un lien. Envoyez également un e-mail aux listes concernées et mettez en place une réponse automatique pour mon adresse e-mail afin d’informer les personnes qui m’écrivent. N’hésitez pas à publier les choses que les gens disent à mon propos sur le site. Tout ceci est probablement évident, et je suis certain que vous vous en sortirez.
Oh, et au fait, vous me manquerez tous.
Crédit photo : Doc Searls (Creative Commons By)
Un certain nombre de textes tournent actuellement sur le Net suite au décès d’Aaron Swartz. Parmi eux on trouve « La Conscience d’un hacker » (ou « Le Manifeste du hacker ») datant de… 1986 et que d’aucuns trouvent particulièrement adapté aux circonstances. Et pour cause…
Nous vous le proposons traduit ci-dessous[1]. Il a été rédigé par Loyd Blankenship, (alias The Mentor) juste après son arrestation.
« Oui, je suis un criminel. Mon crime est celui de la curiosité. »
Remarque : Nous sommes en 1986 et c’est par le téléphone que passe le réseau. Un téléphone qui se retrouve alors bloqué par ces « sales gosses » pour la communication classique.
The Mentor – 8 janvier 1986 – Phrack.org
(Traduction : NeurAlien, Moosh, ga3lig, goofy, zozio nocture (aka brandelune), Slystone, KoS, aKa, Martin, lamessen, Sky)
Ce qui suit a été écrit peu de temps après mon arrestation…
Un autre s’est fait prendre aujourd’hui, c’est partout dans les journaux.
« Scandale : Un adolescent arrêté pour crime informatique », « Arrestation d’un hacker après le piratage d’une banque »…
Satanés gosses, tous les mêmes.
Mais vous, dans votre psychologie de costume trois pièces et votre conscience technologique des années 50, avez-vous un jour pensé à regarder le monde avec les yeux d’un hacker ?
Ne vous êtes-vous jamais demandé ce qui l’avait fait agir et quelles forces l’avaient animé ?
Je suis un hacker, entrez dans mon monde…
Mon monde, il commence avec l’école… Je suis plus éveillé que la plupart des autres enfants et les nullités qu’on nous enseigne m’ennuient…
Satanés gamins, ce sont tous les mêmes.
Je suis au collège ou au lycée. J’ai écouté les professeurs expliquer pour la quinzième fois comment réduire une fraction.
J’ai bien compris. « Non Mme Dubois, je n’ai pas montré mon travail. Je l’ai fait dans ma tête ».
Satané gosse. Il a certainement copié. Ce sont tous les mêmes.
J’ai fait une découverte aujourd’hui. J’ai trouvé un ordinateur.
Attends une minute, c’est cool. Ça fait ce que je veux. Si ça fait une erreur, c’est parce que je me suis planté.
Pas parce qu’il ne m’aime pas…
Ni parce qu’il se sent menacé par moi…
Ni parce qu’il pense que je suis un petit malin…
Ni parce qu’il n’aime pas enseigner et qu’il ne devrait pas être là…
Satané gosse. Tout ce qu’il fait c’est jouer. Ce sont tous les mêmes.
Et c’est alors que ça arrive. Une porte s’ouvre…
Les impulsions électroniques déferlent sur la ligne téléphonique comme l’héroïne dans les veines d’un drogué.
Pour trouver dans un Forum le refuge contre la stupidité quotidienne.
« C’est ça… C’est ici que je dois être…»
Ici, je connais tout le monde… Même si je n’ai jamais rencontré personne. Je ne leur ai jamais parlé, et je n’entendrai peut-être plus parler d’eux un jour… Je vous connais tous.
Satané gosse. Encore pendu au téléphone. Ce sont tous les mêmes.
A l’école, on nous a donné des pots de bébé alors qu’on avait les crocs pour un steak…
Les morceaux de viande que vous avez bien voulu nous tendre étaient pré-mâchés et sans goût.
On a été dominé par des sadiques ou ignoré par des apathiques.
Les seuls qui avaient des choses à nous apprendre trouvèrent en nous des élèves de bonne volonté, mais ceux-ci étaient comme des gouttes d’eau dans le désert.
C’est notre monde maintenant… Le monde de l’électron et des commutateurs, la beauté du baud. Nous utilisons un service déjà existant, sans payer ce qui pourrait être bon marché si ce n’était pas géré par des profiteurs avides, et c’est nous que vous appelez criminels.
Nous explorons… et vous nous appelez criminels.
Nous recherchons la connaissance… et vous nous appelez criminels.
Nous existons sans couleur de peau, sans nationalité, sans dogme religieux… et vous nous appelez criminels.
Vous construisez des bombes atomiques, vous financez les guerres, vous assassinez et trichez, vous manipulez et vous nous mentez en essayant de nous faire croire que c’est pour notre propre bien… et pourtant c’est nous qui sommes les criminels.
Oui, je suis un criminel. Mon crime est celui de la curiosité.
Mon crime est celui de juger les gens selon ce qu’ils pensent et disent, pas selon leur apparence.
Mon crime est d’être plus malin que vous, quelque chose que vous ne me pardonnerez jamais.
Je suis un hacker, et ceci est mon manifeste.
Vous pouvez arrêter un individu, mais vous ne pouvez pas tous nous arrêter…
Après tout, nous sommes tous les mêmes.
The Mentor
Crédit photo : Elizabeth Brossa (Creative Commons By-Nc-Sa)
[1] Il en existait une première traduction mais elle était « perfectible ».
Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.
Traduction Framalang : , , , , , , , , , , , , , + Cédric Corazza
Kai Blin
Kai Blin est un bio-informaticien qui mène des recherches sur les antibiotiques dans le cadre de ses activités quotidiennes, tant sur ordinateur qu’au labo. Il est très heureux de pouvoir diffuser le logiciel développé dans le cadre de ses activités professionnelles sous licence open source. Vivant dans la charmante ville de Tübingen, dans le sud de l’Allemagne, Kai passe une partie de ses soirées sur l’ordinateur, à programmer pour le projet Samba. Il consacre la majorité de son temps libre restant au théâtre, où il participe aussi bien à la performance scénique qu’à la construction d’accessoires et à la régie technique dans les coulisses.
Écrire des correctifs et les proposer est souvent la première interaction concrète que vous pouvez avoir avec un projet open source. C’est la première impression que vous donnez aux développeurs présents. Proposer de « bons » premiers correctifs, ou tout du moins jugés comme tels par le projet auquel vous contribuez, vous rendra la vie plus facile. Les règles précises d’écriture du correctif, de la façon de le soumettre au projet et tous les autres détails nécessaires vont sans doute varier selon les divers projets auxquels vous voulez contribuer. Mais j’ai trouvé quelques règles générales que l’on retrouve presque à chaque fois. Et c’est ce dont traite cet article.
Le fil rouge de ce livre est « ce que j’aurais aimé savoir avant de commencer », aussi permettez-moi de commencer par l’histoire de mes premiers correctifs. J’ai été impliqué sérieusement dans l’écriture de code pour la première fois pendant le Google Summer of Code™ de 2005. Le projet Wine avait accepté que j’implémente un chiffrement NTLM basé sur des outils connexes à Samba. Wine est un projet à committer unique, ce qui signifie que seul le développeur principal, Alexandre Julliard, possède les autorisations de commit sur le dépôt principal. En 2005, Wine utilisait encore CVS comme système de gestion de versions. Quand le projet a démarré et que j’ai reçu le courriel me disant que j’étais accepté, j’ai contacté mon mentor sur IRC et me suis mis au travail.
J’alignais joyeusement les lignes de code et bientôt j’ai pu implémenter les premières fonctionnalités. J’ai produit un correctif et l’ai soumis à mon mentor pour qu’il fasse une relecture. Au temps du CVS, il fallait renseigner toutes les options de diff(1) manuellement, mais je m’étais particulièrement documenté sur la partie cvs diff -N -u > ntlm.patch. De cette façon, j’avais le fichier que je pouvais envoyer à mon mentor. En fait, c’est quelque chose que j’ai bien fait. Et c’est la première chose que vous devriez prendre en compte quand vous préparez un correctif. Le résultat classique de la commande diff est sans doute plus facile à lire pour un ordinateur, mais je n’ai jamais rencontré un humain préférant le résultat classique au résultat d’un diff unifié. Grâce à l’option -u , diff utilise les notations + + + et - - -
Par exemple, le diff qui suit est le résultat de la réécriture de « Hello, World! » en Python, version suédoise.
diff —git a/hello.py b/hello.py index 59dbef8..6334aa2 100644 --- a/hello.py +++ b/hello.py @@ -1,4 +1,4 @@ #!/usr/bin/env python # vim: set fileencoding=utf-8 -print "Hello, world!" +print "Halla, varlden!"
La ligne qui commence par « - » est la ligne supprimée, celle qui commence par « + » est celle qui va être ajoutée. Les autres lignes permettent à l’outil de correction de faire son travail.
J’ai envoyé le diff unifié que je venais de créer à mon mentor qui m’en a fait une review(2) en me signalant beaucoup d’éléments à modifier. J’ai effectué les corrections et lui ai renvoyé un nouveau diff peu de temps après. Le cycle d’analyse du code a continué durant toute la durée du GSoC et mon correctif ne cessait de grossir. Quand la date de livraison est arrivée, je me suis retrouvé avec un correctif monstrueux dans lequel étaient inclus tous mes changements. Naturellement, j’ai eu beaucoup de mal à obtenir une review de mon correctif, sans parler de le faire accepter. Pour finir, Alexandre refusa de regarder plus avant le correctif tant que je ne l’aurais pas scindé. Les règles en usage chez Wine exigent que les correctifs soient de petites étapes logiques ajoutant une fonctionnalité. Chaque correctif doit faire quelque chose d’utile et pouvoir être compilé.
De fait, scinder un énorme correctif existant en différentes parties cohérentes individuellement et qui peuvent être compilées représente beaucoup de travail. C’était même d’autant plus de travail que je ne connaissais qu’une seule manière de le faire : écrire un petit correctif, créer le diff, le proposer à la validation, mettre à jour ma contribution locale et écrire alors le correctif suivant. Peu de temps après que j’ai commencé à envoyer mes premiers petits correctifs, Wine est entré dans une phase de gel des fonctionnalités d’un mois menant à la version 0.9.0 bêta. Je suis resté sur le correctif suivant pendant un mois avant de pouvoir continuer et j’ai finalement envoyé mon dernier correctif en novembre. Complètement frustré par cette expérience, j’ai décidé que je ne voulais plus jamais avoir à faire avec la communauté Wine.
Ma frustration perdura jusqu’à ce que des personnes qui utilisaient réellement mon code commencent à me poser des questions sur celui-ci en février 2006. Mon code était vraiment utile ! Ils voulaient également davantage de fonctionnalités. Quand Google annonça qu’il reconduirait le GSoC en 2006, mes projets pour l’été étaient clairs. Maintenant que Wine avait basculé de diff à git en décembre 2005, je savais que je ne serais pas ennuyé par des gels de fonctionnalités, puisque je pouvais finalement créer tous mes petits correctifs localement. La vie était belle.
Ce n’est que lorsque je suis tombé sur une interface de git (appelée porcelaine dans le langage git) qui émulait le comportement de Quilt que j’ai appris qu’il y avait des outils qui auraient pu rendre ma vie plus facile, même en 2005.
Maintenant que je vous ai raconté comment j’ai réussi à me planter avec l’envoi de correctifs, permettez-moi de poursuivre avec quelques conseils pour éviter les pièges.
Mon premier conseil est de lire attentivement toutes les directives de soumission de correctifs que peut avoir le projet auquel vous voulez contribuer. Celles-ci, ainsi que les normes de style de codage, doivent être consultées avant même de commencer à coder.
Même si ce n’est pas explicitement indiqué dans les directives de soumission des correctifs, vous devez vraiment, vraiment envoyer le résultat d’un diff unifié. Je n’ai encore rencontré aucun projet qui préfère la sortie non unifiée du diff. Les diffs unifiés rendent la révision du correctif beaucoup plus facile. Ce n’est pas par hasard que les programmes de gestion de version modernes utilisent automatiquement ce format dans leurs commandes diff par défaut.
En ce qui concerne la gestion de versions moderne, vous devriez vraiment utiliser un système de gestion de versions distribué (DVCS) pour travailler localement sur le code. Git et Mercurial sont les choix les plus populaires de nos jours, quoique Bazaar puisse aussi très bien faire l’affaire. Même si le projet auquel vous voulez contribuer utilise toujours un système de gestion de version centralisé, être en mesure d’envoyer vos changements de manière itérative est une très bonne chose. Tous les outils de gestion de versions distribués mentionnés ci-dessus devraient être capables d’importer des changements depuis un SVN ou un CVS. Vous pourrez y aller et apprendre doucement Quilt mais, sérieusement, le futur passe par les systèmes de gestion de versions distribués.
Quand je dois examiner des correctifs, les plus ennuyeux à traiter sont ceux qui sont trop gros ou qui tentent de faire de nombreuses choses en même temps. Les correctifs qui ne font qu’une chose à la fois sont plus faciles à traiter. Au final, ils vous faciliteront la vie quand vous devrez déboguer les erreurs qu’auront manquées à la fois l’auteur et le vérificateur.
Après avoir proposé votre correctif, gardez un œil sur les canaux de communication du projet et sur votre correctif. Si vous n’avez eu aucun retour au bout d’une semaine, vous devriez poliment en demander un. En fonction de la façon dont le projet gère les propositions de correctif, celui-ci pourrait être noyé dans le bruit. N’espérez pas voir votre correctif retenu du premier coup. Il faut, en général, quelques essais pour s’habituer au style d’un nouveau projet. En tant que contributeur néophyte, personne ne vous en voudra pour ça, à condition d’avoir presque tout bon. Assurez-vous seulement de corriger ce que les développeurs vous ont indiqué et envoyez une seconde version du correctif.
Écrire de bons correctifs n’est pas difficile. Il y a deux ou trois choses à prendre en considération. Mais après en avoir écrit quelques-uns vous devriez être au point sur celles-ci. Un système moderne de contrôle de version (distribué) et le workflow (Ndt : flux de production) qui en résulte gèreront de fait la plupart des choses que j’ai mentionnées. Si vous n’avez qu’une chose à retenir, c’est ceci :
Les quelques lignes directrices ci-dessus devraient vous aider à bien faire la plupart des choses, sinon toutes, quand vous soumettrez vos premiers correctifs. Bon codage.
(1) Un diff (abréviation de différence) est un fichier qui affiche le résultat d’une comparaison entre deux éléments (en général, des lignes de code). Pour en savoir plus : http://fr.wikipedia.org/wiki/Diff
(2) Review : révision minutieuse http://fr.wiktionary.org/wiki/review
Il se passe quelque chose d’assez extraordinaire actuellement sur Internet suite à la tragique disparition d’Aaron Swartz : des centaines de professeurs et scientifiques du monde entier ont décidé de publier spontanément leurs travaux en Libre Accès !
Il faut dire que sa mort devient chaque jour plus controversée, les pressions judiciaires dont il était l’objet n’étant peut-être pas étrangères à son geste. Comme on peut le lire dans Wikipédia : « En juillet 2011, le militant américain pour la liberté de l’Internet Aaron Swartz fut inculpé pour avoir téléchargé et mis à disposition gratuitement un grand nombre d’articles depuis JSTOR. Il se suicide le 11 janvier 2013. En cas de condamnation, il encourait une peine d’emprisonnement pouvant atteindre 35 ans et une amende s’élevant jusqu’à 1 million de dollars. »
On peut suivre l’évolution du mouvement derrière le hashtag #pdftribute (pdf hommage) qui a déjà son site et son compte Twitter dédiés.
Dans la foulée nous avons décidé de traduire ensemble un autre article important d’Aaron Swartz (rédigé à 21 ans), en lien direct avec la motivation de tous ceux qui lui rendent ainsi un vibrant, concret et utile hommage : Guerilla Open Access Manifesto.
Ce manifeste s’achève sur cette interrogation : « Serez-vous des nôtres ? »
Remarque : L’émouvante photo ci-dessous représente Aaron Swartz a 14 ans en compagnie de Larry Lessig. On remarquera son bien joli tee-shirt 😉
Guerilla Open Access Manifesto
Aaron Swartz – juillet 2008 – Internet Archive
(Traduction : Gatitac, albahtaar, Wikinade, M0tty, aKa, Jean-Fred, Goofy, Léna, greygjhart + anonymous)
L’information, c’est le pouvoir. Mais comme pour tout pouvoir, il y a ceux qui veulent le garder pour eux. Le patrimoine culturel et scientifique mondial, publié depuis plusieurs siècles dans les livres et les revues, est de plus en plus souvent numérisé puis verrouillé par une poignée d’entreprises privées. Vous voulez lire les articles présentant les plus célèbres résultats scientifiques ? Il vous faudra payer de grosses sommes à des éditeurs comme Reed Elsevier.
Et il y a ceux qui luttent pour que cela change. Le mouvement pour le libre accès s’est vaillamment battu pour s’assurer que les scientifiques ne mettent pas toutes leurs publications sous copyright et s’assurer plutôt que leurs travaux seront publiés sur Internet sous des conditions qui en permettent l’accès à tous. Mais, même dans le scénario le plus optimiste, la politique de libre accès ne concerne que les publications futures. Tout ce qui a été fait jusqu’à présent est perdu.
C’est trop cher payé. Contraindre les universitaires à débourser de l’argent pour lire le travail de leurs collègues ? Numériser des bibliothèques entières mais ne permettre qu’aux gens de chez Google de les lire ? Fournir des articles scientifiques aux chercheurs des plus grandes universités des pays riches, mais pas aux enfants des pays du Sud ? C’est scandaleux et inacceptable.
Nombreux sont ceux qui disent : « Je suis d’accord mais que peut-on y faire ? Les entreprises possèdent les droits de reproduction de ces documents, elles gagnent énormément d’argent en faisant payer l’accès, et c’est parfaitement légal, il n’y a rien que l’on puisse faire pour les en empêcher. » Mais si, on peut faire quelque chose, ce qu’on est déjà en train de faire : riposter.
Vous qui avez accès à ces ressources, étudiants, bibliothécaires, scientifiques, on vous a donné un privilège. Vous pouvez vous nourrir au banquet de la connaissance pendant que le reste du monde en est exclu. Mais vous n’êtes pas obligés — moralement, vous n’en avez même pas le droit — de conserver ce privilège pour vous seuls. Il est de votre devoir de le partager avec le monde. Et c’est ce que vous avez fait : en échangeant vos mots de passe avec vos collègues, en remplissant des formulaires de téléchargement pour vos amis.
Pendant ce temps, ceux qui ont été écartés de ce festin n’attendent pas sans rien faire. Vous vous êtes faufilés dans les brèches et avez escaladé les barrières, libérant l’information verrouillée par les éditeurs pour la partager avec vos amis.
Mais toutes ces actions se déroulent dans l’ombre, de façon souterraine. On les qualifie de « vol » ou bien de « piratage », comme si partager une abondance de connaissances était moralement équivalent à l’abordage d’un vaisseau et au meurtre de son équipage. Mais le partage n’est pas immoral, c’est un impératif moral. Seuls ceux qu’aveugle la cupidité refusent une copie à leurs amis.
Les grandes multinationales, bien sûr, sont aveuglées par la cupidité. Les lois qui les gouvernent l’exigent, leurs actionnaires se révolteraient à la moindre occasion. Et les politiciens qu’elles ont achetés les soutiennent en votant des lois qui leur donnent le pouvoir exclusif de décider qui est en droit de faire des copies.
La justice ne consiste pas à se soumettre à des lois injustes. Il est temps de sortir de l’ombre et, dans la grande tradition de la désobéissance civile, d’affirmer notre opposition à la confiscation criminelle de la culture publique.
Nous avons besoin de récolter l’information où qu’elle soit stockée, d’en faire des copies et de la partager avec le monde. Nous devons nous emparer du domaine public et l’ajouter aux archives. Nous devons acheter des bases de données secrètes et les mettre sur le Web. Nous devons télécharger des revues scientifiques et les poster sur des réseaux de partage de fichiers. Nous devons mener le combat de la guérilla pour le libre accès.
Lorsque nous serons assez nombreux de par le monde, nous n’enverrons pas seulement un puissant message d’opposition à la privatisation de la connaissance : nous ferons en sorte que cette privatisation appartienne au passé. Serez-vous des nôtres ?
Aaron Swartz
Crédit photo : Rich Gibson (Creative Commons By)
Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.
Traduction Framalang : , , , , , , , , , , , , , , + Sinma
Henri Bergius
Henri Bergius est le fondateur de Midgard(1), un dépôt de contenu pour les logiciels libres. Il a aussi été longtemps impliqué dans la géolocalisation d’ordinateurs de bureaux sous Linux ainsi que dans les communautés Maemo et Meego. Il dirige un petit cabinet de conseil nommé Nemein, bidouille CoffeeScript et PHP et passe beaucoup de son temps à faire de la moto dans des régions reculées du continent Eurasien. Il vit dans la froide ville nordique d’Helsinki, en Finlande.
Il se peut qu’il existe un système complètement nouveau dans lequel vous pouvez être défini davantage par qui vous êtes plutôt que par ce que vous possédez, par ce que vous avez créé et partagé, parce que d’autres personnes ont ensuite construit sur cette base
– John Seely Brown, ancien directeur de Xerox PARC dans An Optimist’s Tour of the Future (Mark Stevenson, 2010)
Le monde du logiciel libre est pour l’essentiel divisé en tribus rassemblées autour de choses appelées projets. Il existe des projets majeurs tels que GNOME(2), KDE(3) ou Drupal(4) et il existe bien d’autres projets plus modestes tournant autour d’une seule application ou bibliothèque logicielle.
En fait, les qualifier de « projets » est un peu ridicule.
Selon moi, un projet est l’organisation d’un effort visant un but que l’on puisse atteindre et comprend un calendrier avec dates de début et de fin. Ainsi, GNOME 3.1 serait par exemple un projet tandis que GNOME, pris dans son ensemble, n’en est pas un. Il s’agit d’une communauté d’individus qui entretiennent et créent le corps d’un logiciel par de petits efforts variés ou des projets.
Assez de pédantisme. Le souci avec le concept de projet c’est qu’il finit par maintenir une séparation entre les personnes. Cela crée des communautés isolées souvent réticentes voire incapables de collaborer avec « la concurrence ». Mais en fin de compte, toutes ces communautés sont composées de personnes écrivant des logiciels libres. Et ce sont elles qui décident de l’utilisation possible ou non d’un logiciel dans différents environnements.
En fin de compte, nous voulons tous que le logiciel que nous avons créé soit utilisé par d’autres. Mieux encore : nous voulons que les autres joignent leurs efforts aux nôtres et créent des choses sympa à partir de ce que nous avons créé. Après tout, ceci constitue le cœur même des logiciels libres.
Alors pourquoi érigeons-nous ces murs autour de nous ? Garder une communauté isolée ne fait que favoriser une mentalité de type « nous contre eux ». Les incompatibilités des différents langages de programmation contribuent déjà fortement à notre division. Pourquoi en rajouter ?
Il est une chose que j’aurais voulu savoir quand j’ai démarré, dans cette période optimiste des « .com » de la fin des années 90 : c’est qu’en réalité le développement de logiciels ne gagne rien à s’isoler. Avec un peu d’efforts nous pouvons partager nos logiciels et nos idées par le biais de communautés, ce qui renforce et améliore à la fois les logiciels et les communautés.
Quand j’ai démarré ma carrière dans le logiciel libre, c’était l’époque des grands projets. Netscape ouvrait son code source, la fondation Apache prenait forme et des sociétés de capital-risque venaient de partout. Tenter de bâtir sa communauté devenait la norme. C’était le chemin assuré vers la gloire, la fortune et la réalisation de choses extraordinaires.
Alors nous avons construit nos propres infrastructures web. À ce moment-là il n’y en avait pas tant que cela, en particulier pour le tout jeune langage PHP. Le PHP n’était même pas notre premier choix. Nous l’avions seulement choisi au terme d’un long débat sur l’utilisation de Scheme(5) que notre développeur principal préférait. Mais le PHP gagnait alors en popularité, devenant le langage de programmation de la Toile. Et nous voulions construire la Toile.
Au début, les choses semblaient prometteuses. Beaucoup de développeurs rejoignaient notre communauté et commençaient à y contribuer. Il y a même eu des entreprises fondées autour de Midgard. Notre infrastructure gagnait en fonctionnalités et devenait de plus en plus liée à Midgard.
Avec le recul, c’est là que nous avons fait une erreur. Nous avons positionné Midgard pour être distinct du PHP lui-même. Quelque chose que vous installeriez séparément, et utiliseriez comme base pour y construire des sites entiers. Il fallait soit suivre notre voie, soit suivre celle de tout le monde.
Avec Midgard, vous deviez utiliser notre interface de dépôt de contenus pour tout, aussi bien pour notre gestion des utilisateurs que pour le modèle de permissions. Vous deviez utiliser notre système de modèles et stocker beaucoup de votre code dans le dépôt au lieu d’utiliser un système de fichiers.
Ceci ne passait évidemment pas très bien auprès de l’ensemble de la communauté PHP. Nos idées leur semblaient étranges, et Midgard, à ce moment-là, était même distribué en tant que gigantesque correctif à la base de code puisqu’on ne pouvait pas charger de modules avec PHP3.
Les années ont passé et la popularité de PHP a connu des hauts et des bas. Pendant ce temps, la communauté Midgard est restée relativement constante : un petit groupe soudé faisant des progrès sur le long terme mais séparé du monde plus large de PHP.
Nous nous sommes toujours demandé pourquoi il était si difficile d’interagir avec le monde PHP. Même d’autres communautés faisant des choses complètement différentes, comme l’environnement de bureau GNOME, semblaient plus faciles à approcher. Ce n’est que récemment, après des années d’isolement, que nous avons pris conscience du problème. En résumé : les infrastructures nous séparent alors que les bibliothèques nous permettent de partager notre code et nos expériences.
En définitive, les logiciels ont pour objectif l’automatisation, la construction d’outils que les autres peuvent utiliser pour résoudre des problèmes ou se connecter entre eux. Avec les logiciels, ces outils comportent plusieurs couches. Il existe des services de bas niveau comme les systèmes d’exploitation, puis les bibliothèques, les infrastructures, les boîtes à outils et enfin les applications elles-mêmes.
Les applications sont toujours écrites pour des usages spécifiques, donc entre elles il existe peu de possibilités de partage de code.
Les possibilités les plus séduisantes se situent au niveau des bibliothèques et infrastructures. Une infrastructure, si elle est suffisamment générique, peut généralement être utilisée pour construire différentes sortes de logiciels. Une bibliothèque, quant à elle, peut être utilisée pour apporter un élément particulier de logique ou de connectivité là où le besoin s’en fait sentir. De mon point de vue, c’est dans cette couche que le plus gros de la programmation devrait être fait, avec des applications spécifiques qui ne sont que des connexions entre diverses bibliothèques au sein d’une infrastructure qui s’occupe alors de faire tourner l’application en question.
Qu’est-ce qu’une bibliothèque et qu’est-ce qu’une infrastructure ? Les gens utilisent souvent ces termes indifféremment bien qu’il existe une règle grossière qui permet de les différencier : une bibliothèque est une ressource à laquelle votre code fait appel, alors qu’une infrastructure est une ressource qui fait appel à votre code.
Si vous voulez que votre code soit utilisé et amélioré, le meilleur moyen est de maximiser le nombre de ses utilisateurs et contributeurs potentiels. Avec le logiciel libre, cela fonctionne en s’assurant que votre code peut être adapté à de multiples situations et environnements.
En définitive, ce que vous voulez développer c’est une bibliothèque. Les bibliothèques c’est cool.
Le plus difficile est de franchir la barrière du « eux-contre-nous ». Les développeurs de l’autre communauté sont des bidouilleurs concevant du logiciel libre, tout comme vous. Il suffit donc de franchir le pas et de commencer à leur parler.
Une fois le débat engagé, voici quelques points que j’ai trouvés importants quant à l’application effective des idées communes ou des bibliothèques au-delà des frontières du projet
Bonne chance pour abattre les frontières du projet ! Dans la plupart des cas, cela fonctionne si vos idées sont bonnes et présentées avec un esprit ouvert. Mais même si vous ne trouvez pas de terrain d’entente, tant que votre application remplit sa fonction pour vous, ça n’a pas été fait en vain. Après tout, ce qui compte c’est de proposer des logiciels et d’offrir la meilleure expérience utilisateur possible.
(1) http://midgard-project.org/
(2) gnomefr.org
(3) fr.kde.org
(4) drupalfr.org
(5) http://fr.wikipedia.org/wiki/Scheme
Crédit photo : mommy peace – (CC BY-NC-SA 2.0)
Une vague d’émotion sans précédente s’est emparée du Web (que j’ai l’habitude de lire) après la récente tragique disparition d’Aaron Swartz à l’âge de 26 ans. Il faut dire qu’il en avait fait des choses en une pourtant si courte période !
Nous avons décidé de lui rendre hommage en traduisant collectivement l’un des articles de son blog où il évoque son parcours et ses nombreux projets.
Cet article a été initialement écrit en 2007. Aaron avait alors à peine 20 ans…
Aaron Swartz – 18 août 2008 – Blog personnel
(Traduction : ga3lig, clementd, Amic, tth, bld, KoS, Havok Novak, a_r_n_a_u_d_b, jpcw + anonymous)
L’écrivain américain Kurt Vonnegut avait l’habitude de toujours nommer ses interventions « Comment obtenir un travail comme le mien » pour parler ensuite de ce que bon lui semblait. Je suis plutôt dans la situation inverse. On m’a informé que je pouvais parler de n’importe quel sujet qui m’intéressait et j’ai donc décidé, plutôt que de pontifier sur l’avenir d’Internet ou de la puissance de la collaboration massive, que la discussion la plus intéressante était probablement celle-ci : « Comment bénéficier d’un travail comme le mien » (NdT : ce texte a été rédigé en préparation d’une conférence donnée au congrès informatique Tathva à NIT Calicut en 2007).
Comment ai-je réussi à dégotter ce job ? Sans aucun doute, la première étape a été de faire le bon choix, c’est-à-dire les bons gènes : à la naissance, j’étais un garçon, blanc, et américain. Ma famille était relativement aisée et mon père travaillait dans l’industrie informatique. Hélas, il n’existe à ce jour aucun moyen d’influer sur ce genre de choses donc je ne vous serai probablement d’aucune utilité sur ce point.
En revanche, quand j’ai débuté, j’étais un très jeune gamin coincé dans une petite ville au milieu de la campagne. J’ai donc dû trouver quelques astuces pour m’en sortir. En espérant rendre la vie un peu moins injuste, je me suis dit que je pourrais les partager avec vous.
La première chose que j’ai faite, et qu’a priori vous avez tous déjà faite, c’était d’apprendre des choses à propos des ordinateurs, d’Internet et de la culture Internet. J’ai lu un paquet de livres, j’ai lu une quantité énorme de pages Web et j’ai essayé des trucs. J’ai commencé par rejoindre des listes de diffusion et j’ai essayé de comprendre les discussions jusqu’à ce que je me sente assez à l’aise pour me lancer et y participer à mon tour. Ensuite, j’ai regardé des sites Web et j’ai essayé de construire le mien. À la fin, j’ai appris à construire des applications Web et j’ai commencé à le faire. J’avais treize ans.
Le premier site que j’ai réalisé s’appelait get.info. L’idée était d’avoir une encyclopédie en ligne gratuite, que chacun pourrait éditer, ou compléter, ou réorganiser à travers son navigateur. J’ai tout développé, ajouté un tas d’options sympas, testé ça sur tous les types de navigateurs et j’en étais très fier. J’ai même remporté un prix pour la meilleure application Web de cette année-là. Malheureusement, les seules personnes que je connaissais à cette époque étaient d’autres jeunes de mon école, donc je n’avais pas grand monde pour écrire des articles d’encyclopédie. (Heureusement, quelques années plus tard, ma mère m’a montré ce nouveau site appelé « Wikipédia » qui faisait la même chose.)
Le second site s’appellait my.info. L’idée était qu’au lieu d’aller à la recherche d’informations sur toutes sortes de pages Web différentes, il suffisait d’avoir un programme qui allait chercher les nouveautés dans toutes ces pages Web et qui les regrouperait à un seul endroit. Je l’ai construit et je l’ai fait marcher, mais il se trouve qu’à l’époque, je n’étais pas le seul à avoir eu ce genre d’idée. Beaucoup de gens travaillaient sur cette nouvelle technique, appelée alors « syndication ». Un groupe d’entre eux s’est mis à part et a décidé de travailler sur une spécification appelée RSS 1.0, et je les ai rejoints.
C’était l’été, je n’étais pas à l’école et je n’avais pas de boulot, j’avais donc beaucoup de temps libre à disposition. Et je l’ai entièrement consacré à lire la liste de diffusion de RSS 1.0 et à faire toutes sortes de travaux bizarres et tout ce qu’il y avait d’autre à faire. Assez rapidement, on m’a demandé si je voulais devenir membre du groupe, et je me suis retrouvé être co-auteur, puis co-éditeur de la spécification RSS 1.0.
RSS 1.0 était construit au-dessus d’une technologie appelée RDF, source de débats agités sur les listes de diffusion de RSS. J’ai donc commencé à m’intéresser à RDF, j’ai rejoint les listes de diffusion autour de RDF, lu des choses, posé des questions idiotes pour lentement commencer à comprendre comment ça marchait. Assez rapidement, je devenais connu dans le petit monde du RDF et quand ils ont annoncé la création d’un nouveau groupe de travail destiné à créer la prochaine spécification RDF, j’ai décidé de m’y glisser.
Premièrement, j’ai demandé aux membres du groupe de travail si je pouvais m’y joindre. Ils m’ont répondu négativement. Mais je voulais vraiment faire partie de ce groupe de travail, alors j’ai décidé de trouver un autre moyen. J’ai lu le règlement du W3C, qui expliquait le fonctionnement d’un groupe de travail. Les règles indiquaient que, bien que se réservant le droit de rejeter toute demande d’adhésion individuelle, il suffisait que l’une des organisations faisant partie des membres officiels du W3C sollicite la participation d’un candidat pour qu’elle soit acceptée d’emblée. Ainsi, j’ai examiné en détail la liste des organisations membres du W3C, découvert celle qui me paraissait la plus accessible et lui ai demandé de m’inclure dans ce groupe de travail. Et c’est ce qu’ils ont fait !
Faire partie d’un groupe de travail impliquait des communications téléphoniques hebdomadaires avec les autres membres, un tas de discussions sur des listes de diffusion et sur IRC, de temps à autre de voyager vers d’étranges villes pour des rencontres réelles et une quantité de prises de contact avec des personnes à connaître partout.
J’étais aussi un chaud partisan de RDF, j’ai ainsi œuvré ardemment à convaincre d’autres de l’adopter. Quand j’ai découvert que le professeur Lawrence Lessig lançait une nouvelle organisation appelée Creative Commons, je lui ai transmis un courriel lui conseillant d’adopter RDF pour son projet et lui ai expliqué pourquoi. Quelques jours après, il me répondit : « Bonne idée. Pourquoi ne le ferais-tu pas pour nous ? »
Donc, j’ai fini par rejoindre les Creative Commons, qui m’ont fait m’envoler vers toutes sortes de conférences et de réunions, et je me suis retrouvé en train de rencontrer encore plus de gens. Parmi tous ces gens qui commençaient à savoir qui j’étais, j’en suis arrivé à me faire des amis dans un paquet d’endroits et de domaines différents.
Puis j’ai laissé tout ça de côté et je suis allé à l’université pour un an. Je suis allé a l’université de Stanford, une petite école idyllique en Californie où le soleil brille toujours, où l’herbe est toujours verte et où les jeunes sont toujours dehors à se faire bronzer. Il y a des enseignants excellents et j’ai sans aucun doute beaucoup appris, mais je n’y ai pas trouvé une atmosphère très intellectuelle étant donné que la plupart des autres jeunes se fichaient apparemment profondément de leurs études.
Mais vers la fin de l’année, j’ai reçu un courriel d’un écrivain nommé Paul Graham qui disait démarrer un nouveau projet, Y Combinator. L’idée derrière Y Combinator était de trouver un groupe de développeurs vraiment talentueux, les faire venir à Boston pour l’été, leur donner un peu d’argent et la base administrative pour lancer une société. Ils travaillent alors très, très dur pour apprendre tout ce dont ils ont besoin de savoir sur le monde des affaires, en les mettant en contact avec des investisseurs, des clients, etc. Et Paul suggéra que je m’inscrive.
Donc je l’ai fait, et après beaucoup de peine et d’efforts, je me suis retrouvé à travailler sur un petit site appelé Reddit.com. La première chose à savoir à propos de Reddit était que nous n’avions aucune idée de ce que nous étions en train de faire. Nous n’avions pas d’expérience dans les affaires, nous n’avions pratiquement pas d’expérience en création de logiciels au niveau qualité d’un produit fini. Et nous n’avions aucune idée si, ou pourquoi, ce que nous faisions fonctionnait. Chaque matin, nous nous levions et nous vérifiions que le serveur n’était pas tombé en panne et que le site ne croulait pas sous les messages indésirables, et que nos utilisateurs étaient toujours présents.
Lorsque j’ai commencé à Reddit, la croissance était lente. Le site avait été mis en ligne très tôt, quelques semaines après avoir commencé à travailler dessus, mais pendant les trois premiers mois, il a difficilement atteint trois mille visiteurs par jour, ce qui représente un minimum pour un flux RSS utilisable. Nous avons ensuite, lors d’une session marathon de codage de quelques semaines, transféré le site de Lisp à Python et j’ai écrit un article sur mon blog au sujet de cet exploit. Il a beaucoup attiré l’attention (même l’enfer ne peut déclencher autant de colère que celle d’un fan de Lisp mécontent) et encore aujourd’hui les gens que je rencontre en soirée, lorsque que je mentionne que j’ai travaillé à Reddit, disent : « Oh, le site qui a migré depuis Lisp. »
C’est à ce moment-là que le trafic a vraiment commencé à décoller. Dans les trois mois qui ont suivi, le trafic a doublé à deux reprises. Chaque matin, nous nous levions pour vérifier les statistiques et voir comment nous nous en sortions, vérifier si une nouvelle fonctionnalité que nous avions lancée nous avait attiré plus de monde, ou si le bouche à oreille continuait de faire parler de notre site, ou encore si tous nos utilisateurs nous avaient abandonnés. Et, chaque jour, le nombre de visiteurs progressait. Mais nous ne pouvions nous empêcher d’avoir l’impression que la croissance du trafic était encore plus rapide lorsque nous arrêtions de travailler sur le site.
Nous n’avions toujours pas d’idée sur la façon de gagner de l’argent. Nous avons vendu des t-shirts sur le site, mais, chaque fois, l’argent récupéré sur la vente servait à racheter encore plus de t-shirts. Nous avons signé avec un acteur majeur de la publicité en ligne pour vendre de la publicité sur notre site, mais cela n’a guère fonctionné, en tout cas pas pour nous, et il était rare que nous touchions, en réalité, plus de deux dollars par mois. Une autre idée était de commercialiser, sous licence, le savoir-faire « Reddit » pour permettre à d’autres de monter des sites sur le modèle Reddit. Mais nous n’avons trouvé personne d’intéressé pour acquérir notre licence.
Rapidement, Reddit a acquis des millions d’utilisateurs chaque mois, un chiffre qui dépasse de loin le magazine américain moyen. Je le sais, car j’ai discuté, à cette période, avec de nombreuses maisons d’édition. Ils se sont tous demandés comment le charme de Reddit pourrait opérer pour eux.
De plus, les sites d’actualités en ligne ont commencé à voir que Reddit pourrait leur envoyer un énorme trafic. Ils ont pensé, d’une certaine manière, encourager cela en ajoutant un lien « reddit this » à tous leurs articles. Pour autant que je sache, ajouter ces liens n’améliore pas vraiment votre chance de devenir populaire sur Reddit (bien que cela rende votre site plus moche), mais cela nous a offert beaucoup de publicité gratuite.
Assez rapidement, la discussion avec nos partenaires se dirigeait vers une négociation d’acquisition. L’acquisition : la chose dont nous avions toujours rêvé ! Il n’y aurait plus à s’inquiéter de faire du profit. Des entreprises externes se chargeaient de cette responsabilité en contrepartie de faire notre fortune. Nous avons tout laissé tomber pour négocier avec nos acheteurs. Et ensuite, cela est resté à l’abandon.
Nous avons négocié pendant des mois. Au début, nous débattions sur le prix. Nous préparions des « business plans » et des feuilles de calcul, puis allions au siège social pour faire des présentations et affronter des réunions et des appels téléphoniques sans fin. Finalement, ils refusèrent notre prix et nous sommes donc repartis. Plus tard, ils changèrent d’attitude, nous nous sommes serrés la main et nous étions d’accord sur la transaction pour finalement commencer à renégocier sur certains autres points cruciaux, et nous éloigner à nouveau. Nous avons dû nous retirer trois ou quatre fois avant d’obtenir un contrat acceptable. Au final, nous avons dû arrêter de travailler efficacement pendant six mois.
Je commençais à devenir malade d’avoir à consacrer autant de temps à l’argent. Nous commencions tous à être affectés par le stress et le manque de travail productif. Nous avons commencé à nous disputer et ensuite à ne plus nous parler, avant de redoubler d’efforts pour retravailler ensemble, pour retomber finalement dans nos errements. L’entreprise a failli se désintégrer avant que la transaction ne se concrétise.
Mais finalement, nous sommes allés chez nos avocats pour signer tous les documents et le lendemain matin, l’argent était sur nos comptes. C’était terminé.
Nous nous sommes tous envolés pour San Francisco et avons commencé à travailler dans les bureaux de Wired News (nous avions été rachetés par Condé Nast, une grande entreprise de publication qui possède Wired et de nombreux autres magazines).
J’étais malheureux. Je ne pouvais pas supporter San Francisco. Je ne pouvais pas supporter une vie de bureau. Je ne pouvais pas supporter Wired. J’ai pris de longues vacances de Noël. Je suis tombé malade. J’ai pensé à me suicider. J’ai fui la police. Et quand je suis revenu le lundi matin, on m’a demandé de démissionner.
Les quelques premiers jours sans travail ont été bizarres. Je tournais en rond chez moi. Je profitais du soleil de San Francisco. Je lisais quelques livres. Mais rapidement, j’ai senti que j’avais besoin, à nouveau, d’un projet. J’ai commencé à écrire un livre. Je désirais collecter toutes les bonnes études dans le domaine de la psychologie pour les raconter, non pas comme des analyses, mais comme des histoires. Chaque jour, je descendais à la bibliothèque de Stanford pour y faire des recherches. (Stanford est une école réputée en psychologie.)
Mais un jour, Brewster Kahle m’a appelé. Brewster est le fondateur de The Internet Archive, une organisation formidable qui essaye de numériser tout ce qu’elle trouve pour le publier sur le Web. Il m’a dit qu’il voulait démarrer un projet dont nous avions parlé à l’époque. L’idée serait de rassembler l’information de tous les livres du monde dans un lieu unique, un wiki libre. Je me suis mis immédiatement au travail, et dans les quelques mois qui ont suivi, j’ai commencé à contacter les bibliothèques, mettre à contribution des programmeurs, cogiter avec un designer et faire plein d’autres trucs pour mettre ce site en ligne. Ce projet a fini par devenir Open Library. Il a été développé en grande partie par un talentueux programmeur indien : Anand Chitipothu.
Un autre ami, Seth Roberts, a suggéré que nous devrions trouver le moyen de réformer le système des études supérieures. Nous n’arrivions pas à nous mettre d’accord sur une solution satisfaisante, mais nous avons eu une autre bonne idée : un wiki qui explique aux étudiants à quoi ressemblent les différents métiers. Ce site va être bientôt lancé…
Ensuite, un autre ancien ami, Simon Carstensen, m’a envoyé un e-mail disant qu’il avait obtenu son diplôme universitaire et qu’il cherchait à monter une entreprise avec moi. En fait, j’avais gardé une liste d’entreprises qui pourraient être d’excellentes idées et j’ai pris la première de la liste. L’idée était de créer un site Web aussi simple à remplir qu’un champ texte. Pendant les mois suivants, nous avons travaillé d’arrache-pied à rendre les choses de plus en plus simples (et un peu plus complexes aussi). Le résultat, avec le lancement il y a quelques semaines, est le site : Jottit.com.
Je me suis aussi engagé en tant que conseiller pour deux projets du Summer of Code, les deux étant étonnamment ambitieux et avec un peu de chances, ils devraient être lancés bientôt.
J’ai décidé également alors de m’impliquer dans le journalisme. Mon premier article papier vient d’être publié.
J’ai aussi lancé quelques blogs sur la science et j’ai commencé à travailler à rédiger un article académique moi-même. Il se base sur une étude que j’avais conduite il y a quelques temps sur les rédacteurs effectifs de Wikipédia. Quelques personnes, y compris Jimmy Wales, qui est en quelque sorte le porte-parole de Wikipédia, affirmait que Wikipédia n’était pas, tout compte fait, un projet massivement collaboratif, mais était plutôt rédigé par une équipe d’à peu près 500 auteurs, qu’il connaissait pour la plupart. Il avait fait quelques analyses simples pour le mettre en évidence, mais j’ai vérifié attentivement les chiffres et j’arrive à la conclusion inverse : la grande majorité de Wikipédia a été écrite par de nouveaux rédacteurs, la plupart ne s’étant pas donné la peine de créer un compte, ajoutant quelques phrases de ci de là. Comment Wales a-t-il pu commettre une telle erreur ? Il a analysé le nombre de modifications effectuées par chaque auteur sans vérifier la nature de ces modifications. Or la grande majorité de leurs modifications sont tout à fait mineures : ils font des choses comme des corrections orthographiques ou des remises en forme. Il semble plus raisonnable de croire que ces 500 personnes se comportent plus comme des inspecteurs que comme des producteurs de contenu.
Quel est le secret ? Comment pourrais-je condenser les choses que je fais dans des phrases concises qui me correspondent le plus ? Allons-y :
J’ai suivi cette ligne de conduite. Et voilà où j’en suis aujourd’hui, avec une douzaine de projets en tête et mon niveau de stress toujours au plus haut.
Chaque matin, je me lève et vérifie mes courriels pour savoir lequel de mes projets a implosé aujourd’hui, quelle date limite a été dépassée, quels discours je dois préparer et quels articles doivent être rédigés.
Un jour, peut-être, vous aussi serez dans la même situation. Si tel est le cas, j’espère que j’y aurai modestement contribué.
Crédit photo : Sage Ross (Creative Commons By-Sa)
