Comment je vais tenter de gagner un peu d'argent avec un projet opensource

Quoi ? Argent et opensource dans la même phrase ?

Oui ! Chiche.

En avril 2013, je créais wallabag (qui s'appelait alors poche) pour mes besoins personnels uniquement.

De fil en aiguille, le projet a pris un peu d'ampleur. Jusqu'à devenir aujourd'hui quelque chose qui me prend beaucoup de temps tous les jours.

Nous sommes une équipe de trois développeurs (j0k3r et tcitworld), accompagnés par les développeurs des applications Android, iOS et Windows Phone et des extensions Chrome et Firefox, et enfin une équipe d'une dizaine de traducteurs. Ça commence à faire un beau petit projet.

Courant 2013, j'ai lancé un service de création à la demande de wallabag (qui s'appelait alors app.inthepoche.com). En janvier 2014, après avoir rejoint l'équipe de Framasoft, ce service se renommait Framabag. Aujourd'hui, ce service compte plus de 11.400 comptes : la création d'un compte étant gratuite, ces comptes ne sont pas tous utilisés régulièrement, bien évidemment.

Puisque ce projet me prenait de plus en plus de temps, je me suis rapidement mis dans la tête d'essayer de bosser de manière plus officielle dessus, d'en faire mon job. À la manière de Piwigo.com, Kanboard / Miniflux, FeedHQ ou encore Wordpress, pourquoi ne pas tenter de gagner de l'argent avec un projet open source ?

Plusieurs solutions pour ça : se mettre à son compte et tenter d'en vivre à 100%, profiter d'un licenciement, bosser la nuit, etc.

L'idée de me mettre à mon compte exclusivement pour wallabag a vite été écartée : maison à nourrir et enfants à payer (ou presque) ont eu raison de moi.

L'an dernier, j'ai tenté la rupture conventionnelle (qui a l'avantage de vous proposer des aides assez rapidement), ça n'a pas pu se faire.

J'ai dernièrement changé d'employeur, où j'ai pu demander un 80% pour consacrer encore plus de temps au projet. Le risque était minime : moins de salaire OK, mais c'est suffisant pour nourrir la maison et 1 journée par semaine pour wallabag (en plus des soirées déjà consacrées).

Niveau création d'entreprise, plusieurs solutions également : auto entrepreneur, entreprise individuelle, travailler illégalement.

Le top aurait été de ne pas choisir le statut auto entrepreneur (statut contraignant, etc.), mais clairement, je n'avais pas envie de me lancer dans une tonne de paperasses : ça m'aurait encore plus fait perdre de temps. Donc du coup, j'ai choisi le statut auto entrepreneur : en 10 minutes (dont 9 minutes pour choisir le bon type d'entreprise à créer), c'est réglé.

Les récents changements dans le secteur des read it later (Instapaper racheté par Pinterest, fermeture de Readability) et tcitworld) (qui m'a bien remotivé) m'ont poussé à me lancer. Enfin.

Coup de chance, en démarrant tout ça, j'ai été contacté par une entreprise pour développer de nouvelles fonctionnalités sur wallabag : ces idées étaient dans notre roadmap, le fait que cette entreprise les souhaitait a juste modifié le calendrier. Ces fonctionnalités ont été (ou seront) toutes intégrées dans l'application open source : tout le monde est gagnant dans l'histoire.

Restait à mettre en place la partie Abonnements et un site vitrine pour présenter le service.

Concernant la partie Abonnements, techniquement c'est un bundle (= "plugin", "module", "addon" si vous n'êtes pas dans le monde Symfony, le framework qui fait tourner wallabag) qui gère tout ça. Puisque les utilisateurs de l'application opensource n'ont pas besoin de ce bundle, je ne me voyais pas l'intégrer à l'application opensource distribuée sur wallabag.org. J'ai donc un fork de ce projet (en dépôt privé pour l'instant) où je récupère les dernières évolutions de wallabag. Si ça vous intéresse, j'ai suivi cette doc trouvée sur StackOverflow. C'est prévu que je rende ce fork opensource. Il me reste juste à nettoyer un peu et ajouter des tests.

Pour le site vitrine, j'ai trouvé un thème tout fait sur html5up.net, j'ai développé un petit projet Silex et voila. Ce site sera lui aussi bientôt opensourcé.

L'un des atouts du service wallabag.it que je voulais mettre en avant était le côté vie privée. C'est pourquoi le choix des partenaires choisis était important : web4all.fr pour l'hébergement, Mailjet pour l'emailing et PayPlug pour le paiement en ligne. Il n'y a que pour le site de support où j'ai mis en place FreshDesk, je n'ai pas encore trouvé d'alternative française ou européenne à moindre frais (si vous en connaissez, prévenez-moi). C'est moins critique car le site de support n'est pas utilisé pour stocker les articles, pour les infos bancaires ou pour les infos type adresse email. Mais il faut remplacer ce service, ça sera peut-être fait avec l'installation d'une application auto hébergée.

Et puis voila, tout était prêt : il fallait bien se lancer un jour ou l'autre. Samedi 3 décembre (le 3 revient souvent dans les dates de wallabag : 3 avril 2013 et le tout premier commit, 3 octobre 2013 et la v1, 3 avril 2016 et la v2, 3 octobre 2016 et la v2.1), samedi 3 décembre donc, j'ai sauté le pas. Tout s'est mis en place presque sans encombre.

Beaucoup de retours positifs par mail ou sur twitter. Personne pour me dire Quoi ? Argent et opensource dans la même phrase ?. Des premiers clients (je ne suis pas encore arrivé aux 22 millions de comptes chez Pocket mais je m'en approche tout doucement quand même !), des premiers bugs : bref ça y est. C'est parti.

Aujourd'hui on peut donc se créer un compte sur wallabag.it pour me payer mes prochaines vacances (profitez-en, y'a une promo jusque début mars !). Pour moins d'un café par mois, vous avez accès à la toute dernière version de wallabag, avec toutes les fonctionnalités actives (comme par exemple l'import asynchrone depuis Pocket / Instapaper et cie, ce qui vous évitera d'installer RabbitMQ ou Redis sur votre Raspberry).

Vous pouvez aussi installer wallabag chez vous en téléchargeant tout ça ici. Le projet est et restera open source et gratuit. Ne faites confiance qu'à vous même pour gérer vos données :-)

wallabag 2.1 : imports asynchrones, gestion des utilisateurs, etc.

Aujourd'hui est un grand jour pour wallabag : il y a trois ans tout juste, nous sortions la version 1.0.0 de poche, il y a six mois, c'était la 2.0.0 et aujourd'hui, c'est la 2.1.0.

Je ne vais pas copier / coller / traduire l'article publié sur le blog du projet, mais parmi les principales nouveautés, on a :

  • la possibilité d'importer depuis Pocket / Readability / Instapaper et les favoris Chrome et Firefox. Le tout en asynchrone avec Redis ou RabbitMQ pour éviter de faire tomber votre serveur avec des milliers d'articles.
  • une gestion d'utilisateurs : pratique pour ajouter / modifier / supprimer des utilisateurs sur votre instance de wallabag.
  • le partage public d'un article
  • une nouvelle version de l'appli Android

Lisez le billet de blog (en anglais) ici https://www.wallabag.org/blog/2016/10/03/wallabag-21 pour avoir toutes les infos.

Un énorme merci à Thomas et Jérémy pour tout le travail fourni sur cette superbe version <3 !

Appel aux fabricants de liseuses

La rentrée littéraire approche.
L'occasion de lancer un petit appel aux fabricants de liseuses.

wallabag est un service de lecture différée : vous sauvegardez en un clic des articles web dans votre compte et vous les lisez en mode déconnecté sur votre smartphone ou tablette. Le tout dans un mode épuré pour ne vous concentrer que sur le contenu de l'article.
Une présentation vidéo existe et vous permettra de mieux comprendre l'idée : https://vimeo.com/167435064.

Nous sommes une alternative libre et opensource à Pocket.
Pocket, une solution propriétaire déjà intégrée sur les liseuses Kobo https://fr.kobo.com/help/category/related-products/pocket?products=Pocket

Notre idée : voir wallabag intégré chez un ou plusieurs fabricants de liseuses.

Le travail à fournir n'est pas impressionnant : wallabag propose déjà un export des articles aux formats ePUB et PDF (et bien d'autres).
Techniquement, wallabag propose déjà une API pour permettre aux applications des liseuses de récupérer les contenus sauvegardés.

Si vous travaillez dans le monde de l'édition numérique, si vous êtes fabricants de liseuses (et vous souhaitez concurrencer Kobo :-) ), si vous connaissez quelqu'un qui travaille dans l'édition numérique, si vous souhaitez pouvoir utiliser wallabag sur votre liseuse, écrivez-moi à nicolas@loeuillet.org, contactez-moi via twitter @nicosomb, partagez ce message, commentez-le ci-dessous, diffusez-le :)

PHP Tour à Clermont-Ferrand, les slides

Cette semaine, c'était le PHP Tour à Clermont-Ferrand. On était présent avec Jérémy pour parler de wallabag et de la migration d'un projet PHP tout pourri mais qui marche à une application plus qualitative, basée sur Symfony (mais c'est pas uniquement pour ça que c'est plus qualitatif, lisez les slides).

Pour notre présentation, je trouve qu'on s'en est plutôt bien sorti, malgré le manque de préparation (on n'a pas répété à deux avant de passer, le midi on se demandait encore qui parlait à quel moment, etc.). Mais les retours qu'on a eus pour l'instant semblent corrects.

Slides de "wallabag : comment on a migré vers Symfony 3"

Si vous avez assisté à la conf, n'hésitez pas à laisser un avis sur joind.

Notre conf

Wow beaucoup de monde

wallabag était plutôt bien représenté : hormis notre conf, Joel Wurtz a dockerizé wallabag lors d'un atelier et Kévin Gomez a présenté RulerZ avec forcément une slide sur son implémentation dans wallabag. Merci à vous !

Santé !

Merci à l'AFUP et Clermont'ech pour l'organisation de l'événement !

Santé !

wallabag everywhere

Un dépôt monolithique pour wallabag ?

Un dépôt monolithique, kézaco ? C'est un dépôt global, qui regroupe tous les applications de votre projet.

Par exemple, un dépôt monolithique pour wallabag, ça serait un dépôt qui recense le code source de l'application web, de la documentation, du site web, de l'appli android, de l'image Docker, etc.

Mais t'es fou ? Tout dans un seul dépôt ?

Oui. Tout.

Quelques exemples de projets qui font ça ? Google, Facebook ou plus proche de wallabag, Symfony.

Dans le projet Symfony, il y a un dépôt qui regroupe tout le code source du framework et un dépôt par composant.
Par exemple, le composant Console a son propre dépôt ici : https://github.com/symfony/Console et se trouve aussi dans le dépôt global : https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Console

Tout est synchronisé automatiquement (via un outil développé par Fabien Potencier pour remplacer git subtree, pas assez performant pour un projet comme Symfony).

L'intérêt ? La personne qui souhaite récupérer tout le projet Symfony peut récupérer le framework complet. La personne qui ne souhaite que le composant Console le peut également.

Quels intérêts pour wallabag ?

Prenons le cas de notre dépôt pour l'image Docker : https://github.com/wallabag/docker/blob/master/Dockerfile

Dans ce fichier se trouve la dernière version stable de wallabag en dur.

Dans le projet wallabag/wallabag, on a aussi des fichiers où cette version est stockée (la documentation, le README, etc.).

Si nous n'avions qu'un seul dépôt, une seule pull request serait nécessaire. Là, il en faut une par dépôt. Donc autant de revues de code nécessaires.

Certains changements (typiquement, des changements dans l'API) pourraient également impacter les applications pour smartphone par exemple. Là encore, un seul dépôt pour gérer tout ça apporterait de la flexibilité pour faire évoluer les projets.

La documentation de tous nos projets se trouverait à un seul endroit.
Il n'y aurait qu'un seul endroit pour rapporter des bugs : bien plus pratique pour les utilisateurs qui n'auraient pas à se demander si c'est dans tel ou tel dépôt.

Quelles contraintes ?

C'est là le souci : il faudrait mettre ça en place et j'ai une crainte de tout casser.

Il faudrait aussi mettre en place la synchronisation automatique entre tous les dépôts, pour éviter de devoir ça manuellement à chaque merge.

Quelques inconnues sur la mise en place, mais je compte bien me lancer.
Je vais surement ouvrir un ticket sur wallabag/wallabag pour avoir l'avis des principaux contributeurs à wallabag.

À suivre donc, car je compte avancer là-dessus dans les semaines à venir.

wallabag v2 et conférence au PHP Tour à Clermont-Ferrand

Lundi 23 mai, avec Jérémy, nous serons à Clermont-Ferrand pour parler de wallabag, comment on a migré vers Symfony3.

wallabag est une application opensource de lecture différée : elle vous permet de mettre de côté la version épurée d'un article pour la consulter plus tard où que vous soyez. Créée il y a 3 ans à base de fichiers PHP comme on faisait en 2005, nous avons décidé il y a maintenant un peu plus d'un an de migrer le projet à Symfony. Au cours de ce talk, nous présenterons donc le projet wallabag et tout son écosystème : son concept, son socle technique (API REST, tests unitaires, Rulerz, RabbitMQ, Capistrano), les difficultés rencontrées, la communauté et les projets qui tournent autour, la roadmap pour les semaines à venir.

D'ici là, wallabag v2 sera sortie : elle sera disponible au téléchargement en version stable le dimanche 3 avril, jour des 3 ans du projet.

Ça promet donc quelques semaines encore bien chargées.

Ah tiens, on a commandé des stickers pour le projet. J'en aurai forcément sur moi, n'hésitez pas à venir m'en demander.

Stickers wallabag

Nouvelle alpha pour wallabag v2

Et voila, après 4 mois de travail plus ou moins acharnés, on vient de sortir une nouvelle alpha avec pas mal de nouvelles fonctionnalités bien sympas, comme :

  • l'import depuis wallabag v1 et pocket (en 1 clic, via leur API \o/)
  • l'assignation automatique de tags quand on ajoute un nouvel article (en fonction de règles que l'on peut créer facilement)
  • l'enregistrement public
  • la validation via email pour se connecter
  • l'export des articles dans une tonne de formats différents (PDF, JSON, EPUB, MOBI, XML, CSV)

Le billet complet (en anglais) est sur le blog du projet.

Pour installer / tester :

git clone https://github.com/wallabag/wallabag.git -b v2
cd wallabag
composer install
php app/console wallabag:install
php app/console server:run

Amusez-vous bien, on retourne bosser !

CMS, frameworks : recensement des versions de PHP (décembre 2015)

J'ai annoncé hier que wallabag 2 ne serait pas compatible avec PHP <= 5.4, en conseillant vivement aux personnes qui avaient un serveur avec une version de PHP <= 5.4 de le mettre à jour.

Pour quelle raison wallabag ne sera pas compatible ? Car wallabag implémente Rulerz (pour avoir un joli moteur de règles) qui utilise les générateurs (source).

Suite à une discussion avec Pierrick de Piwigo (qui me conseille de ne pas aller trop vite pour ne pas se couper une part non négligeable d'utilisateurs), j'ai décidé de faire le tour des applis PHP pour voir si on était dans le vrai ou pas avec wallabag.

Petit rappel : PHP 5.4 n'est plus maintenu (même les failles de sécurité) depuis le 3 septembre 2015. Faut-il aussi vous rappeler que PHP 5.3 n'est plus maintenu depuis août 2014 et pour PHP 5.2, c'est depuis le 6 janvier 2011 (il y a bientôt 5 ans) ? (source)

C'est facile de dire de mettre à jour son serveur, mais comment faire quand on est sur du mutualisé ?

Jetons un œil du côté de certains hébergeurs

OVH

Possible d'installer PHP 5.5, 5.6, 7 (source)

Web4all

Possible d'installer PHP 5.2, 5.3, 5.4, 5.5 (source)

Alwaysdata

Possible d'installer PHP (accrochez-vous) ... 4.4.9 et de 5.2.5 à 7.0.0 (source).

Non, je ne reviendrai pas sur PHP 4.4.9 (mort depuis 7 ans et 4 mois). NON.

Bilan

OK, je n'ai pas fait le tour de 10.000 hébergeurs, mais on voit quand même qu'il existe des hébergeurs grand public qui ont des versions correctes de PHP. Donc si votre hébergeur actuel ne vous propose pas PHP 5.5, contactez-le ... ou quittez-le. Ce n'est pas à vous de payer les lenteurs de votre hébergeur.

CMS & frameworks

Frameworks

  • Zend Framework 3 : PHP > 5.5 (source)
  • Slim Framework 3 : PHP > 5.3 (source)
  • Laravel 5.1 : PHP > 5.5.9 (source)
  • Symfony 3.0 : PHP > 5.5.9 (source)

50% PHP 5.3 et 50% PHP 5.5

CMS

  • Wordpress 4.4 : PHP > 5.2.4 mais PHP > 5.6 recommandé (source). Je retiens (parce que ça m'arrange pour mon argumentaire) que Wordpress encourage vivement PHP 5.6 (ils proposent même un mail type à envoyer à son hébergeur).
  • Joomla 3 : PHP > 5.5 (source)
  • Drupal 8 : PHP > 5.5.9 (source)
  • Typo3 7.6.0 : PHP > 5.5 (source)
  • Magento 2 : PHP > 5.5 (source)

80% PHP 5.5 et 20% 5.6

Autres applications

  • Piwik : PHP > 5.3.3 mais > 5.5 en 2016 (source). Je retiens donc PHP 5.5 car 2016, c'est demain.
  • Piwigo : PHP > 5.2 (source)

50% PHP 5.2 et 50% PHP 5.5

Conclusion

Nous avons donc :

  • PHP 5.2 : 9%
  • PHP 5.3 : 18%
  • PHP 5.5 : 64%
  • PHP 5.6 : 9%

En annonçant donc que wallabag v2 ne serait pas compatible avec PHP <= 5.4, je me situe dans les 73% des applis / frameworks présentes dans cet aperçu.

OK, des personnes ne pourront pas installer wallabag v2 du premier coup, mais ça leur permettra peut-être de se dire qu'il serait temps de changer de crèmerie.

Je suis bien évidemment pour avoir un maximum d'utilisateurs et se dire que potentiellement, on perd 30% d'utilisateurs, c'est beaucoup. Mais j'estime également que nous avons un rôle en incitant les gens à mettre à jour leurs plateformes.
En dehors d'avoir le dernier gadget à la mode dans notre application (nous ne forçons pas les gens à avoir PHP 7 par exemple), c'est surtout une question de sécurité : les anciennes versions de PHP ont des failles de sécurité qui ne seront jamais corrigées.

Racisme ordinaire entre Paris et Calais

À bord du TGV Paris - Rang-du-Fliers, qui passe par la gare de Calais Fréthun.


Un père et son fils, sur la plateforme entre deux voitures. Un homme monte et leur demande en anglais si c'est bien le train pour Calais. Le père répond "Non, c'est la voiture à côté". L'homme le remercie et s'en va.

Le père : "Comme ça, il ne sera pas avec nous ici".

Une seule envie à ce moment-là, lui dire que c'était un abruti.


Un autre jour, toujours sur la plateforme entre deux voitures. À côté de moi, deux hommes discutent. Ils ne sont pas français. Le contrôleur passe une première fois. Quelques minutes après, il repasse "Contrôle des titres de transport". Je tends ma carte d'abonné, il la regarde à peine "C'est bon, merci" (alors qu'il est censé la bipper pour savoir si mon abonnement est à jour). Il se dirige tout de suite vers les deux hommes : "You go to Calais ?" (les formules de politesse, déjà, tu peux oublier).

L'un des deux tend son justificatif. Le contrôleur l'inspecte durant quelques minutes, rentre dans la voiture avec le justificatif, ne contrôle personne d'autre puis ressort et rend le justificatif.

Contrôle au facies, je pense fortement que c'est illégal. Mais quotidien.

Ces deux hommes qui descendent à Calais Fréthun pour prendre une correspondance pour Calais ville se voient tout de suite refuser la montée par le contrôleur du second train : "Vous allez où?" en se mettant sur leur passage. Son collègue, aussi aimable, avait au moins fait l'effort de poser la question en anglais.


Passer tous les jours par Calais (et donc pas très loin de son camp de réfugiés), c'est entendre et voir le racisme ordinaire. De la part des autorités (police, SNCF) mais aussi et surtout des gens dans le train. Vomir.


Pendant ce temps, toujours à Calais, des centaines d'arbres ont été déracinés, pour raison de sécurité (lire ici, photos © La Voix du Nord).

Arbres déracinés

Arbres déracinés

Des milliers de personnes vivent dans un état d'insalubrité innommable, on ne s'occupe pas de leur trouver une douche, des toilettes, mais on déracine des arbres pour éviter que ces gens ne s'y abritent, ou s'y cachent (oui, ils se cachent là, et alors ? Vu les persécutions, c'est pas plus mal pour eux).

Forcément, des jours ça dégénère entre les forces de l'ordre et ces personnes qui fuient la guerre. Mais vivre dans la boue pendant des jours et des nuits, au bout d'un moment, ça doit fatiguer et énerver.

Je n'ai aucune solution à ce problème de réfugiés, mais clairement, les laisser pourrir dans la boue n'est pas la solution.

Et Mozilla décida de remettre Pocket en addon

move pocket to a built-in add-on, c'est le titre du ticket ouvert sur Bugzilla le 16 octobre dernier par Shane Caraveo.

We're moving pocket to a built-in addon. This will facilitate user choice (I rip the pockets off everything I own), alternate firefox distributions that do not want to include the feature, etc. As well it will help to identify any potential issues with using add-ons for feature implementation.

Pour rappel :

Alors, forcément, c'est une bonne nouvelle que Firefox n'embarque plus nativement Pocket (pour laisser le choix aux utilisateurs, tout ça), mais ce rapide retour en arrière est quand même inquiétant sur la gestion de tout ça en interne.