Blogging in 2013

Est-ce que ça vaut encore le coup de coder un logiciel de blogging en 2013 ?

Je me pose la question depuis quatre ans chaque fois que je code sur Publify. Cela fait bien longtemps que Wordpress a phagocyté le marché des outils de publication open source, des utilisateurs aux contributeurs disponibles, au point d’occuper aujourd’hui la part de marché hallucinante de 19.3% des sites Web dans le monde. Le blogging est considéré comme mort et enterré depuis que le micro blogging a bouleversé nos habitudes d’écriture, érodant nos capacités d’attention à 140 caractères, et la pertinence de n’importe quel événement à quelques heures. Quant aux Tumblr like et autres silos, ils ont pris l’espace laissé par ceux dont l’activité principale était de relayer les contenus publiés par d’autres.

Il y a 8 ans, pratiquement toutes les introductions aux langages et frameworks orientés Web comprenaient l’écriture d’un outil de blog. Le screencast qui lança la légende de Ruby On Rails se basait sur l’idée que l’on pouvait avoir un blog fonctionnel en moins de 10 minutes. C’était bien évidemment un mensonge, mais cela marchait.

J’ai moi-même codé mon premier blogware en 2002 avant de passer sur un Wordpress encore balbutiant en 2003. Ma lune de miel avec l’outil de publication le plus connu de l’Histoire du Web dura trois ans, avant que je ne reprenne Typo Publify, un outil en Ruby On Rails que je maintiens encore aujourd’hui.

Travailler sur Publify m’a beaucoup appris.

J’ai appris à suivre un projet année après année avec une équipe changeant, tout en gérant une gigantesque dette technique et un code tellement ancien que j’ai plus d’une fois eu envie de tout recommencer.

J’ai appris toutes les erreurs à ne pas connaître quand on gère le développement d’un produit, la première étant de ne pas copier son principal concurrent quand quand on joue pas dans la même cour et que l’on ne cible pas le même marché. À eu époque, nous avons voulu faire de Publify un outil grand public alors que nos utilisateurs étaient en très grande majorité des développeurs et des administrateurs systèmes. Le résultat : des fonctionnalités que personne n’utilisait, mal finies et mal maintenues.

J’ai appris que gérer un projet open source demandait de grandes qualité de management. Travailler avec des gens qui vous consacrent gratuitement une partie de leur temps libre demande une attention plus importante encore que celle que vous portez à vos employés, sous peine de les voir perdre leur motivation. C’est encore plus vrai avec ceux qui s’occupent d’éléments “secondaires”, comme les traductions, le pakagig, ou les annexes comme maintenir les catalogues de thèmes ou de plugins.

Les années passant, j’ai lentement mais sûrement perdu ma motivation. Coder un blogware ne m’intéressait plus ; les sorties se faisaient de plus en plus rares, et les tickets pouvaient rester des semaines sans réponse. Je ne contribuais plus que pour ajouter une fonctionnalité dont j’avais besoin, ou corriger un bug qui me gênait. En fin de compte, les deux raisons qui m’avaient poussé à reprendre le projet.

Mais, pour être honnête, entre l’absence de nouvelles fonctionnalités majeures, et des concurrents de plus en plus nombreux, j’avais fini par ramener Publify dans la situation dans laquelle il était le jour où je l’ai repris.

Pendant près d’un an, j’ai songé à changer d’outil de publication. Les outils de génération de contenu statique comme Jekyll ont le vent en poupe et une communauté assez active à laquelle j’aurais pu me greffer le cas échéant. J’ai même songé à repasser sous Wordpress, mais l’idée d’installer PHP sur une de mes machines suffisait à me donner de l’urticaire.

Jusqu’au au live tweet de Tantek à Indie Web Camp 2013, à l’occasion duquel la découverte de POSSE a ouvert de nouvelles perspectives aussi bien pour Publify que pour moi.

Ça fait longtemps que je m’intéresse à la vie privée, et à la manière dont sont gérées et exploitées mes données. J’ai publié mon premier site en 1995 ou 1996, et me suis impliqué dans l’auto hébergement aux alentours de 1998 ou 1999. Après mon déménagement à Paris à l’été 2001, j’ai eu jusqu’à 9 machines qui faisaient tourner divers services sous un certain nombre de versions d’UNIX sur une ligne ADSL Nerim (en IPv6). Ça a duré jusqu’à mon mariage, et au moment où ma femme a décrété que je devrais libérer le placard dans lequel trônaient mes machines, et en particuliers mon Ultra30 et ses disques SCSI beaucoup trop bruyants à son goût. J’ai alors déménagé ailleurs, sur une seule machine.

J’ai commencé à développer mon premier outil de blog le jour où j’ai commencé à bloguer. L’idée que quelqu’un d’autre puisse m’héberger m’était alors inconcevable. Puis de plus en plus de startups ont commencé à proposer des services hébergés, et j’ai commencé à leur faire confiance au point de leur confier mes données sans espoir de retour. Certaines d’entre-elles tournent toujours, mais la plupart d’entre elles ont disparu corps et données, sans réelles conséquences : j’hébergeais tout ce qui comptait chez moi.

Jusqu’au jour où Google a annoncé la fermeture de Reader le premier juillet 2013. Depuis la mort de Bloglines, Reader avait été le seul lecteur de flux qui vaille la peine d’être utilisé pour un utilisateur final, et bien que je n’utilise plus les RSS autant qu’autrefois, la fermeture du service avait été un choc. La mort de Force Jaune dans le dixième épisode de Bioman n’avait pas été plus traumatisante. J’avais perdu la foi en la capacité de Google à maintenir ses services les moins rentables bien que très utilisés, et ma confiance dans le modèle SAAS s’était évaporé bien que je travaille pour une entreprise qui propose ce genre de prestations.

POSSE était ce qu’il me fallait. Publish Own Site, Syndicate Elsewhere. Le POS était pour moi une seconde nature au point d’en faire mon métier, mais la partie Syndicate Elsewhere m’était jusque là étrangère. Au lieu de donner mes données à des silos, les utiliser afin de syndiquer mes propres données m’est devenu une évidence.

Dans une univers POSSE, je publie un status sur mon site avant de l’envoyer sur Twitter avec un lien vers le contenu original. J’ajoute une photo dans ma galerie avant de la publier sur Flickr, 500px ou Facebook, une fois encore avec le lien vers le contenu original, vers mon contenu.

J’ai passé la plus grande majorité de mes vacances d’été à réfléchir au POSSE. À tous point de vue, POSSE était le chainon manquant de ma présence en ligne, une solution partielle mais des plus acceptables à la schizophrénie qui me faisait gérer mes sites Web, mon email et même mon serveur Jabber d’un côté, et joyeusement donner mes données à des silos sur lesquels je n’avais aucun contrôle de l’autre côté.

L’implémentation était la partie la plus problématique. J’ai assez d’expérience dans le logiciel pour savoir combien il est difficile de créer un produit qui fasse une seule chose vraiment bien. Que dire alors d’une suite regroupant un outil de blogging, un client Twitter, une galerie photo hyper connectée… le tout en mode auto hébergé. Par le passé, j’utilisais une crontab et un fichier texte pour planifier mes tweets. C’était largement assez jusqu’à l’arrivée de Buffer. Fin de l’histoire.

J’ai lu du code PHP, Python et Ruby. J’ai lu plus de code que je n’en avais vu depuis des années. J’ai lu du code pendant la sieste des enfants et j’ai lu du code sur la plage. J’ai étudié les implémentations POSSE existantes pour trouver la meilleure marche à suivre. J’ai découvert pas mal de projets intéressants, mais aucun qui ait été construit dans le but d’être facilement repris ou intégré.

Je voulais commencer par publier des messages courts sur mon blog, avant de les envoyer sur Twitter avec un lien retour. J’avais besoin d’une UI Web utilisable sur téléphone mobile, puisque je ne pouvais pas utiliser d’interface en ligne de commande sur mon iPhone. Je ne voulais pas d’un outil en PHP – question de religion – et je ne voulais pas non-plus d’un projet éphémère qu’il me faudrait reprendre dans six mois faute de mainteneur.

J’avais pourtant une bonne base avec Publify, mais Publify est un outil de blogging sur le déclin et… mais atteds… les logiciels de blogging sont des outils de publication de contenus, n’est-ce pas ?

J’ai rapidement envoyé un message à mes co mainteneurs pour leur proposer de prendre la direction du POSSE, et ils m’ont suivi aussi bien pour des raisons philosophiques que pour sortir Publify de la catégorie des outils de blogging.

Publify est loin d’être le meilleur outil de blogging du marché. Pour être honnête, il est loin d’être terrible, parce qu’aucun de ses mainteneurs n’est assez orienté frontend pour prendre cette partie à bras le corps. Nous avons donc laissé les interactions Javascript de côté, et utilisons Bootstrap pour la CSS. En revanche, côté publication de contenu, il faut avouer qu’on se débrouille bien.

J’ai commencé à hacker Publify pendant la sieste des enfants, pour lui ajouter sa première fonctionnalité importante depuis des années. J’étais aussi excité que le jour où j’ai envoyé mon premier patch à un projet open source.

En ajoutant les messages cours, j’avais deux choses en tête :

  1. Il fallait que ça aille vite. Soit je pliais mon POC en deux heures sans tordre l’application dans tous les sens au risque de casser l’existant, soit je changeais mon fusil d’épaule.
  2. Ça devait s’intégrer facilement avec l’existant. Pendant plusieurs années, Publify a trainé une réputation d’usine à gaz, et je ne pouvais pas me permettre de l’alourdir.

Ça a été vite, beaucoup plus vite que prévu. Avant que les enfants ne se réveillent, je pouvais enregistrer des messages courts, les republier sur Twitter et les afficher sur une page à part de mon blog sans même toucher au schéma SQL. C’était le pied.

Étendre le modèle Content pour publier des messages courts m’a pris moins de 10 minutes, et tellement peu de lignes de code que ce n’est même pas la peine d’en parler. L’URL shortener existait depuis longtemps, là encore je n’ai rien eu à faire. Ajouter l’envoi sur Twitter m’a pris 20 minutes de plus, le temps de lire la documentation de la Gem de l’API Twitter. Tout le reste, c’était de l’affinage et l’ajout d’un formulaire Web pour éviter de passer par la console Rails.

Encore un commit, et Publify rentrait dans la liste des Projets de l’Indie Web Camp, en même temps que dans une nouvelle vie.

Un peu plus tard, je connectais les status à notre state machine, histoire de pouvoir planifier mes tweets à l’avance. Un copier / coller qui m’a pris littéralement quelques secondes pour un résultat fonctionnel.

J’ai alors ajouté l’auto discovery sur les comptes Twitter et les hashtags. Une fois encore, je n’ai pas touché au coeur de l’application. Publify dispose depuis des années d’un système de filtres appliqués au texte en pré processing et post processing. Ils sont notamment utilisés pour transformer les syntaxes Markdown ou Textile en HTML, ou pour transformer des macros en jolis blocs de code indentés avec la coloration syntaxique qui va bien. 10 lignes de code plus tard, les @mentions et les #hashtags étaient transformés en liens lors de leur affichage (et j’ajoutais un premier bug dans ma TODO).

Ce n’est pas tout.

Je fais de la photo, et j’ai besoin d’une galerie afin d’exposer ce que je fais avant de l’envoyer sur Flickr, 500px ou même Instagram en utilisant feu l’API officieuse. Tout comme les webmails, les galeries photos sont l’arlésienne des projets open source, et les rares qui arrivent à maturité sont des usines à gaz inutilisables.

J’ai créé une branche locale sur mon Git, et commencé à étendre le modèle de données de Publify, toujours sans toucher un cheveux du schéma SQL. Je voulais stocker mes photos dans des albums, les taguer, une description, des commentaires, l’affichage des champs EXIF et la publication sur Flickr.

90% du code existait déjà sur Publify. Tout ce que j’avais à faire était de lier les briques entre elles.

  • Le modèle Content (le même que nous utilisons pour les articles, les pages et les status) pouvait être utilisé pour les photos. J’avais juste besoin d’ajouter une classe Photo qui en hériterait.
  • Les images seraient gérées par notre modèle Resources, qui produit déjà des vignettes de différente tailles, et que l’on peut rattacher à des objects de type Content.
  • Les albums seraient des catégories.
  • L’API Flickr est déjà intégrée dans une de nos macros: publify:flickr.
  • Pour les données EXIF, ça passera par un helper.

Et après ? Pas mal de choses, toujours sans ajouter trop de code : poster sur Facebook et d’autres silos, un calendrier compatible hCalendar / iCal / vCal avec intégration à Google Calendar… il n’y a pas vraiment de limites tant qu’il existe une API ouverte en écriture en face. Mais les projets indie Web, ce n’est pas seulement POSSE, et nous avons d’autres projets qui méritent d’être implémentés : h-entry pour syndiquer les contenus, indie auth pour l’authentification des utilisateurs, et les Web mentions pour la communication entre les sites de l’indie Web.

Quand je ne codais pas, je réfléchissait aux outils de publication de contenus, et à l’hyper domination de Wordpress. Bien que tout ce que j’ai décrit dans cet article puisse être fait avec Wordpress, j’ai la certitude que le POOSE donne une seconde chance aux outils de publication alternatifs.

Les outils de contenus “alternatifs” ont plus de chances d’attirer les hackers, parce qu’ils sont généralement moins industriels et donc plus simples à hacker rapidement. Les projets de petite taille acceptent plus facilement les contributions externes. Commencer petit par une plate-forme (Seigneur que je hais ce terme) codeur / hacker friendly est la meilleur chance pour le POSSE de se répandre de la même manière que le jeune Wordpress a permis l’expansion du blogging auto hébergé.

Quand je suis revenu de vacances, j’avais la réponse à ma question : est-ce que ça vaut le coup de développer un outil de blogging en 2013 ? Oui, s’il ne s’agit pas d’un outils de blogging.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: