this post was submitted on 13 Sep 2023
24 points (100.0% liked)
[🔒] AskFrance
361 readers
1 users here now
Migration le 19/09 vers !forumlibre@jlai.lu, voir fil épinglé: https://jlai.lu/post/856448
Le contenu en français est privilégié, mais nous acceptons aussi les messages en anglais.
We attempt to keep the community in French, but English posts are also accepted.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Pour participer un peu au projet et administrer jlai.lu, le problème principal, c'est la gestion du projet et ça rend tout extrêmement difficile en tant que contributeur.
Par exemple, y a eu des choix conceptuels de faits qui sont plus que douteux et qui méritent d'être refondus, notamment tout ce qui touche à l'authentification et la gestion de session. Ça a déjà posé problème, et ça reposera problème, d'où l'importance du sujet.
Le problème c'est que cette réécriture est en cours depuis bien 3 mois, et vu qu'il n'y a ni roadmap ni gestion centrale du projet, c'est impossible de savoir ce qui marche, marche pas, les features qui sont là et que ça risque de casser ou pas, ce que ça va casser pour les clients, etc. du coup ça avance pas, les gens en ont marre et abandonne le truc parce que le temps disponible est pas non plus infini.
Imagine ça sur 200 features différentes.
Tout le monde fait ses merge requests à l'arrache (moi le premier), les reviews se font à l'arrache aussi parce que y en a trop et dans un laps de temps entre 1h et un mois, les tests automatisés puent la mort et en fait testent pas grand chose, du coup on se retrouve avec des releases complètement instables en plus d'en chier pour contribuer.
Si toute l'organisation roulait, les barrières techniques comme le Rust par exemple seraient bien moins impactantes parce qu'il y aurait pas besoin de 200 personnes pour faire un truc qui est censé prendre une journée. Y'a aussi assez peu de communication entre les devs principaux et les contributeurs, notamment sur les différents espaces Matrix dédiés au projet, ce qui complique encore plus l'évolution du projet.
Autrement, le problème de Beehaw c'est qu'ils ont pris une plateforme fédérée alors qu'ils veulent pas fédérer. Leur choix technologique est mauvais par rapport à leur besoin et ça c'est pas vraiment la faute de Lemmy.
Retour super intéressant, merci!
Ton message fait presque penser qu'il faudrait qu'une équipe de dev open source chevronnés (parce que même si j'apprécie beaucoup Lemmy, j'ai l'impression que les deux devs sont clairement victimes de leur succès) qui se lancent dans une alternative à Lemmy (parce qu'un fork, au final, ça reprendrait toute la dette technique), compatible avec Lemmy/Kbin via ActivityPub.
Intéressant ton point de vue de contributeur sur le projet. Je n’ai pas contribué à Lemmy, mais j’ai un peu contribué sur d’autres projets Open Source, notamment en Rust d’ailleurs. C’est toujours compliqué la gestion de ce type de projet. S’il commence à y avoir pas mal de contributeurs, c’est nécessairement un job à temps plein que de trier les issues, review les PR, assurer une certaine cohérence et une roadmap, entre les ré-écritures de fond et nouvelles features qui arrivent… et sans société derrière, sans qu’il y ait des gens payés pour le faire, c’est toujours délicat. Sur les projets OSS sur lesquels j’ai un peu bossé, il y avait toujours des boites derrières et l’orga des projets étaient plutôt carrée (des trucs liés aux technos blockchain, client Ethereum avec Parity derrière, ou Lighthouse avec SigmaPrime, …). Le choix de Rust semble être une bonne chose alors, au moins le typage statique et la compilation réduisent un peu le cataclysme que serait un projet sans lead technologique fort dans un langage plus permissifs comme le Node (ouais c’est surtout pour le troll 😉).
Et tout à fait de ton avis sur Beehaw.
Les deux devs principaux de Lemmy reçoivent des subsides de la Nlnet foundation (https://nlnet.nl/project/Lemmy/), après effectivement ils n'ont sans doute pas l'habitude de gérer autant de PR ni de discussions architecturales