Journal FreshRSS, 3 ans de maturité (suite et fin)

Sommaire

• Synthèse des deux premières années
• La version 1.0
• Qu'est-ce qui ne marche pas ?
• La suite

Hello 'nal,

après un premier épisode qui posait l'intrigue principale et la suite qui venait confirmer la notoriété du projet, voici le dernier épisode qui vient conclure cette trilogie de journaux parce que oui, j'en ai gros.

Pour rappel, FreshRSS est un agrégateur et lecteur de flux RSS que vous pouvez héberger sur votre serveur si le PHP ne vous fait pas peur.

• Le site officiel
• Le blog
• Le compte Twitter
• La démo
• Le dépôt GitHub

Synthèse des deux premières années

FreshRSS fut avant tout un projet personnel que j'avais décidé de développer pour mes besoins personnels, n'étant pas satisfait des autres TinyTinyRSS (trop lourd), RSSLounge (trop bogué) ou Leed (trop pas pour moi). En me focalisant sur mes propres besoins et en le faisant du mieux que je le pouvais à la fois sur les plans « expérience utilisateur » et « interface utilisateur », un certain nombre de personnes m'a suivi dans le développement de ce projet. Alexandre et Alexis, les deux contributeurs les plus actifs ont permis de maintenir FreshRSS actif durant les périodes où je ne le pouvais / voulais pas.

C'est durant la deuxième année que j'ai vu ce travail porter ses fruits avec des mentions sur opensource.com et sur le compte Twitter de nixCraft (+47k followers aujourd'hui, ~34k à l'époque). Sans doute pas lié au hasard, c'est à cette période que le projet et la communication ont été les plus actifs. De nombreuses fonctionnalités ont aussi été ajoutées comme l'API compatible Google Reader, la gestion du multi-thèmes, des statistiques, le support de SQLite, le système de mises à jour automatique et j'en passe.

Tout allait donc pour le mieux jusqu'à…

La version 1.0

Sentant que je perdais l'enthousiasme des débuts et voulant sortir une version définitivement stable au plus vite, j'ai profité des premiers mois de mon année sabbatique pour aboutir à une version 1.0 fin janvier (contre fin décembre prévu initialement). Celle-ci n'apportait rien de fondamentalement nouveau hormis le support des extensions et – chose non négligeable – la satisfaction d'avoir réalisé un produit fini.

Ne voulant pas faire les choses n'importe comment, j'ai aussi réfléchi en parallèle à comment passer la main proprement sans laisser le projet mourir lentement comme d'autres avant lui. Voyant en FreshRSS un candidat idéal à la gestion communautaire, j'ai tenté de réfléchir aux outils idéaux qui m'aiderait à cette transition. J'en suis arrivé à l'organisation suivante :

• GitHub comme pivot pour la communauté : gestion du code, des tickets, « Pull Requests », gestion des versions (milestones), écriture de la doc et des articles de blog ;
• freshrss.org comme vitrine (site statique généré par Pelican) : présentation générale du projet, blog, documentation, liens vers chacun des outils ;
• mailing lists pour le support communautaire et les discussions générales entre développeurs ;
• compte Twitter pour la communication « extérieure ».

Qu'est-ce qui ne marche pas ?

Si je suis globalement satisfait de l'organisation actuelle, différents points me gênent encore :

• je suis le seul à avoir les clés de freshrss.org qui est hébergé sur mon serveur personnel. Le corollaire est que je suis le seul à pouvoir publier les nouveaux articles ainsi que la documentation ;
• les mailing lists, en théorie, ça marche. En pratique c'est plus compliqué : faut-il laisser les mailings ouvertes ? Quid alors du spam ? Que faire si une personne fait « Répondre » au lieu de « Répondre à tous » ? Comment gérer le suivi des questions ? Comment retrouver une question à laquelle personne n'a répondu ?
• il faut encore motiver les troupes (dont je fais partie) pour rédiger la documentation : code, documentation utilisateur, processus de sortie d'une nouvelle version, comment fonctionne les mises à jour automatiques… Ce sont des pans entiers importants qu'il faudrait documenter ;
• le code accuse des défauts de jeunesse (que ce soit celle du projet ou la mienne) : l'utilisation d'un framework fait maison, le mélange PHP / HTML dans les fichiers de vue, une architecture pas toujours optimale, etc. ;
• personne n'a de vision à long terme sur ce que doit être FreshRSS.

La suite

Je considère désormais que FreshRSS est « complet » dans le sens où il ne lui manque aucune fonctionnalité fondamentale. S'il est complet, ce n'est pas pour autant qu'il n'y a aucune piste d'améliorations (au contraire, il suffit de voir la liste des tickets ouverts sur GitHub) et l'idéal serait aujourd'hui de revoir en profondeur les choix de technos pour avoir quelque chose de plus propre (Minz pour le framework PHP, SimplePie pour la récupération des flux, JQuery pour le framework JavaScript, etc.) ainsi que l'architecture (séparation serveur / client). Ce n'est néanmoins pas quelque chose sur lequel je souhaite passer du temps personnellement.

Le but de ces prochains jours va être de mettre en place un VPS dédié à FreshRSS pour héberger les différentes choses qui le sont actuellement sur mon propre serveur et d'écrire la documentation pour les développeurs qui est prioritaire si l'on souhaite obtenir de l'aide. Tout cela est détaillé sur GitHub si vous êtes intéressés par les détails. En gros : il faut donner la main à d'autres contributeurs pour de bon.

Pour ma part, ensuite, je pourrai enfin dédier mon temps à un gros projet qui couve depuis juillet. Je vous donne donc rendez-vous l'année prochaine pour un journal qui devrait parler de tout autre chose :).