Le client API desktop Yaak passe en open source

• Il y a 3 mois, Yaak a publié un article intitulé "Why Not Open Source" expliquant pourquoi le projet ne devenait pas open source
• Ayant connu un burnout sur des projets open source par le passé, l’auteur a partagé sa réflexion en pensant que son processus de décision pourrait être utile à d’autres
• La plupart des utilisateurs de Yaak étaient d’accord, mais la communauté open source au sens large s’est fortement opposée à la majorité des arguments

Réaction de la communauté open source

• "Ne confondez pas l’open source / le logiciel libre avec un modèle social spécifique de GitHub ou avec la contribution" - lobste.rs

• "Mais tout cela s’applique aussi aux logiciels closed source" - ycombinator.com

• "Les arguments de cet article sont totalement absurdes. Je ne sais même pas ce qu’est cette ‘app’. On n’en a pas besoin. Direction la poubelle de l’histoire" - reddit.com

• La plupart des réponses n’étaient pas constructives, mais ce commentaire de 500 mots sur lobste.rs était vraiment excellent. En le lisant, l’auteur s’est dit qu’il avait peut-être tort

Les avantages de l’open source

• Open source ne signifie pas nécessairement contributions ouvertes
• Le simple fait de publier le code permet déjà d’obtenir la plupart des avantages :
  • ouvert aux audits de sécurité
  • transparence des fonctionnalités (rien de suspect)
  • flexibilité (possibilité de forker et de modifier)
  • le logiciel peut continuer à fonctionner même si le développeur s’en va

Passage à l’open source avec contributions limitées

• Il existe des projets comme SQLite qui sont open source mais n’acceptent pas de contributions externes
• Litestream n’acceptait pas les contributions au départ, puis a fini par n’autoriser que les corrections de bugs
• Yaak adopte lui aussi ce modèle : passage en open source sous licence MIT, avec uniquement les corrections de bugs acceptées en contribution

[rmekdma]

J’ai été impressionné de voir qu’il a lu de nombreux commentaires, en a extrait les éléments constructifs et les a pris en compte. C’est quelqu’un d’ouvert d’esprit.

[savvykang]

Les commentaires constructifs sont eux aussi excellents.

[xguru]

Voici un résumé d’un commentaire de 500 caractères sur lobster.rs inclus dans l’article.
Ce commentaire a été écrit à propos du billet original Why Not Open Source ?.

• Pour commencer par la conclusion : ne confondez pas « open source » / « logiciel libre » avec un modèle social spécifique à GitHub, celui des drive-by contributions, ni même avec les contributions en général
• Difficile d’être d’accord avec l’explication sur les raisons pour lesquelles l’open source ne fonctionnerait pas
• Beaucoup des points avancés relèvent de faux dilemmes. Par exemple : « ajouter des fonctionnalités est en pratique difficile, et il est souvent plus rapide que le mainteneur les implémente lui-même »
• En closed source, il faut toujours tout faire soi-même, mais en open source on peut aussi choisir de fonctionner ainsi. Il n’y a aucune obligation d’accepter les contributions des autres

Réfutation point par point

Possibilité d’ajouter des fonctionnalités - 🟥 En pratique, c’est difficile

• Il n’est pas nécessaire d’accepter tout ce que n’importe qui soumet pour être open source

Plus de transparence - 🟧 L’open source n’est pas nécessaire à la transparence. On peut aussi l’obtenir avec une roadmap publique, pas seulement avec le code

• Bonne remarque. Mais il ne s’agit pas d’avoir seulement du code : il s’agit aussi d’avoir le code. On peut avoir à la fois un code transparent et une roadmap transparente

La sécurité va s’améliorer - 🟧 Cela dépend des cas. Les utilisateurs peuvent auditer le code d’un projet open source et divulguer les problèmes

• Passer en open source ne détériore pas la situation. Même si l’amélioration n’est pas garantie, cela n’a au moins pas d’inconvénient

La communauté va grandir - 🟧 Cela n’est possible qu’en y investissant des efforts. Ce n’est pas propre à l’open source

• Là encore, cela ne nuit pas, mais l’auteur reconnaît aussi que ce point n’a pas un lien très fort

Réponse aux inconvénients

Difficile de gérer les retours impolis

• On reçoit aussi des retours en closed source. Dans un cas comme dans l’autre, rien n’oblige à les accepter

Difficile de gérer de longs cycles de feedback

• Il suffit de ne pas accepter les retours / soumissions de changements. Le cycle d’amélioration disparaît

Difficile de refuser des contributions soumises sans approbation

• Il suffit d’écrire dans le README que les contributions ne sont pas acceptées et de fermer automatiquement toutes les PR

Une fois le projet mature, il devient difficile de tout refuser

• Même en closed source, les utilisateurs continueront à faire des demandes

C’est difficile quand de bons contributeurs s’en vont

• Il suffit de ne pas accepter d’autres contributeurs. Aucune différence entre open source et closed source sur ce point

Difficile d’accepter le fait que des gens travaillent gratuitement

• Le logiciel libre ne signifie pas gratuit. Un logiciel libre commercial est aussi possible, et il n’est pas nécessaire d’accepter que d’autres travaillent sans être payés

Ce n’est pas bon d’avoir plus de 1 000 issues non résolues

• Il suffit de les fermer automatiquement

Le fait que cela n’ait pas de fin est difficile

• Avoir des utilisateurs / clients en closed source, c’est pareil