Il y a environ six mois, j’ai écrit un article sur l’état de la commercialisation de l’open source qui a attiré l’attention. Presque immédiatement après cela, Hacker News a présenté un morceau de prose problématique en première page. Le titre est « Fix it, Fork it, Fuck off » (la censure est à moi). Je pense que c’est un excellent exemple de là où l’OSS échoue commercialement et en tant que mouvement. Une grande partie de l’attention dans l’OSS va dans les politiques de code de conduite (qui sont importantes), mais pas assez dans ce qu’il faut pour construire un projet open source réussi. Ce n’est pas seulement le codage. Je dirais que le codage est souvent moins important que cela.
Le choc des droits
Je comprends d’où vient l’auteur. Il écrit par frustration. Nous mettons beaucoup de travail dans notre projet OSS, et un utilisateur final autorisé peut être difficile. Je suis d’accord que certaines personnes dépassent les bornes, mais d’après mon expérience, cela représente moins de 0,1 % des plaintes. Il est rare d’avoir un utilisateur vraiment toxique.
C’est le problème fondamental que j’ai avec ce poste; il lance la tâche aux utilisateurs. « Réparez-le vous-même. » C’est le mainteneur qui a droit. Ne vous méprenez pas; c’est OK pour faire un vidage de code. Mais alors déclarez-le comme tel et laissez-le aller. Être mainteneur est quelque chose de complètement différent.
Je soutiendrai et aiderai les utilisateurs qui veulent le réparer eux-mêmes, mais je reçois les gens qui ne veulent pas le faire. Je pense toujours qu’ils ont le droit de se plaindre comme s’ils avaient payé le logiciel. Oui, c’est frustrant d’entendre des plaintes. Mais je n’ai pas commencé un projet open-source juste pour qu’on me dise à quel point je suis génial. Je veux que les utilisateurs se sentent suffisamment à l’aise pour se défouler ; cela m’aide à comprendre les points douloureux. Cela aide à l’authenticité de la communauté, et sa capacité à me critiquer aide tout le monde, surtout moi. Cela attire l’attention d’autres membres de la communauté qui pourraient avoir un problème similaire et pourraient être plus motivés pour le résoudre. Cela me rend plus conscient des problèmes et des points qui nécessitent une amélioration.
Un organisateur communautaire
Un mainteneur d’OSS est une sorte d’organisateur communautaire. Un peu politicien mélangé à un chef de projet et à un dictateur bienveillant tout en un. Les bons managers et leaders sont généralement des personnes assez sympathiques et empathiques, la plupart du temps. Les gens mentionnent parfois un manager ou un dirigeant d’OSS et mentionnent sa terrible personnalité. Ça n’a pas de sens. Ils tiraient souvent ces histoires de quelques incidents parmi des milliers. Un projet réussi commence avec un leader patient. Oui, ce leader peut avoir une mauvaise journée de temps en temps. Ou ils pourraient utiliser un langage qui n’est pas politiquement correct. Mais l’exception ne fait pas la règle, et un tel langage ne se traduit pas toujours par l’hostilité.
Le « mythe » d’un chef de génie fou n’est souvent que cela. Un mythe. Quand des gens comme ça réussissent, c’est généralement malgré ça, pas à cause de ça. Pourtant, certaines personnes choisissent de pousser ce récit, se cachant derrière une fausse « méritocratie » au lieu de prendre leurs responsabilités. Ne le prenez pas mal; Je ne pense pas que nous ayons besoin de marcher sur des œufs avec tout le monde. Je ne pense pas que cela aide, et je ne pense pas que cela résolve quoi que ce soit non plus.
Il n’y a rien de mal à pardonner à un mainteneur qui a eu une mauvaise journée ou qui a fait quelque chose de mal. Mais cela ne devrait probablement pas être «fêté». Pourquoi donc? Pourquoi devrais-je maintenir un projet open source pour lequel je ne serais peut-être pas payé et aider les utilisateurs ?
Pourquoi écrivons-nous du code open-source en premier lieu ? Nous aimons coder. Mais je pense que nous l’aimons encore plus lorsque les gens utilisent notre logiciel. J’aime aussi cuisiner, mais si les gens ne mangent pas ma nourriture, c’est pire que de la brûler sur la cuisinière. L’un de mes échecs en tant que mainteneur est que je m’appuie trop sur mon passé technocratique. J’apporte trop de soutien. Cela a souvent étouffé la communauté. Pourquoi répondre à une question sur le forum si Shai répond tout de suite ?
La solution était de ne pas submerger. Je réponds une fois par jour et pas plus vite. En conséquence, la communauté peut développer ses forces. C’était une version de la microgestion qui s’applique aux mainteneurs. C’est courant pour les tâches de codage où nous avons tendance à prendre trop de travail et à déléguer trop peu.
Pourquoi c’est important
La dernière fois que j’ai écrit sur le rachat de l’open source par les entreprises. Cela a de bons éléments, mais présente également de nombreux dangers. Nous avons besoin de la communauté pour conduire cela. Nous avons besoin de mainteneurs qui comprennent le travail et ne sont pas liés aux seigneurs de l’entreprise.
Le gros problème dans tout projet, open source ou autre, c’est que les gens s’en fichent. Nous avons tous besoin de susciter l’adhésion de la communauté. C’est comme ça qu’on construit un projet. Vous pourriez avoir de la chance si vous êtes au bon endroit au bon moment. Mais si vous soutenez votre communauté, vous pourriez réussir même si vous avez raté le coche.
Tout cela m’amène à la raison pour laquelle je me suis « soudainement » rappelé que j’avais ce message qui traînait dans mon carnet de commandes pendant six mois et qui accumulait la poussière.
Dois-je démarrer un nouveau projet OSS ?
J’ai envisagé un nouveau type de JVM AoT qui adopte une approche radicalement différente de ce que nous avons actuellement. C’est quelque chose que je veux construire, mais dois-je le construire en tant que projet OSS ou commencer en privé ?
J’aimerais lever des fonds pour cela, et la participation de la communauté aidera. Mais si je n’ai pas encore de projet OSS, l’incertitude de la traction à venir pourrait être un meilleur argument de vente pour les investisseurs que la réalité de la traction actuellement limitée. De par sa nature, un projet JVM prendra du temps pour porter ses fruits et apporter de la valeur aux clients ; cela n’apportera pas une communauté ou une traction dès le début. Ce n’est donc peut-être pas un projet idéal à construire à l’air libre. Je ne suis pas non plus fan du codage avec des gens qui regardent par-dessus mon épaule. Je me sens gêné car il y a des attentes concernant mes compétences en codage.
Je veux à 100% construire à l’air libre, mais je ne peux le faire que si j’ai quelque chose en cours d’exécution qui montre la valeur du travail que je fais. Cela prendra un certain temps. C’est très subjectif. Certains projets ont plus de sens en tant qu’open-source dès le départ.
Avons-nous besoin de ce nouveau projet ?
Je parlais à un ami il y a quelque temps et discutais de mon idée quand il m’a défié sur la nécessité d’une autre JVM. Avez-vous réalisé une étude de marché ? Quelle est la viabilité de construire quelque chose comme ça?
Je ne veux pas en arriver au point où j’investis autant de temps et d’âme dans un produit qui se retrouve dans une petite niche. Il y a l’adage : « Si j’avais demandé aux gens ce qu’ils voulaient, ils auraient dit des chevaux plus rapides. C’est attribué à Henry Ford, qui, autant que je sache, n’a jamais dit cela. Je ne pense pas que cela aurait été vrai non plus. Nous devons être orientés produit même lors de la construction d’un projet open source.
Nous devons penser à la valeur client, à la volonté de s’adapter et à la pénétration du marché alors même que nous construisons quelque chose de gratuit et open source. Avant de lancer LWUIT chez Sun Microsystems, nous avons passé énormément de temps avec les utilisateurs cibles potentiels. Nous avons mené des entretiens et des réunions et aidé à l’intégration. Les retours que nous avons eus étaient formidables.
Puisque Codename One est issu des mêmes racines, il a bénéficié de ces racines. Pourtant, nous avons travaillé avec des sociétés d’accélérateurs pour voir comment elles travaillaient en étroite collaboration. Nous avons également eu une longue bêta précoce. C’est quelque chose d’assez important pour la traction initiale du projet. Lorsque LWUIT a été annoncé, nous avons pu ravir les premiers utilisateurs avec un produit plus adapté aux besoins des clients. Cela a beaucoup aidé avec les premiers utilisateurs et les premiers clients que nous avons eu pour Codename One.
Enfin
Lorsque nous construisons un projet open-source, nous finissons souvent par tout faire. Produit, DevOps, expérience utilisateur/développeur, etc. Il s’agit d’une expérience unique que la plupart des entreprises ne vous offriront pas. Je sais que mon expérience dans ces autres disciplines a fait de moi un meilleur gestionnaire et entrepreneur à long terme.
C’est un travail. Ça ne paie pas (du moins au début), et les heures sont toujours des heures supplémentaires, mais ça reste un boulot. Parce que; sinon, vous demandez aux autres développeurs de faire confiance à votre passe-temps. C’est injuste pour eux. Même lorsqu’il est gratuit, nous devons prendre le projet au sérieux et respecter nos utilisateurs.
Les mainteneurs reçoivent beaucoup en retour. Nous améliorons nos compétences. Les gens sont plus susceptibles d’utiliser et de défendre notre travail, et il est plus probable qu’il aboutisse à une entreprise rentable. Se retrouver avec un travail open-source de notre projet de passe-temps est un très bon résultat pour de nombreux projets parallèles. Cela commence par être raisonnablement patient avec les gens.