Publish or not Publish

posté par Jérôme Vieilledent, le 17/10/2009 13:25

Tags : open source , contribution , ezpublish

Logo open source

eZ Publish est un lociel Open Source, nous le savons tous. Derrière eZ Publish, il y a une société privée, eZ Systems qui a honorablement choisi un business model totalement orienté sur l'Open Source en décidant, à l'image d'autres société du secteur comme Red Hat ou MySQL , de développer un logiciel libre et de vendre en parallèle des services de consulting, de support et de formation.

À côté de cela, eZ Publish est souvent intégré par des sociétés privées pour le compte de clients divers (Voyages-SNCF, Canal+, JC Decaux, Prisma Presse, etc...). Parmi ces sociétés, on retrouve souvent Smile , SQLi , Noven , Novactive , etc... C'est un marché qui semble bien huilé, surtout en France, autour d'un produit excellent et dynamique qu'est eZ Publish. Mais quel rapport avec le titre du billet ?

Publier ses extensions à la communauté

communauté open source

Récemment, dans le cadre d'un projet, j'ai eu à développer une extension permettant de cropper les images avec une interface dédiée, que j'ai bien entendu décidé de publier. Jusqu'à présent, cela n'avait jamais posé de problème à mon employeur, du moment que je précisais que l'entreprise était derrière le développement de la contribution. J'ai comme cela pu mettre à la disposition de la communauté un certain nombre d'outils (jvAMF , NovenUtils , NovenINIUpdate - publiée initialement par Jean-Luc Nguyen ).

Le problème, c'est que cette logique commence à heurter une certaine politique commerciale dans mon entreprise et on me l'a fait remarquer en me disant :

 Je pense que tu as suffisamment contribué, maintenant tu arrêtes.

Mais pourquoi devrais-je arrêter ?

 Parce que c'est notre savoir-faire et qu'il y a de la concurrence !

Nous y voilà !

De l'Open Source en entreprise

Ubuntu, open source

Le sujet est posé et bien réel ! Comment réussir à concilier le monde du logiciel libre avec le monde de l'entreprise ? Que faire si l'entreprise refuse de jouer le jeu ?

Personnellement, je suis à fond pour le partage à la communauté car je suis convaincu que cette démarche fait avancer l'informatique bien plus vite et bien plus loin que l'autre démarche que je qualifierais de fermée. Par ailleurs, les entreprises intégratrices du logiciel libre sont le plus souvent bien heureuses de trouver des outils issus du monde du logiciel libre afin de pouvoir développer son activité ! Je pense là à Nuxeo , Eclipse , les logiciels de la fondation Apache , Open Office , et j'en passe ! Et c'est bien là où cela me gène ! Comment peut-on avoir un comportement fermé alors que l'on profite pleinement d'outils libres ?

Concernant un logiciel CMS comme eZ Publish, il me paraît normal de publier son travail, sauf dans certaines conditions touchant à la confidentialité et à certaines spécificités liées à chaque projet bien évidemment. A propos de l'aspect commercial, je suis persuadé que le fait de publier contribue énormément à donner une bonne image de l'entreprise. En outre, cela permet également d'avoir des retours de la communauté sur d'éventuels bugs ou améliorations possibles, qui n'auraient peut-être jamais été remontés, ou alors en production, dans l'urgence.

Voilà ce que j'avais à dire sur le sujet. Je ne compte bien sûr pas m'arrêter là dans les publications de contribution, mais il est fort probable que je le fasse désormais en mon nom propre...

Related content

Commentaires

community manager (par Gandbox)

... et tu auras peut être droit à : "maintenant tu arrêtes ce blog !"

Plus sérieusement, les entreprises ne savent pas trop comment exploiter positivement ce phénomène de communauté professionnelle ultra concurrentielle. de mon point de vue tout le monde est gagnant :
- L'entreprise valorise son savoir faire et ses experts, en communiquant indirectement sur certaines spécialités
- Le développeur valorise son travail, et se valorise lui même
- L'éditeur profite d'extensions fonctionnelles, et valorise le dynamisme de sa communauté

L'éditeur a d'ailleurs une part de responsabilité dans cette promotion des avantages développeurs / entreprises / éditeurs autour des contributions. Au dernières eZ Matinales (Vendredi 16/10), eZ Systems a d'ailleurs annoncé la création du poste d'un community manager Français, qui je l'espère saura animé un groupe de réflexion autour de ce sujet stratégique.

La vérité... (par Wascou (www.wascou.org))

... c'est que ces entreprises auparavant citées dépendent étrangement de notre expertise et de notre capacité à créer des extensions en phase avec une réalité du marché. En clair, tu penses qu'il manque une extension à eZPublish, tu la réalises pour ton compte ou dans le cadre d'un projet et ensuite tu la reverses à la communauté. Finalement, ceux qui sont les gagnants de cette histoire sont :

- toi : parce que tu as contribué à faire avancer l'ensemble, eco système or not
- eZ Systems : parce qu'en ne faisant rien, ils vont te faire signer un papier indiquant que tu cèdes tous tes droits et intégrer cette "brand new feature" dans leur version 7.x.
- les concurrents de ta société : puisqu'ils vont bénéficier d'une fonctionnalité qu'ils auront un jour à développer pour rien du tout.

J'avoue mettre déjà penché sur ce problème et il semble que ceci émane clairement du manque de clarté sur le point suivant : à qui appartient le code que tu réalises en dehors du boulot classique ? J'ai donc vérifié dans mon contrat de travail, tout ce que je fais en touchant un ordinateur appartient à mon employeur.

Concrètement ça craint, mais par contre, rien ne t'empêche d'avoir un blog dans lequel tu expliques ce que tu fais puisque tu ne révèles ou ne diffuses aucun code. Si tu veux aller plus loin et regagner ta liberté de développeur aguerri, il va falloir trouver une autre solution.

Pas question d'arrêter (par Jérôme Vieilledent)

Pour moi, il n'est pas question d'arrêter de publier mon code source, dans la mesure de mes possibilités bien sûr.
@Wascou : Je pense que ce que tu décris de ton contrat de travail est une clause abusive ! C'est comme si ton employeur te disait que ta voiture lui appartenait aussi !
@Gandbox : C'est une excellente nouvelle ce Community Manager ! J'espère que justement il contribuera à améliorer la situation de ce côté là au niveau des entreprises.

En tout cas, une chose est sûre... Si je dois changer de poste, je prendrai bien soin à parler de cette problématique, car c'est pour moi un point important !

Un sujet pour notre prochaine rencontre (par Nicolas)

Ce sujet est, comme Gandbox le dit, stratégique pour l'ensemble de l'écosystème. Clairement un des thèmes clés de notre prochain rassemblement communautaire, à la eZ French Corner. Le programme de nos rencontres devrait être proposé d'ici quelques semaines, affaire à suivre.

Je vois avec plaisir Jérôme que ton activité éditoriale est fournie, pourvu que ça dure !
--
Nicolas
eZ Community Manager

Sur le contrat de travail... (par Nicolas Steinmetz)

... la remarque de Wascou est tout à fait juste - ce que tu produis pendant ton boulot appartient à ton employeur et seul lui peut t'autoriser à le publier sous la licence de son choix.

C'est assez logique d'ailleurs vu qu'il te rémunère en échange d'un travail et que le client commandite ta boite pour réaliser un projet. D'ailleurs, le code est même plus au client qu'à ta boite si on va jusqu'au bout du raisonnement.

Quand j'étais en SSLL comme Linagora ou SSII comme Clever Age, pour publier du code il fallait l'autorisation du client et de la boite. Dans mon cas, la boite était plutôt pour vu que ca lui permettait de "briller" un peu sur la place en disant "moi je contribue à XXX". Pour le client, j'ai vu de tout : aussi bien celui qui veut tout publier en supposant que la communauté maintiendra son spécifique que le client qui veut rien publier du tout mais qui voudrait que la maintenance des dev soit gratuite

A l'inverse, je code sur mon temps libre (principalement, j'ai quand même bosser 2 journée de travail dessus) un outil pour JCDecaux, je sais pas trop quel statut cela peut avoir d'un point de vue licence...

Beau sujet épineux (par Bertrand Dunogier)

Effectivement, c'est un sujet difficile. Comment faire cohabiter le côté opensource et l'entreprise pour laquelle on travaille.

Déjà, un bénéfice très net pour l'entreprise: le fait de voir que Noven, ou autre, contribue des extensions de qualité augmente clairement la réputation de la société au sein de l'écosystème eZ. En ce qui me concerne en tout cas, c'est un gage de qualité, d'autant plus que contrairement à des projets clients classiques, l'accès au code source permet de se rendre compte de la qualité du travail effectué.

Pour ce qui est de la license et des contributions, attention: eZ Systems ne s'approprie en aucun cas les contributions. Là où une signature, en l'occurence la CLA, est demandée, c'est dans le cas de la contribution à eZ Publish même. Il est impossible pour eZ d'intégrer un patch fourni par un membre de la communauté sans cession de ses droits sur ce même patch. Par contre, une contribution ou extension reste totalement séparée du CMS même, et le contributeur est libre de choisir sa license.

Je comprends malheureusement la remarque qui t'a été faite. Le fait est que tes extensions seront certainement utilisées par la concurrence. Cependant, ces contributions étant faites sous une license qui les protègent, leur présence, et leur auteur, donc ton employeur, seront visibles dans les crédits du site, leur suppression allant à l'encontre de la license utilisée. Cela voudra dire que la société X utilise le travail de la société Y, et cela en embêtera certainement quelques uns. Le même discours serait valable pour eZ Publish lui même. Après tout, nos concurrents peuvent sans aucune difficulté récupérer des parties de notre code, nos idées, etc, pour les intégrer à leurs produits.

Peut-être la solution réside-t-elle dans les extensions certifiées ? Clairement un sujet à débattre avec notre nouveau Community Manager

Le partage est un investissement ! (par Ronan)

Ce sujet est régulièrement mis en débat dans mon entreprise. Par chance la Direction n'est pas opposée à l'idée de partager des développements, mais elle y met des conditions.

Je te rejoins dans ton témoignage : Pour une majorité de développeurs, il est devenu évident que l'innovation se nourrit du partage des connaissances. Imaginer investir des mois de développements en interne pour inventer une solution au code fermé et breveté, qui sera "innovante" pendant 3 mois, ça ne devrait plus avoir de sens pour aucune entreprise travaillant sur le web. Mais c'est pourtant encore comme cela que réfléchissent pas mal de "décideurs" rencontrés ces dernières années.

Mais si certaines sociétés trainent des pieds avant de partager un développement pertinent, c'est quelques fois aussi parce que le code libéré et rendu public devient une "carte de visite" supplémentaire pour l'entreprise. Cette image de l'entreprise à travers le code libéré est finalement un retour sur investissement non négligeable, et ça vaut le coup de sensibiliser les entreprises sur ce point. Si le code est bon et les fonctionnalités innovantes, alors c'est le savoir de l'entreprise qui est prouvé publiquement. Si le code n'est pas irréprochable, ou si le projet est trop vite abandonné, l'image de l'entreprise (ses méthodes, son engagement, ses compétences) peut en pâtir. Dans ma boîte, on est prêt à libérer une ou plusieurs petites extensions utiles, simplement la Direction souhaite avoir une retour sur investissement minimum : une bonne image. Ca passe par une extension rendue vraiment "propre" avant d'être publiée.

Je pense aussi que cela ne vaut pas la peine pour une entreprise de rendre public un développement si c'est pour l'abandonner au bout de quelques mois. L'image de l'entreprise n'en sera pas meilleure. A ce titre, libérer une "simple" extension pour eZ est une manière très intéressante pour une entreprise de contribuer au monde du Libre, car il s'agit d'une quantité de code plutôt réduite, donc facile à suivre et à faire évoluer. C'est une démarche qui peut donc durer dans le temps, à l'inverse d'un "gros projet" libre qui mobiliserait beaucoup plus de ressources.