Nos clients sont sponsors de nos plugins Open Source !

Ce sont nos clients, la communauté et notre expérience en e-commerce qui nous donnent des idées de plugins.

Proposer gratuitement sous licence Open Source un code source réalisé par Monsieur Biz sur les projets de l’agence web implique forcément des règles strictes afin que ça soit équitable pour tous. Il serait dommage que les clients ne s’y retrouvent pas.

Pourquoi proposer du code Open Source ?

Beaucoup de logiciels fonctionnent aujourd’hui avec du code Open Source : les systèmes d’exploitation (Windows, macOS, Linux…), les applications mobiles, les sites internet…
L’Open Source est basé sur l’échange et la confiance (et le droit des contrats aussi…).
Quand vous donnez gratuitement (et sous licence) du code source et que celui-ci sert à d’autres et bien généralement ce sont ces mêmes personnes qui viennent ouvrir des issues (bugs), parfois les corriger, ajouter des fonctionnalités, corriger la documentation, etc.
Nos clients acceptent parfois de payer pour une fonctionnalité qui sera publiée gratuitement sous licence Open Source.
En échange, la communauté améliore ce code, directement ou indirectement. Et nous aussi ! Car évidemment nous faisons vivre les projets sur lesquels nous travaillons et apportons donc régulièrement des améliorations sur les plugins existants. D’ailleurs on ne le fait évidemment pas que pour nos plugins mais aussi pour directement ou les plugins de la communauté.
Ça profite à tout le monde !
La communauté progresse car ils ont une fonctionnalité intéressante et notre client a bien investi son argent car il profite à moyen/long terme des améliorations, par la communauté mais pas que, sur le code source qu’il utilise.

Quel code source peut-on libérer ?

Evidemment on ne libère pas n’importe quoi. Il faut que le code source qui va être mis à disposition de la communauté apporte quelque chose d’intéressant, sinon l’échange ne fonctionnera pas.
Par exemple si vous faites ajouter une fonctionnalité qui a le potentiel de bénéficier au plus grand nombre sur votre site e-commerce alors nous viendrons vraisemblablement vous proposer de la passer en Open Source. Au contraire, si vous faites développer une fonctionnalité qui n’est utile que pour vous alors il est inutile de la proposer en Open Source.
D’ailleurs nous refuserons de le faire !
Dans tous les cas c’est après une discussion avec nos clients que nous décidons ou non de mettre du code en Open Source.
En général on le propose avant même le début des développements !

La mise à disposition du code source

• Le code source est forcément proposé sous licence EUPL 1.2 ou MIT, selon la préférence du sponsor. Sans choix précis de la part du client alors la licence choisie sera automatiquement la licence MIT, qui est moins contraignante selon nous.
• Le code source sera accessible publiquement dès que Monsieur Biz considèrera que celui-ci est assez mature et n’entache ni à la réputation du client ni à celle de l’agence.
• Le code source est hébergé sur le compte Github de Monsieur Biz, au nom de Monsieur Biz. Evidemment il est possible de proposer un code sur le github de notre client, par exemple s’il souhaite développer une extension
• pour son business, mais dans ce cas il s’agit d’un développement standard et les avantages dont nous parlons plus bas ne peuvent pas s’appliquer.
• Les traductions gérées par défaut dans le code source sont l’anglais et le français à minima.
• Le code source doit être de qualité : nous nous engageons à afficher une jauge de qualité sur la page principale de la documentation (dans le fichier README généralement).
• On ne peut pas faire marche arrière une fois que le code est libéré.

Ces quelques règles ne sont pas contraignantes.

Nos clients sont sponsors !

Obtenir une participation de la communauté sur le code source dont on est sponsor n’est pas le seul avantage.
Chez Monsieur Biz nous proposons en plus à notre client d’apparaître comme sponsor directement dans le fichier README du code libéré :

• Le nom et le logo du client, ainsi qu’un lien hypertexte vers l’adresse web de son choix sont affichés dans le fichier README du projet, dans la section « Sponsors ».
• Le client peut ne pas être le seul sponsor, il n’y a pas d’exclusivité. Si un autre client de l’agence souhaite améliorer le code source (ajout d’une fonctionnalité) par le biais de la facturation alors il deviendra sponsor également. Evidemment quand nous développons sur les projets de l’agence et que nous trouvons un bug dans une librairie utilisée et bien nous essayons tant que faire se peut de proposer le correctif aux développeurs, même si c’est sur un plugin que nous maintenons. C’est l’effort collectif !
• Le client a bien sûr le droit de refuser d’apparaître comme sponsor, et il peut changer d’avis sur ce point s’il le souhaite !

Aspects financiers

Lors du développement d’une fonctionnalité Open Source pour le projet le client s’engage à payer comme si cette fonctionnalité n’était que pour lui.
Le fonctionnement pour le client est donc le même que d’habitude.

L’engagement de Monsieur Biz

Cependant la libération d’un code source implique forcément un effort supplémentaire de la part des développeurs : meilleure documentation, développements supplémentaires pour que le code soit bien détaché du reste du projet, ajout de certains tests automatisés qui ne sont pas toujours nécessaires sur un code privé, etc.
Cet effort pourrait donc avoir un impact direct sur la quantité de fonctionnalités développées : si on passe plus de temps sur la gestion de l’Open Source alors on en passe moins sur le fonctionnel.
Afin d’éviter que nos clients ne soient lésés par la libération du code source et bien nous nous engageons à passer 15% de temps supplémentaire, non facturé, à la fin des développements, sur le code concerné.

Rien de mieux qu’un exemple pour tout comprendre !

Vous avez besoin de développer une fonctionnalité très intéressante et Monsieur Biz vous propose de la faire en Open Source ; Ce que vous acceptez.
Pour développer cette fonctionnalité il nous faut 100 jours. Vous acceptez donc de payer, comme à l’ordinaire, les 100 jours de développement.
Mais comme nous allons passer du temps sur des éléments qui seront uniquement nécessaires à la libération du code source : nous passerons automatiquement 15 jours supplémentaires sur le projet à la fin des 100 jours facturés (soit +15%) afin que vous n’engagiez des frais que sur la fonctionnalité demandée et non pas sur sa libération du code !
Vous obtenez donc un résultat fonctionnellement identique en 115 jours au lieu de 100. Mais le code source est maintenant sous licence Open Source et disponible pour tous. Et ça, c’est juste beau.
Vous êtes indiqué comme sponsor et profitez de la communauté pour avoir des améliorations intéressantes de votre plugin au fil des mois/années.

Conclusion

Ça ne coûte rien à notre client, uniquement à nous car nous développons 15% de temps en plus.
Ça profite à tous.
Aujourd’hui tous les développements s’appuient sur des projets Open Source, contribuer à cela c’est faire évoluer l’entièreté de l’écosystème utile à votre métier. Et puis on peut même aller plus loin et dire que ça permet de diminuer l’empreinte carbone de vos projets web !
Forcément, si un développeur peut utiliser un code déjà fait, il n’utilisera pas sa machine pour développer la fonctionnalité en question !
Bref, ce n’est que du bon. 💪