Je vais te raconter l’histoire qui arrive à ceux qui font quelque chose d’énorme : un projet open-source qui a du succès.
Au début, tout a commencé par une idée que tu as eu un matin. Tu commences à coder quelques lignes dans un coin, puis ensuite tu en parles avec un collègue ou un ami. En quelques jours, tu as l’impression que ton idée pourrait intéresser d’autres développeurs. Tu commences par trouver un nom sympa, voire même un logo. Ton code est un peu brouillon alors tu passes de longues heures à le nettoyer et à le tester. A un moment donné, il est tellement beau que tu décides que c’est le bon moment pour le partager sur Github.
Après avoir créé ton repository, c’est lorsque tu sauvegardes pour la première fois le fichier README.md, que tu sais que tout va changer. C’est parti : tu viens de lancer ton premier projet open source. Tu tentes une nouvelle sur HackerNews. Les visiteurs montrent un certain intérêt. Ta nouvelle monte dans le classement hacker-news. Ton projet est alors poussé au premier plan. En quelques jours, plusieurs milliers de développeurs téléchargent ton projet. Tu vois qu’il y a déjà 2 ou 3 personnes qui te proposent des Pull-Requests. Au début, c’est difficile de refuser, et tu acceptes un peu prêt toutes les demandes. Et puis tu veux absolument avancer rapidement, et tu te retrouves à travailler 12 heures par jour sur ton projet.
Tu crées une liste sur Google Groups. D’un email ou deux au début, c’est rapidement plus de 30 emails par jour. Au départ, tu es seul. Tu mets un point d’honneur à répondre à TOUS les emails que tu reçois. Les premiers participants sont plutôt éduqués et habitués aux projets en démarrage. Tout le monde est sympa, l’ambiance est cordiale, et les questions sont plutôt pointues. Ca, c’est parce que tu n’es qu’au début de ton projet.
Ensuite un ami te refait un vrai site web digne de cela. Tu as maintenant un beau logo, une belle documentation avec un tutorial. Tu as aussi créé un compte sur Twitter. Coté code, tu t’arraches chaque jour difficilement du clavier. C’est génial, tu sens que tu vis quelque chose d’énorme.
Tu as chaque matin de belles surprises. Par exemple ce contributeur qui a traduit en japonais ton tutorial. Tu lis aussi de bons articles sur les blogs. Les gens commencent à parler de toi. Tu reçois des emails sérieux de recruteurs. Et des emails bizarres de gens bizarres. Mais bon, c’est la rançon de la gloire non ?
Le point de basculement
Arrive un jour un premier article négatif sur un blog. Un développeur a écrit un article assez critique sur ton projet. Cela t’affecte, car lorsqu’il critique ton projet, il te critique indirectement. Tu es vraiment très affecté et très triste. Tu ne sais pas comment répondre. Sur la liste de diffusions, les gens s’enflamment. Certains sont plus engagés que toi et seraient prêt à en découdre pour défendre ton projet. Là tu regrettes d’être un peu trop seul et de ne pas avoir partagé la gouvernance.
C’est dingue. Ton projet est devenu un parti politique ou un groupe de musique. Les fans ne sont pas forcément objectifs. Tu le sais bien, toi, qui commence à douter de certaines parties de ton projet. Mais eux, ils sont fous. Tu apprends un jour qu’un gars fait la tournée des JUG en présentant ton projet. Tu reçois un matin un communiqué de Presse car un livre va sortir sur ton projet. C’est dingue mais tu sais que cela va s’arrêter.
Entre temps, tu décides de refondre une partie du projet. La liste de diffusion s’emballe. Il y a ceux qui sont pour, et ceux qui sont contre. Et il y a aussi tous les débutants qui posent des questions débiles, qui polluent la liste de diffusion, et que tu rêves de décapiter. Tu as perdu tous tes cheveux et tu as pris 10 kilos. Tu aimerais bien trouver un autre contributeur pour qu’il prenne la suite, mais à avoir trop verrouillé ton projet, cela semble impossible.
Tu fais la tournée des groupes d’utilisateurs, des conférences et de tout ce qui te permet de boire une bière en racontant à chaque fois la même histoire. Au début tu étais intimidé, mais aujourd’hui tu es complètement défoncé. Avec 5 heures de sommeil, le stress de ne pas arriver à suivre les bugs et les demandes de changement ou l’intégration et la sortie de la prochaine version, franchement tu fais peur à voir.
Et puis ton projet commence à te lasser. Tout d’abord tu vois bien qu’il n’a plus la même justification qu’il y a 2 ans. Aujourd’hui tous les navigateurs supportent l’injection d’Haskell en triphasé, surtout lorsque tu essayes de l’accoupler avec du JS. Et ça, toi tu le sais très bien. Mais bon, on t’a encore demandé de faire une formation et de participer à un enregistrement télé à San Francisco, alors tu vas pas encore continuer un peu non ? Et puis ton nouvel employeur qui t’a embauché en disant « … votre projet est génial … » aurait du mal à comprendre que tu laisses tomber non ?
Et puis surtout, tu te dis que lorsque cela va s’arrêter, tu ne sauras pas quoi faire. Tu n’as pas d’idées de Projet2. Imagine, tu viens d’inventer Twitter Bootstrap. Les gens sont content et s’en servent… que veux-tu faire ensuite après cela ?
Alors tu continues. Limite, tu simules.
Jusqu’au jour où cela s’arrêtera, les gens arrêteront d’envoyer des emails sur la liste. Plus personne ne téléchargera ta nouvelle-nouvelle version. Tu devras gérer toutes les personnes furieuses. En fait, tu n’entendras plus que les râleurs. Les gentils early-adopteurs sont déjà partis sur un autre projet. Ton projet est devenu un énorme machin, patché dans tous les sens. Une espèce de poupée gonflable sur laquelle une équipe de Rugby serait passé. Oh tu as beau tenter de continuer, de toutes les façons tu n’y crois plus.
Voilà ça s’arrête comme ça.
La fin est triste
Non, pas de happy end. Tu as merdé en fait. Tu as oublié qu’un projet open-source cela doit rapidement être le projet de plusieurs personnes. Dans toutes les aventures, il y a un début, une apogée et une fin. Dans notre industrie de princesse, il faut vivre sur plusieurs branches. C’est aussi une grosse erreur que de n’avoir pas préparé un « après ». A moins d’être l’auteur d’un langage, de quelque chose qui ne change pas tous les 3 ans, il faut vraiment prendre conscience que la durée de vie de ton projet est limitée. A consommer avant le 31/12/2014, sinon il sera tout pourri.
Ensuite en 2012 il y a quelque chose de très populaire qui a changé la donne : c’est GitHub. J’imagine que nous sommes en 2025. Vous lisez cet article sur un iPad mini-mini sur vos iToilettes comme chaque matin. Bon alors je vous explique : Github à notre époque c’est un système de partage de code et un réseau social pour les projets open-sources. Sur Facebook je pouvais m’abonner et suivre mes amis. Sur Github je peux suivre les projets. Et ça, ça a changé beaucoup de choses. Un projet populaire peut rapidement se faire déborder par une communauté enthousiaste.
Ensuite il y a les réseaux sociaux, et particulièrement Twitter. Cela peut vous prendre plusieurs heures chaque jour. A la limite il était facile de faire un projet open-source il y a 10 ans. Aujourd’hui en 2012, si vous vous lancez dans l’aventure et que ça marche, mon dieu, vous allez prendre 10 kg et perdre vos cheveux.
Attention, cela reste génial. Mais j’ai eu envie d’écrire cet article en voyant Jacob Thornton à la conférence dot.JS (@fat sur twitter). Certains ont détesté sa présentation. Moi j’ai adoré. Il est arrivé sur scène, certains ont pensé qu’il avait sniffé des macarons pendant la pause, bref, ce gars est cramé. Il a fait MooTools, co-créé Twitter Bootstrap et d’autres projets de malade. Il a bossé 2 ans 1/2 chez Twitter et il vient de passer chez Obvious (cofondé par Biz Stone et Evan Williams, eux-même fondateur de Twitter). Je l’admire et c’est la première fois que j’entends un développeur nous avouer simplement qu’un projet lui a bouffé la vie. Si vous voulez vous en convaincre, écoutez-le dans une interview à OSCON 2012. En psychologie on parle de Burnout. Cela peut nous arriver lorsque l’on est devenu complètement engagé dans un projet.
Bref votre projet open-source n’a qu’une durée de vie limitée. Profitez de la vie, ne faîtes pas que cela, demandez ce qu’en pense vos amis.
C’est tout.
0 no like
Excellent article
Humm, quelqu’un m’avait suggérer bootstrap sur un autre post(de js) pour m’aider à faire du design. Ici je lis que le projet est dépasser.
Qu’est-ce qu’il y a de nouveau qui aide à faire un beau design ?
Merci pour ce billet, interessant et tres bien ecrit !
Simon.
Ca c’est un article tourné vers l’avenir, en effet, bootstrap n’est pas mort du tout, mais ça va ouvrir des portes à d’autres projets.
Maintenant tout va très vite, certains n’ont pas eu besoin de se faire la main avec les nouveaux langages IOS et Android, qu’ils n’ont plus besoin de le faire avec PhoneGap et Appccelerator
Apparemment GitHub aurait défoncé de toute évidence tous les autres sites d’OpenSource, mais c’est évolution qui veut ça, et plus tard il y aura un remplaçant de GitHub
Excellent article que je diffuserait largement sur twitter.
Un projet opensource, c’est un « bébé » qu’on met au monde.
Il est très dur de s’en séparer mais il le faut 🙂
Magnifique. Merci.
Un projet opensource, c’est un « bébé » qu’on met au monde.
http://25.media.tumblr.com/tumblr_me9izrcMfd1rt7j2bo1_500.jpg
Un excellent article qui n’est pas sans me rappeler celui là :
L’un de mes bébés a quitté la maison !
Un article où l’auteur d’un outil Open Source de test pour PHP, explique qu’il a laissé son « bébé » aux mains de la communauté afin qu’il puisse évoluer dans les meilleurs conditions.
Moi aussi j’ai beaucoup aimé l’intervention de @fat à dotJs. Il avait vraiment pas l’air bien et c’était touchant. Bel article !
Très bon article !
J’ai adoré du début à la fin !
Excellent article, ce genre de problème psy n’est pas forcement reserve aux projets open source, mais a tout les projets qui tiennent a coeur! Dans l’entreprise, ou dans l’open source! Tu as bien resume! Prennez le temps de vivre!
Encore un article fort intéressant!
Personnellement je rêve de ce genre d’expérience.
Je suis sûr que même en sachant cela nous ferions la même chose car c’est cette envie de faire et de contribuer à de grands projets qui nous anime.
Le problème comme souvent c’est de s’y perdre, de s’oublier…
Superbe.
J’ai vu la conf j’ai adoré aussi. Avouer qu’un projet comme bootstrap l’a bouffé, faut oser.
Est-ce qu’une solution ce ne serait pas d’arreter le développement lorsque toutes les fonctionnalités importantes sont développées?
Bel article.
Obtenir de la visibilité sur un projet Open Source n’est pas simple. Être hosté par une boîte tech connue (twitter, google, facebook), être relayé par des gens ayant de la visibilité (=> avoir un bon réseau), ça joue beaucoup. Ensuite, il faut un beau site, une belle doc, etc. L’utilité du projet en elle même, la qualité du code… ça joue à la marge, du moins au départ. Pour promouvoir son projet, il faut : 1) y consacrer beaucoup de temps, dans la durée et surtout 2) prendre son bâton de pèlerin et aller en parler à des confs, tout le temps, partout.
« Tu as merdé en fait. Tu as oublié qu’un projet open-source cela doit rapidement être le projet de plusieurs personnes. »
Ça a l’air simple comme ça, mais même quand un projet a un peu de visibilité, il est TRES difficile de faire monter du monde à bord. GitHub est génial car il diminue le coût d’entrée sur un projet. Mais il incite aussi à papillonner, à contribuer à droite à gauche. Plus besoin de s’investir, de s’engager pour longtemps. Et un projet Open Source, ce n’est pas juste une agrégation de mini pull requests.
Bon, je vais parler de moi… à mon échelle, je vis ça avec AndroidAnnotations (http://androidannotations.org). Ça me prends un temps monstre. J’ai plein d’idées de projets à démarrer, d’articles à écrire, mais quand tu as des issues ouvertes, des questions sur la ML et SO, des pull requests à vérifier… En 2 ans, on a eu 13 contributeurs, mais en réalité on est 3 / 4 à bien connaître la base de code. Je suis heureux de voir des gens répondre sur la mailing list, sur les issues. J’adorerai « partager » la paternité de ce projet et ne pas en être le « dictateur bénévole », mais je ne sais pas comment faire.
Une pull request, ça a l’air cool comme ça. En réalité, c’est un boulot monstre. On perds beaucoup moins de temps à coder la feature soi même. Je considère la revue de pull requests comme un investissement en « formation de la communauté », en espérant des retombées en terme d’investissement dans la communauté.
Si quelqu’un a la recette magique sur comment créer un projet Open Source, lui faire prendre son envol et s’en détacher, je suis preneur.
C’est vrai que l’industrie informatique devient un peu folle, on verra ce qu’il en sera dit dans 10 ans. Quand on voit par exemple qu’un développeur Java qui passe au Scala avec une touche de JS/Backbone, se met à dessiner une tasse de café sur une étiquette arc-en-ciel, c’est le moment où l’on s’en rend le plus compte :-> C’est bien fait en plus, bizarre mais propre !
En tous cas je suis assez triste de l’apprendre, il a fait du bon taf ce mec.
Il y a des points très solides dans cet article, et en effet un projet OSS peut devenir tentaculaire.
Il faut néanmoins remettre les choses en perspective : un projet comme Bootstrap est une exception, pas la règle. Une sorte d’explosion soudaine de notoriété comme dans une émission de télé-réalité. Un projet OSS c’est plus souvent un long travail de fond solitaire, pour peut-être une reconnaissance au bout de quelques années.
Savoir intégrer des contributeurs clé de la communauté et leur conférer graduellement du poids est en effet essentiel, mais aussi délicat. Face à un fourmillement d’idées il y a un réel péril à ce que le projet dérive vers un foutoir sans fin, un produit peu cohérent. Un bon projet reste un projet focalisé, et savoir dire non est un réflexe essentiel. Forcément cela crée des tensions avec le reste de la « communauté », mais c’est un mal nécessaire. Relire justement « Getting Real » ou « Rework » à ce sujet (« opiniated product vs half-assed product »).
Faire un projet il y a 10 ans n’était pas spécialement plus facile. Par expérience des outils comme GitHub sont au contraire des facilitateurs. Poser un projet sur GitHub est facile. Accepter / reviewer des pull requests est facile. Se farcir un projet sur Sourceforge, prendre des diffs attachés dans un bug tracker, beaucoup moins. L’outillage actuel n’est pas vraiment le facteur qui mets de l’huile sur le feu, et j’aurais plutôt tendance à dire qu’il réduit les frictions pour essayer de garder un peu la tête hors de l’eau si la machine du succès s’emballe.
En tous cas c’est intéressant de voir un retour de quelqu’un qui admet un burnout, s’être fait dépassé par l’emballement autour de son projet. Comme le disent certains ici c’est le même phénomène sur à peu près n’importe quel projet perso ou pro. Il faut poser des limites, savoir dire stop quand la passion s’éffrite … mais c’est si grisant 🙂
Parole de quelqu’un qui a conduit un projet OSS pendant plus de 10 ans : allez-y, vous ne regretterez pas grand chose, et si jamais votre projet marche, gardez la tête froide, le meilleur moyen restant d’avoir un entourage solide !
@iamwarry : je remplacerai Backbone par AngularJS 🙂 Pour info, je suis aussi passé par les Gobelins, d’où une petite maîtrise de Photoshop/Illustrator (mais modeste).
Excellent article (en plus quand on a été à la conf c’est complémentaire)
Je suis super intéressé par tes retours sur tes pbs avec Backbone et si Angular règle ces problèmes
Excellent Article.
A mon sens, beaucoup de projet OpenSource qui marchent n’ont souvent que quelques personnes ou une entreprise derrière pour faire avancer le truc. Le pure projet à 1000 développeurs impliqués j’y crois peu 🙂
Bootstrap est dans la continuité logique de BluePrintCSS (et des autres). Mais l’on observe un shift entre 2 mondes:
– Les informaticien qui veulent faire du web: GWT, BackBone, AngularJS, … du beau MVC
– Les webdesigner qui veulent normaliser/structurer le front: Bootstrap, Compass, etc, …
Très bon article, j’ai pris plaisir à le lire, il décrit bien la vie d’un projet open source et les étapes que traverse son auteur.
Excellent article en effet qui décrit ce qu’il peut arriver si on ne prépare pas l’avenir. Cependant si le code lui-même à une durée limitée, une équipe peut en avoir une plus longue au delà du code spécifique initial.
L’informatique est un métier en innovation constante et chaque année une nouvelle vague de projets va emporter d’anciens projets qui vont disparaître ou perdre en interêt.
Pour autant, à travers un projet, on peut construire une équipe et cette équipe sera capable de préparer l’avenir et de faire évoluer le code, mais il faut le prévoir très vite.
Le plus important cependant est que les créateurs de projets ont eu une contribution non négligeable à la communauté. Les idées de ce projet auront été repris dans un autre projet et ainsi de suite.
Le tout est soit de ne pas s’attacher à son propre projet, soit faire en sorte que le projet se succède à lui même le plus longtemps possible, et cela en effet passe par une communauté la plus large possible.
Ludovic
Fondateur de XWiki
Excellent article comme d’habitude.
Une autre possibilité, si on souhaite vraiment s’investir dans de l’open source sans se faire bouffer tout son temps est de faire en sorte de se faire embaucher à temps plein par une entreprise qui vous payera pour travailler sur un projet open source.
@Jack qui s’inquiète du fait que bootstrap soit « dépassé » :
Un design ça s’étudie à la rigueur en utilisant un framework css léger comme knacss de Raphaël Goetter mais partir sur Bootstrap est une decision lourde qui va impacter l’intégration du projet car alors il faudra se traîner Bootstrap et ce n’est pas au designer d’imposer un framework à l’intégrateur.
Demandez vous d’abord quelles seront les conséquence d’un tel choix avant de vous demander si le style de Bootstrap est « dépassé » ou non, ce qui est une affirmation qui reste à argumenter AMHA.
Je reviens sur un de mes tweets un peu brutal. 140 caractères, c’est un peu court pour exprimer une pensée constructive. Et je ne suis pas connu pour être toujours constructif 😉
Bref, j’ai tweeté que « c’est ceux qui n’ont jamais fait d’open source sont ceux qui en parlent le mieux », parce que ça m’a rappelé la pub des années 80 pour un parfum ( http://www.mes-parfums.com/en/publicite/-Inconnu/87/Darling ).
Et ce rapprochement m’a fait marrer 🙂 Parce que, au final, on peut adorer l’Open Source, difuser la bon e parole, sans jamais avoir participé à un projet.
Bon, bref, revenons à l’article. Je pense que ce qui est décrit est une rareté, et ne représente absolument pas la vaste majorité des projets open source. Qu’un gars ait fait un burnout dans ce cadre, pourquoi pas. Mais il aurait tout aussi bien pû se ‘brûler’ dans un autre contexte.
Je ne suis pas sûr que GitHub – ou d’ailleurs quelque outil que ce soit – soit à l’origine des problèmes rencontrés par le gars en question.
La conclusion est parfaitement vraie : on n’a qu’une vie, et ce n’est pas celle qui consiste à rester devant son écran.
Mais, non, bosser sur un projet OSS qui marche ne conduit pas à prendre 10kg ni à perdre ses cheveux : seus les autistes ou les cinglés sans recul arrivent à ce résultat. Bizarrement, j’ai beau creuser, je ne vois qu’une seule personne qui pourrait se rapprocher de cette description.
Dernier point : un projet OSS n’est rien sans communauté (je pense que c’est l’objet du post, et c’est bien souligné). Le style BDFL n’est qu’une illusion qui ne résiste pas au Bus Factor.
Excellent article, j’ai adoré.
Article très intéressant !
Je vous recommande celui-ci écrit par Jason de 37Singals 🙂
http://www.goodreads.com/author_blog_posts/3354200-open-source-guilt-passion
Juste énorme 🙂
Un grand merci pour cet article qui fait réfléchir sur l’approche du développement open source…
J’ai regretté de ne pas être à la conf @dotJS mais j’aurais beaucoup aimé voir @fat faire sa présentation (les slides détachées du présentateur ont un petit gout qui manque).
Mais est-ce que c’est vraiment possible de démarrer un projet dans son garage avec une très bonne idée et de le passer à plusieurs ensuite? Avec les outils actuels est-ce que tout ne va pas trop vite pour permettre une mise en place stable?
Merci pour cet article 🙂
Excellent article.
Il rappelle un point important qui est qu’un projet OpenSource, c’est avant tout une communauté.
Il y a une multitudes de projets Canada Dry OpenSource.
Ils en ont la couleur et le gout mais ne le sont pas, tenus qu’ils sont par une personne ou une entreprise. Les contributeurs externes sont parfois tolérés mais les décisions sont prises en interne et sans que les utilisateurs aient leur mot à dire.
Ces projets finissent invariablement par mourir car la gouvernance n’est pas partagée alors que c’est la finalité même d’un projet OSS.
Un conseil, fuyez ce genre de projet, il y a une multitude de projets ouverts qui accepteront votre aide et vos idées.
Bonne fin du monde à tous