Comment devenir éditeur de logiciels libres quand on est une entreprise

Présentation

• Titre : Comment devenir éditeur de logiciels libres quand on est une entreprise
• Intervenants : Jean-Michel ARMAND
• Licence : CC-by-SA
• Durée : 43min 58s
• Lien vers la vidéo

Transcription

D'abord bonjour. Je vois qu'il y a quand même du monde pour la dernière conf' du dernier jour, c'est bien !

Donc, je vais essayer de vous parler de comment est-ce qu'on peut devenir éditeur de Logiciel Libre quand on est une entreprise. Comment ? Donc, je vais balayer un peu tout, je vais être très généraliste, je vais faire moins que quarante minutes… enfin, je vais essayer de faire moins de quarante minutes, comme ça on pourra avoir plus d'échanges et plus de discussions.

Slide « Présentation d'Hybird »

Avant de commencer, juste qui je suis, j'ai bêtement oublié de mettre mon nom sur le slide. Donc, je m'appelle Jean-Michel ARMAND, j'ai monté une entreprise avec des copains il y a maintenant sept ans, qui s'appelle Hybird. On était cinq au départ, maintenant on est sept, on est sept salariés, voilà ! On génère du chiffre suffisamment pour employer sept personnes. On a commencé par faire de la régie mais ce n'est pas très intéressant ; et surtout, on était intégrateur de VTiger, VTiger qui est un fork de Sugar. Alors, pourquoi VTiger plutôt que Sugar ? Parce que, j'en reparlerai un peu, mais la politique de licence communautaire / enterprise de Sugar ne m'a jamais bien plu, et en plus, parce qu'ils ont pris des choix au niveau CRM pur qui ne me plaisaient pas. Donc du coup, l'intérêt de prendre un CRM qui, en plus, ressemblait plus à un Logiciel Libre, à notre avis, et qui en plus, au niveau métier, était plus ce qu'on pensait être du CRM.

On a fait de la prestation jusqu'en 2008, et ensuite on s'est dit « Pourquoi est-ce qu'on reste intégrateur ? Pourquoi est-ce qu'on deviendrait pas éditeur ? ». Donc, on est devenu éditeur du CRM qui s'appelle Crème dont la première version qui était la 0.7 ou 0.8 est sortie en 2010, on est à la 1.2, c'est la sixième version, donc un choix de numération un peu bizarre, et maintenant on ne fait plus que des prestations autour de Crème.

Donc, voilà, on est éditeur, on est vraiment éditeur, on a commencé à devenir éditeur il y a quatre ans, on est éditeur d'un logiciel fini depuis deux ans et on fait notre chiffre d'affaire en tant qu'éditeur. Éditeur intégrateur, mais voilà, on fait vivre sept personnes avec un Logiciel Libre qu'on a développé à partir de zéro.

Hybird est membre de Libertis, dont j'ai été trois ans président, qui est l'association des entreprises qui font du Logiciel Libre en PACA. Donc, en plus, je me suis beaucoup inspiré de notre expérience d'éditeur, l'avantage d'être membre d'une association d'entreprises qui font du Libre, c'est que je connais d'autres éditeurs, et en préparant la présentation, je suis allé plusieurs fois taper à leurs portes en leur disant « Et vous, à ce niveau là, est-ce que vous avez eu des problèmes ? Qu'est-ce qui n'allait pas ? Qu'est-ce qui va ? Est-ce que j'ai oublié des choses à ce niveau là ? Etc. ». Voilà, ça va être un petit peu un condensé.

Slide « Faire de l'argent avec du logiciel libre, ce n'est pas SALE ! »

Pour commencer, juste parce que je l'ai souvent entendu dans les couloirs des RMLL, non, faire de l'argent avec du Logiciel Libre, c'est pas sale du tout. Je pense que c'est une des raisons qui m'a fait présenter cette conf' : voilà, faire des sous avec du Libre, c'est même très bien, voilà !

Slide « Faire de l'argent avec du logiciel libre, c'est même très bien ! »

Parce que ça fait faire plus de Libre, et puis ça fait faire qu'il y a des gens qui vivent en faisant du Libre. Donc, c'est bien, y a juste que c'est comme les chasseurs, y a les bons intégrateurs du Libre et les mauvais intégrateurs du Libre, potentiellement. Mais voilà, ce n'est pas forcément « pas bien » de faire de l'argent et de vivre et de pouvoir faire vivre sept personnes avec du Logiciel Libre.

Slide « Plan de l'intervention »

Donc, qu'est-ce que je vais essayer de balayer rapidement :

• on va commencer par voir « Éditeur, qu'est-ce que ça veut dire ? » ;
• « les business model d'un éditeur », comment est-ce que vous allez peut-être pouvoir un jour espérer gagner de l'argent avec votre Logiciel Libre en étant un éditeur ;
• il y a une des notions de communauté, communauté d'éditeurs, communauté de développeurs, communauté d'utilisateurs, etc., qu'est-ce qu'elles sont, à quoi elles servent, qu'est-ce qu'elles vont pouvoir faire, qu'est-ce qu'elles ne feront pas ;
• un truc qu'on a souvent l'habitude d'écouter des intégrateurs qui expliquent comment ils font, comment ils vivent, etc., mais vous si vous devenez un jour éditeur, comment est-ce que vous allez pouvoir gérer vos intégrateurs, comment est-ce que vous allez en trouver déjà, est-ce que vous allez en trouver, est-ce que c'est intéressant d'en trouver, et puis comment est-ce vous allez avoir des relations avec eux ;
• et enfin, est-ce qu'il y a une recette magique pour réussir ? Non, mais j'ai quelques petits conseils à mon avis, de ma maigre expérience, qui peuvent aider à faire en sorte que peut-être vous allez réussir.

Slide « Être éditeur, c'est ? »

Donc, être éditeur, qu'est ce que ça veut dire, qu'est ce que ça va vouloir dire, et notamment dans le Logiciel Libre.

Pour moi, principalement, l'éditeur dans le Logiciel Libre, ça marche aussi avec l'éditeur dans le logiciel entre guillemets, mais c'est juste que dans le Logiciel Libre, c'est encore plus important, c'est celui qui va porter la vision du logiciel, c'est lui qui va dire « voilà, je veux faire un logiciel pour faire ça ; dans dix ans, il fera ça et je vais faire en sorte de l'amener à ce que je veux ». C'est vous, l'éditeur c'est celui qui rêve au départ, celui qui a une idée, qui a un rêve, et qui va dire « je veux que ça aboutisse, je veux que ça ne reste pas une idée dans ma tête, je veux que ça soit du logiciel », donc c'est lui qui va porter la vision.

C'est lui aussi qui va passer des mois, des années, à développer, à commencer au départ. Au départ, vous êtes un éditeur, vous êtes tout seul, on reviendra après sur les communautés, mais dans mon sens, le noyau dur, au départ, c'est un investissement, il ne faut pas espérer. J'ai vu souvent, quand j'étais président de Libertis, des gens qui disaient « On veut devenir éditeur, on va faire du Libre comme ça, tout de suite, y a plein de gens sur Internet qui vont venir coder avec nous, dès la première ligne de code ». Non, faut se dire qu'au départ, éditeur, c'est un investissement important. Nous, typiquement, la première version de Crème, c'est neuf ans / homme, calés sur deux ans. Donc voilà, vous calculez combien ça fait un salaire d'une personne, vous calculez neuf ans / homme et puis voilà. Nous, on a calculé, on a dit « Ça va nous coûter ça, faire Crème, bon bah on a fait en sorte de payer ça ».

C'est celui qui va choisir la licence, alors c'est trivial, c'est du Logiciel Libre donc il faut que je cherche une licence, mais c'est important ! Nous on y a réfléchi pendant longtemps, donc Crème est en AGPL, on avait un doute entre GPL ou AGPL, il y a des avantages aux deux, des inconvénients aux deux. Quoi choisir ? Voilà, c'est pas forcément « moi je prends la GPL parce que c'est la plus connue », « je prends du BSD parce qu'on m'a dit que la BSD c'était cool ». La licence que vous allez choisir va impacter fortement votre business model derrière, va impacter les relations que vous allez avoir avec vos clients, va impacter les relations que vous allez avoir avec vos utilisateurs, avec vos intégrateurs. Donc, c'est un point important. C'est pas juste « bon, je fais du Libre, je prends la what's the fuck licence parce qu'elle va bien » et puis hop, non. Faut vraiment réfléchir ! Nous, prendre l'AGPL, ça a été de longues discussions, entre GPL et AGPL, pourquoi est-ce qu'on le fait, est-ce qu'on ne le fait pas… Donc, on a pris la AGPL mais on sait que ça va nous desservir à certains endroits, tant pis, c'est une volonté assumée, il faut le choisir.

C'est aussi vous qui allez gérer les demandes entrantes. Vous vous rendrez compte à un moment ou à un autre, si vous êtes un éditeur et que ça marche, que vous allez passer plein de temps à gérer les demandes entrantes. Les demandes de vos intégrateurs, qui vont sans arrêt vouloir que vous modifiez votre vision pour que ça cale à leur vision à eux qu'ils ont besoin. Les demandes de vos utilisateurs, les demandes des gens qui ont découvert votre logiciel à une conférence aux RMLL ou sur Twitter et qui viennent et qui vous disent « ha, c'est super bien mais ça ne pourrait pas faire tout l'inverse ? ». Donc voilà, vous allez passer plein plein de temps à gérer ça. Quand vous en serez à cette étape là, c'est bien, parce que ça voudra dire que ça marche. Mais il faut se rendre compte que, j'en reparlerai aussi, que voilà, à un moment ou à un autre, vous allez vous rendre compte que le code va passer malheureusement entre guillemets, surtout si vous aimez faire du code, devenir une partie peu importante de votre activité. C'est bien si ça en arrive là. C'est couillon quand vous êtes un dév', mais c'est bien parce que ça veut dire que votre logiciel vit pour de vrai.

Slide « Choix de la licence ? »

Alors, le choix de la licence, voilà, donc c'est une question importante, ça va impacter, donc… j'ai mis les slides à l'envers mais c'est pas grave……, Ça va impacter vraiment tout ce qui est business model. Si on part sur de l'AGPL, on sait que pour des intégrateurs, typiquement, ils vont être potentiellement refroidis, c'est pas grave car les intégrateurs refroidis par l'AGPL sont toujours de mauvais intégrateurs donc c'est justement pour nous une barrière. Donc, on va prendre l'AGPL, comme ça on aura peut-être moins d'intégrateurs, mais ce seront des intégrateurs avec qui on a envie de travailler. Donc, c'est un choix en creux, on va dire, mais voilà, il faut se rendre compte qu'à ce niveau là, on prend un risque. Ça pourra être une barrière ou pas pour la création d'une communauté, là typiquement, à un moment donné on a des trolls qui reviennent récurrents : « ho, t'as pris l'AGPL, donc c'est pas bien car nous on aime plus la BSD donc on viendra pas t'aider », donc y a des choses comme ça qu'il faut prendre en compte, faut y réfléchir.

Typiquement, c'est comme, je ne sais pas si j'en ai parlé, le nom. Bêtement, il y a un meme à un moment qui passait à base de « On a un nom, ho bah, c'est bon, on a fini le projet ». C'est pas ça, mais voilà, le nom va être important après parce que du nom va découler une grande partie de tout ce qui va être fait en market et en com. Le nom va faire qu'on se rappelle ou pas de votre logiciel, le nom va faire que vous allez pouvoir faire des choses ou pas, sur de la communication, sur le site Web. Typiquement, nous, on a choisi Crème bêtement, pourquoi ? Parce qu'on voulait un jeu de mot avec CRM. On s'est dit que ça sera rigolo à dire à chaque fois qu'on nous demandera pourquoi on l'a appelé comme ça, on pourra dire aux gens que c'est un jeu de mot avec les trois lettres CRM. Et effectivement, Crème, c'est CRM avec un e au milieu et un e à la fin. C'était la raison de base. En fait, à un moment ou un autre, on a pris un grand tableau, on a fait un brainstorming à lister tous les mots avec CRM, donc on s'est retrouvé avec cérumen par exemple, donc on s'est dit « ça c'est pas bien », on a cherché et Crème nous semblait parfait, donc on a un logo qui est un bol de crème, etc, on est pas allé plus loin.

La première fois qu'on a voulu faire un salon pro, on s'est dit « on est tout petit, on est une boite de Marseille, on va sur un salon parisien, on a pas beaucoup de sous, donc on va prendre un stand de quatre mètres carrés, on va avoir en face SAP qui va avoir un stand de trente cinq mètres carrés, comment on fait pour se démarquer, pour que les gens se rappellent de nous ? ». Bien, on s'est dit « Si on utilisait notre nom ? ». Donc Crème, ce qu'on va faire, c'est qu'on va prendre des grands tabliers de vendeurs de glace et on offrira de la crème glacée sur le salon. C'est ce que l'on fait sur tous les salons. Tous les exposants, tous les gens qui organisent des salons, quand on est venus sur un salon pro, ils se rappellent de nous d'année en année. On fait un salon tous les ans à Paris, on a fait plusieurs fois dans toute la France, tous les visiteurs se rappellent de nous comme les gens qui font un CRM et qui offrent des glaces. Alors, effectivement, on a pas trouvé le nom, je pourrai dire « on a super bien réfléchi dès le départ, on a trouvé le nom pour faire en sorte d'avoir une idée », on l'a trouvé après juste parce que c'est par hasard. C'est pour dire à quel point le nom va être important. Le nom va potentiellement définir toute votre démarche marketing, donc va définir si ça marche ou pas. Notre CRM, on l'aurait appelé Puedespieds, on aurait pas eu… ça aurait été un peu plus compliqué. Voilà, donc le nom est important, le choix de la licence est importante.

Slide « Les business models d'un éditeur? »

Comment est-ce que vous allez avoir des sous? Donc, je ne vais pas être très précis, si vous avez des questions là-dessus, si vous voulez qu'on en discute pendant la deuxième phase, on le fera. Il y a deux grandes catégories pour moi, et c'est juste parce que, assez souvent quand je parle avec des petits éditeurs de logiciels libres, ils ont des idées qui à mon avis ne sont pas complètement vraies. Donc il y a, pour ceux qui se rappelle d'un film qui s'appelle Beetlejuice, ou d'un autre film avec un tueur qu'il fallait appeler trois fois devant un miroir, voilà, mais ce n'est pas parce que vous vous dites« je suis éditeur, je suis éditeur, je suis éditeur », que vous allez tout de suite avoir le business model d'un éditeur, existant, qui a des intégrateurs, qui fonctionne, etc. Le business model d'un éditeur, classique entre guillemets, c'est se dire je suis éditeur, je m'occupe de ma version TRUNK, tranquille, je fais ma vision, j'ai des intégrateurs qui tous les ans vont me payer parce qu'on a un contrat de partenariat, parce que je les forme, vont me payer parce que je leur mets un label« intégrateur validé »de ce logiciel, vont me payer parce qu'ils ne vont pas avoir envie de se former en interne d'une manière suffisamment importante sur des points très précis de développement précis, faire des petites missions donc, où ils vont avoir des demandes trop compliquées des clients, ils vont me ramener du boulot parce qu'ils ne sont pas capables de le faire et que cela les arrange de ne pas le faire donc ils vont le ramener chez moi. Ça, effectivement, ça marche bien, ça marche pour plein d'éditeurs de logiciels libres. Typiquement OpenBravo fonctionne comme ça, OpenBravo qui est un éditeur espagnol d'un ERP qui s'appelle OpenBravo, ils ont un fonctionnement un petit peu comme ça. Ils vous prêtent des ingé contre sous pour des problèmes précis, ils vous labellisent en vous formant, en disant« ben voilà eux ce sont les intégrateurs labellisés sur cette région géographique là, donc allez avec eux, vous aurez du bon boulot et en échange vous, vous leur faites un chèque annuel », ils fonctionnent comme ça parce que c'est quelqu'un de reconnu, c'est un logiciel reconnu, ça marche.

Quand vous en êtes à votre version bêta 0.1, vous n'avez pas d'intégrateur, vous ne pouvez pas fonctionner comme ça. Donc, ça c'est le rêve. Peut-être que vous n'aurez pas envie de faire ça, mais logiquement, c'est la finalité classique d'un éditeur. Avant de faire ça, il faut faire autre chose, car ça demande une base d'utilisateurs, ça demande d'avoir une base d'intégrateurs, ça demande d'avoir un produit mature. Et effectivement, quand vous commencez, vous avez juste un« int main(void) », et ça ne suffit pas un« int main(void) »pour convaincre des gens. Donc, ce business model là, il est bien, mais il n'est pas possible, quasiment pas possible.

Il y a quelques contre-exemples, oui dans le cas où effectivement, dans le cas où vous avez un logiciel qui est totalement financé dès le départ par l'utilisateur, dans le cas où vous savez que, votre logiciel, y a des utilisateurs qui se mutualisent, qui disent« voilà, on vous donne un gros chèque, développez le logiciel, et puis on vous donnera des chèques pour que vous développiez les évolutions ». Ça existe, il y a des cas comme ça, mais êtes-vous vraiment éditeurs dans ce cas là, est-ce vraiment de l'édition logiciel. Les gens qui le font vont dire que oui, je ne sais pas, je n'ai pas d'avis tranché. Mais effectivement, dans le cas où vous avez un logiciel dont le développement est totalement payé dès le départ par l'utilisateur et que l’utilisateur, en plus, vous dit qu'on va faire en sorte que de toute façon tous les ans vous développiez la suite. Là, oui, vous pouvez travailler comme un vrai éditeur, car oui, vous avez le jackpot, mais ce n'est pas souvent le cas.

Donc, l'autre business model, c'est d'être un éditeur intégrateur. Typiquement, c'est la solution qu'on a choisi pour Creme. Parce que de toute façon, pour nous, c'était la seule solution viable. C'est à dire que nous, on édite et on intègre à côté. Il y a deux visions de cette chose. Il y a les gens qui disent que c'est mieux, j'en fait partie, c'est parce que c'est bien, on est éditeur d'un côté, intégrateur de l'autre, donc on est autonome, on fonctionne tout seul. Y a des gens qui disent mais non, c'est une hérésie parce que si tu es intégrateur, le jour où tu auras d'autres intégrateurs, tes autres intégrateurs ne te feront pas confiance parce que tu vas pouvoir aller voler leur marché et en tant qu'éditeur tu vas forcément gagner contre eux, donc ils n'auront jamais confiance en toi donc il ne faut pas faire ça parce que ce n'est pas bien. Peut-être. L'avantage, c'est que vos déploiements N, vos déploiements clients N en tant qu'intégrateur, vont vous servir à financer votre personnel déjà et votre vision N+1 au niveau du TRUNK. Donc, vous êtes vraiment autonome, vous faites en sorte que votre logiciel est utilisé, donc il est connu, donc il y a de plus en plus de gens qui, potentiellement, veulent l'utiliser et donc vous allez atteindre la masse critique dont j'ai parlé tout à l'heure, qui vous permet d'avoir des intégrateurs et qui vous permet potentiellement, si à ce moment là vous en avez encore envie, de redevenir, de devenir un éditeur pur.

Donc, là du coup, qu'est-ce qu'on vend ? C'est du business model classique, SSLL entre guillemets, sauf que le seul service que vous produisez, c'est le service qui est autour de votre logiciel à vous, donc c'est du service, c'est de la formation, c'est du déploiement, c'est du déploiement spécifique, etc. Il y a une difficulté, une difficulté à laquelle nous on est en face tous les jours, c'est que du coup on se retrouve avec entre guillemets deux branches de son entreprise. Y a la partie de l'équipe de dév, qui fait la partie TRUNK et y a la partie de l'équipe de dév qui fait le client. Du coup, on se retrouve avec deux équipes qui sont souvent constituées par les mêmes personnes qui changent un jour l'un, un jour l'autre, mais qui ont des besoins totalement orthogonaux. Parce que sur le TRUNK il faut avoir du temps pour faire des choses biens, pour faire des choses au long terme sur une vision précise, alors que les clients veulent des trucs qui cassent la vision du logiciel qu'on veut, mais ils les veulent tout de suite et puis ils donnent des sous pour les avoir. À ce niveau là, il faut se dire, j'ai deux objectifs au final, j'ai mon objectif d'intégrateur, j'ai mon objectif d'éditeur, il se trouve qu'ils sont assez souvent divergents. L'avantage, c'est qu'au moins, comme c'est la même entreprise, les mêmes personnes, qu'on se voit tous les jours, c'est plus facile d'arbitrer. Mais voilà, arrivé à un moment, y a le vote. Et nous typiquement, il est arrivé que sur des coups de bourre, on dise que la release TRUNK prévue en avril sera en juin, parce qu'on a pas le temps. Donc, tant pis, on fige le TRUNK, on livre nos clients et aura deux mois de retard sur le TRUNK, ce n'est pas trop grave, de toute façon, personne n'attend le TRUNK. Mais à un moment ou un autre, y aura cette problématique là, de dire, lequel on avantage? Et la gestion des intégrateurs est effectivement potentiellement plus délicate car là, c'est vrai, que le jour où vous commencez à avoir des vrais intégrateurs, ils peuvent avoir peur que vous veniez leur voler leurs clients. Puisque vous êtes aussi intégrateur, donc au final, vous êtes à demi concurrent avec eux. C'est un vrai problème.

Slide « Communautaire VS Enterprise »

Juste, je ne veux pas troller, mais c'est juste qu'il y a pas mal d'éditeurs qui font deux versions, la version communautaire et la version enterprise. Avec une version communautaire qui est totalement sabordée et une version enterprise qui est totalement presque plus libre, avec de temps en temps, un concurrent éditeur de CRM donc que je ne citerai pas fait des choses comme ça, une licence très restrictive pour les intégrateurs qui ne voudraient pas passer par la version enterprise et qui voudraient juste faire de l'intégration sur la version communautaire, donc des choses intéressantes du style: «Vous n'avez pas le droit de citer le logiciel ou de mettre le logo sur votre site. On vous l'interdit». Voilà des trucs sympathiques comme ça.

Personnellement, j'aime pas. Personnellement, je trouve que c'est très très limite d'avoir une version libre qu'on a complètement sabrée, qui est presque inutilisable et qui est juste là comme produit d'appel, je trouve que ce n'est pas très très propre qu'on utilise juste le libre comme un freeware, pour un freeware d'une partie qui serait shareware. Donc, je trouve que ce n'est pas bien. Nous, c'est pour ça que nous n'avons qu'une seule version, TRUNK. Creme, c'est AGPL, y a qu'une seule version et une seule où y a tout ou y a rien. Je sais que y a des éditeurs de logiciel libre qui ont envie de faire ça. Moi, je vous le déconseille parce que je trouve que ce n'est pas... Mais après, effectivement, quand vous avez une entreprise avec vingt cinq salariés et qui vous disent« on a peur que... C'est plus simple... », chacun fait ce qu'il veut mais voilà.

Slide « ÉVANGELISEZ ! »

Quelque chose d'important! Tout à l'heure j'aurai le même slide au même endroit: l'évangélisation. Alors, c'est assez rigolo, parce que des fois, quand je parle avec des gens:« Ouais, c'est bon, les gens maintenant savent ce qu'est le logiciel libre, on a plus besoin de dire ce que c'est, on a plus besoin d'expliquer pourquoi c'est bien ». C'est juste pas vrai.

Si vous voulez avoir des clients, il y a une chose à faire, il y aura deux choses à faire: la première, c'est d’évangéliser sur le logiciel libre, sur pourquoi est-ce que vous êtes crédible en tant qu'éditeur logiciel libre, pourquoi est-ce que vous êtes autant crédible que un Microsoft, qu'un SAP, qu'un SAGE, ou n'importe quel éditeur proprio, pourquoi est-ce que votre logiciel bien qu'il soit libre est autant crédible. Ça, ça sera la première des choses à évangéliser. Il va falloir que vous évangélisiez sur le logiciel libre et en plus il va falloir que vous fassiez exactement comme tous vos concurrents, que vous évangélisiez sur votre logiciel. Donc, tout à la fin de la présentation, j'ai re-exactement le même slide pour redire évangélisez parce que voilà, il faut bien s'en rendre compte, il faudra évangéliser sur le logiciel libre mais aussi évangéliser sur le fait que votre logiciel, il est bien.

Pourquoi il est bien, pourquoi est-ce qu'il est bien, pourquoi il faut absolument que vos futurs clients l'utilisent, pourquoi est-ce qu'il est mieux que tous vos autres concurrents, même si ce n'est pas tout à fait exactement vrai. À ce moment là, on est sur du commercial mais il faut leur expliquer qu'il est au moins aussi bien, et que s'il est aussi bien, il vaut mieux prendre le votre que les autres. Ça, vous devrez le faire. Le jour où vous serez éditeur, où vous voudrez vraiment vivre de votre logiciel, il faudra accepter de se déguiser en quelqu'un qui va vendre le logiciel, qui va expliquer que votre logiciel, c'est le mieux du monde, même s'il est aussi bien que tous les autres, il faudra que vous expliquiez qu'il est mieux, même s'il est aussi bien.

Et ce n'est pas forcément sale.

Donc, il faudra introduire l'intérêt du logiciel libre, et il faudra expliquer que tout n'est pas gratuit.

Ha, alors, ça c'est quelque chose que moi, en tant que personne qui vais vendre du libre, on m'a souvent renvoyé en face, en me disant :« Oui, nan, mais les gens du libre vous êtes un peu des filous parce que c'est pas tout gratuit ». Nan, ce n'est pas tout gratuit. Alors, expliquez le: non, tout n'est pas gratuit, oui il y a des coûts en plus. Ne faites pas comme vos concurrents du propriétaire, je le dis parce que c'est souvent eux qui le font, qui pratiquent la politique des coûts cachés implicites. C'est à dire qu'ils font un beau devis où c'est pas trop cher et puis en fait il y a plein de petites étoiles qu'on ne lit jamais qui disent« Nan, mais ça c'est pas prévu, ça c'est pas prévu, ... ». Voilà, les coûts cachés, ils existent, on le sait tous, ils existent qu'on fasse du libre ou du propriétaire, c'est la même chose. Soyez honnête, dites le.

Expliquez que non, tout n'est pas gratuit, expliquez que ce n'est pas parce que la licence vous permet d'avoir le code source, ce n'est pas parce que vous pouvez le télécharger sur la forge, etc. Bah, non, il y a des coûts, oui ça va coûter de l'argent, oui ça va demander qu'on me fasse des chèques. Soyez clairs, l'argument du prix n'est pas forcément le meilleur des arguments, c'est un argument comme un autre, d'accord, surtout dans la période où l'on est, ce n'est pas le seul, ce n'est pas forcément le meilleur et à mon sens d'expérience, pour la pérennité d'une entreprise qui fait du logiciel libre, il ne faut surtout pas se baser tout sur le« on est moins cher ». Parce qu'en plus, ça ne veut rien dire. Nous, on a eu des cas clients où on était plus cher que des gens en face avec un logiciel propriétaire. Pourtant, les clients nous ont choisis nous. Parce que on leur a expliqué pourquoi on était plus cher, parce qu'il y avait beaucoup de spécifiques qui n'étaient pas faisables avec le propriétaire, etc. Il y a des raisons pour lesquelles on peut être plus cher et ça peut être un argument de vente. Je suis plus cher, oui, mais pour ça. Donc, faut bien expliquer, c'est vraiment pas tout est gratuit, mais faut bien expliquer et ça passe.

Slide « Communautés? »

Donc, il y deux types de communautés pour moi: il y a la communauté des utilisateurs et il va y avoir la communauté des contributeurs.

Elles se forment l'une après l'autre. La communauté des utilisateurs c'est celle qui va se former en premier, la plupart du temps, si on part sur du logiciel un peu classique. Elle sera ultra consommatrice en temps. Dès qu'elle va commencer, dès que vous allez commencer à avoir des gens qui utilisent votre logiciel et qui l'utilisent de manière gratuite, juste ils ont téléchargé, ils ont installés, ils ont testés, que ce soit du site Web, que ce soit un truc avec un« .exe »parce que vous faites du libre sous Windows, ou que ce soit un tar gz qu'ils ont décompressé et qu'ils ont installé. Elle est super consommatrice en temps mais elle est ultra importante. Et pour qu'elle se forme, il faudra que vous lui donniez les outils. Donc, il faudra qu'il y ait un forum, faudra qu'il y ait des mailing listes, faudra peut-être même qu'il y ait une page Facebook ... Hou, le mal au secours. Mais c'est important parce que même si elle ne vous apporte rien en terme de business, parce que ce n'est pas l'utilisateur gratuit qui va utiliser votre logiciel, même si c'est une société, nous, on a des utilisateurs de Creme, qui utilisent Creme depuis la première version, qui nous ont coûté des dizaines d'heures, entre guillemets, sur le forum, en envoyant des mails, en téléphonant au bureau alors que le numéro de téléphone n'est pas forcément sur le site de Creme, mais en allant sur le site d'Hybird pour téléphoner en disant« On a essayé de l'installer, mais ça ne marche pas, aidez nous ». Bah oui, mais heu...,« Mais non, s'il vous plait ». Donc nous, comme on était jeunes et puis comme on aime bien aider les premiers utilisateurs, on a passé du temps au téléphone. Alors à quoi ça sert s'ils ne vous rapporteront jamais d'argent? C'est juste que ça vous amène une pérennité, ça fait des gens derrière qui vont dire« Bah, on a utilisé ce logiciel, il n'est pas trop mal », ça fait du buzz entre guillemets, ça fait du marketing indirect que vous n'aurez pas à faire et qui fait que potentiellement votre logiciel il va être connu et ça va permettre à la communauté de contributeurs de se former peut-être.

Donc, là, c'est pareil, faut pas dire trois fois leur nom pour qu'ils apparaissent. Vous pourrez très bien avoir très peu de contributeurs, voir quasiment pas. Des copains qui sont éditeurs sur Marseille qui n'ont quasiment aucun contributeur, ils doivent avoir cinq ou six contributeurs. Leur logiciel marche bien, ils ont des utilisateurs, ils ont des clients, etc, mais ça intéresse juste personne de contribuer. Donc, ça ne veut pas dire que leur logiciel est... ça veut juste dire que leur logiciel, c'est une niche et qu'il y a peu de gens qui ont envie de prendre du temps pour développer. Tant pis, ce n'est pas grave. Tant que, de toute façon, vous ne basez pas votre business model sur le fait que ce sont d'autres personnes que vous qui vont faire votre code, il n'y a pas de problème.

Slide « Communauté de contributeurs »

Alors, là, c'est pareil, mais par contre, les contributeurs, il y a plein de choses qu'il faut faire, de toute façon des choses que normalement vous devriez faire de base, mais si vous ne le faites pas, vous n'aurez jamais personne pour vous aider. Faut coder proprement et pas trop mal. Faut avoir une doc à jour. Le manuel du contributeur, c'est carrément super important, et leur expliquer comment est-ce qu'ils peuvent vous donner les contributions, qu'est-ce qu'ils vont devoir faire. Un bug tracker utilisable et utilisé par vous, qu'il n'y ait pas que les contributeurs qui donc... Un bug tracker qui soit vraiment le bug tracker qui est utilisé. Et on utilise au boulot Bucket ou Git, donc on a l'habitude de tout ce qui est« pull request »mais voilà, permettre au gens, facilement, que ce soit par patch, que ce soit sur Git ou sur Bit Bucket, qu'ils n'aient juste à faire un fork, à faire une fourchette mais que le mécanisme de« je vous donne mon code »soit facile, qu'il n'y ait pas besoin d'envoyer les patchs à la main, qu'il y ait un mécanisme qui soit facile, qui soit clair, qui soit transparent.

Typiquement, un projet que j'aime, un petit projet sur lequel j'ai contribué un peu, dans un domaine complètement différent, c'est circus, c'est un petit projet de remplacement de quelque chose qui fait la même chose que Superviseur, qui vérifie que vos processus tournent, qui est fait par la fondation Mozilla. Ils ont typiquement dans leur site de doc, ils ont un site de doc très très à jour, et la dernière partie, c'est le manuel du contributeur, ils expliquent comment faire, il faut que vous forkiez sur Git, il faut que vous fassiez une branche, que vous codiez, que vous respectiez tels trucs, etc, parce que c'est du Python, et après vous faites une« pull request »sur leur branche et ils acceptent ou pas s'ils veulent. Voilà, tout est clair, tout est précis, c'est super facile. Si vous voulez avoir des contributeurs à vous, faut faire la même chose.

Et surtout, ce qui est important, c'est qu'il faut apprendre à dire NON. Il faut que vous appreniez à dire NON tout le temps. Cela ne veut pas dire être élitiste, c'est à dire que nous, crème est fait en DJango, pour avoir des contrib qui soient acceptées dans le cœur de Django, c'est super difficile parce qu'ils ont des pré requis de vision du logiciel, des pré requis de qualité, de beauté du code qui sont ultra précis. Il faut que tout soit testé, que tout le code soit bien écrit, il faut que ce soit Pythonique, vous allez peut-être devoir ré écrire votre patch dix fois pour qu'il rentre. C'est tant mieux, ça veut dire qu'au final Django est super qualitatif.

Donc, vous avez le droit de faire la même chose, vous avez le droit dire« Non, ça, je ne veux pas, ça je n'ai pas envie, cette fonctionnalité, je trouve qu'elle ne va pas dans mon logiciel. Bah, si tu veux la mettre dans mon logiciel, tu forkes et tu le fais à côté ». Mais il faut que vous disiez non, parce que sinon après ça devient une machine à café qui fait tout le reste et sandwich, ça ne va pas. Pareil, les utilisateurs qui vont vous dire sur le forum« ha, c'est super bien ton logiciel mais tu pourrais pas faire ça? ». Bah non. C'est important. Avec les communauté, vous allez perdre plein de temps. Alors, il ne faut pas en perdre plus que nécessaire parce que c'est utile, mais faut surtout apprendre à, voilà, à dire non.

J'essaye d'aller vite car il me reste que cinq minutes.

Slide « Relation entre éditeurs et intégrateurs »

Relation entre éditeurs et intégrateurs. Alors, c'est bien, logiquement, c'est censé vous faire gagner plus. Une relation qui marche bien, c'est du gagnant/gagnant. C'est à dire que vos intégrateurs, il ne faut pas les voir comme des gens qui vous prennent vos clients, parce qu'ils vont vous donner une force de frappe marketing, une force de frappe commerciale plus importante, que vous n'auriez pas eu, puisque vous n'auriez pas embauché tous les commerciaux qu'ont vos intégrateurs.

Potentiellement, si vous mettez en place des contrats de partenariat avec des labellisations d'intégrateurs, chose que je vous conseille de faire, vous allez avoir des sous qui rentreront de toute façon et de façon annuelle. C'est toujours bien des sous qui rentrent de façon récurrentes et sur lesquels on peut être sûr. Et ce sont des contrats que vous n'auriez jamais signés, parce que potentiellement, vous êtes basés à Genève, vous êtes quatre, et aller faire un contrat en Espagne à cinq mille euros, vous n'allez pas le faire. Parce que rien qu'aller vous déplacer pour faire la formation, ça vous coûte plus que... Voilà, il y a plein de raisons pour lesquelles les contrats que vos intégrateurs vont faire, vous ne les auriez jamais fait, donc ce n'est pas de l'argent perdu, de toute façon, vous n'y seriez jamais allé. Il faut le voir comme du« C'est bien pour tout le monde, et c'est surtout bien pour votre logiciel »parce que de toute façon, plus il est utilisé, plus vous avez de chance que les gens veuillent l'utiliser donc plus vous, vous allez avoir du revenu.

Alors, effectivement, il y a un respect mutuel. Il faut aussi voir qu'un éditeur ne peut pas vivre de manière, en tout cas ne peut pas grossir et vivre de manière pérenne sans avoir quelques intégrateurs à un moment ou un autre. La position d'éditeur intégrateur qui fait tout tout seul, à part si on veut rester petit, etc, mais ça c'est rester le cul entre deux chaises, c'est un peu compliqué à géré. Voilà, vous avez de grands pouvoirs, ça vous donne de grandes responsabilité, donc il faut... À chaque fois, je me débrouille pour... Donc, voilà, il ne faut pas les pressurer vos intégrateurs, il ne faut pas aller sur leurs plate bandes, il ne faut pas effectivement leur voler des clients. Ils ont un gros contrats où vous pourriez aller parce que c'est à trois cent kilomètres de chez vous, ils en sont à la phase finale, non, ça ne se fait pas d'y aller et de le voler. Voilà, à ce niveau là, il faut que eux vous respectent et que vous les respectiez et ça se passe plutôt bien.

Comment est-ce qu'on gère les tricheurs? Comment est-ce qu'on gère les intégrateurs qui sont des mauvais intégrateurs, qui vont prendre le code, qui vont faire des développements spécifiques, qui ne vont jamais dire à leurs clients que c'est du libre, qui ne vont jamais rien vous reverser? Je ne sais pas. J'en suis venu au point, moi, à me demander s'il faut les gérer, en fait, est-ce que ce n'est pas juste une perte de temps que d'essayer de taper les gens qui de toute façon n'ont pas envie d'être honnêtes? Je ne sais pas. C'est une vraie question que je me pose, est-ce qu'il faut ou pas les gérer? Est-ce qu'il faut se dire bah tant pis, c'est le petit pourcentage de gens qui font que... Le problème, c'est que s'il y en a trop, ça devient... Mais voilà, ça c'est une vraie question, je ne sais pas encore.

Slide « La recette magique pour réussir? »

La recette magique. On a presque fini, rapidement.

Donc voilà, le code, ça ne suffit pas. Vous allez vous rendre compte que le meilleur logiciel du monde, si personne ne l'utilise, il est juste mort. C'est bête, surtout si vous êtes une entreprise, vous avez dépensé plein d'argent, vous avez des salariés et si personne n'utilise votre logiciel... Donc, le code c'est super bien, le code c'est primordial, il faut que vous ayez un code qui fonctionne, qui n'ait pas de bug, qu'il y est des tests, il faut qu'il y ait une couverture de tests, que tout marche bien, c'est le pré requis minimal à n'importe quel développement logiciel, on est d'accord. Mais ça ne suffit pas.

Il y a, donc le nom, il s'en rappeler. Et le fait d'être clair, d'être transparent. Donc, toutes les relations que vous allez avoir avec vos intégrateurs, avec vos clients, avec vos prospects, avec vos partenaires, il faut être clair, il faut être transparent, il faut leur expliquer les choses, alors il faut évangéliser mais il ne faut rien cacher, voilà. Il faut évangéliser, il faut leur expliquer les choses clairement, qu'ils comprennent, faut pas cacher.

Deux autres choses aussi, voilà, faire des releases rapides, ça c'est pareil, c'est un projet tips classique mais ça marche aussi quand vous êtes éditeur. Il faut, à un moment ou un autre, surtout que vous allez avoir des concurrents, des vrais concurrents, qui vont à un moment ou à un autre, sans arrêt vouloir avoir un logiciel mieux que le votre, surtout si votre logiciel marche bien, vous allez arriver sur une vraie démarche concurrentielle, un vrai marché vraiment concurrentiel, avec des gens qui vont absolument vouloir dire que leur logiciel est mieux que le votre même si ce n'est pas vrai, et vous vous vouloir dire la même chose. Donc, faire des releases rapides, faire des releases souvent. Avoir des nouvelles fonctionnalités qui arrivent de temps en temps, même si elles ne servent pas forcément à grand chose. Typiquement, sur OpenERP 6, si il y a des gens qui connaissent un peu, il y a la notion de la carte avec Google, si je ne me trompe pas c'est sur la 6, donc voilà, c'est un truc qui est super rigolo, mais moi, quand j'ai parlé avec plein de gens, qui étaient utilisateurs d'OpenERP:« Ouais, trop bien, y a la carte avec Google qui va nous afficher nos clients... ». Ok, trop bien, mais voilà, c'est un ERP donc on n'a pas forcément l'idée de se dire que c'est super important que d'avoir les clients en Google. Mais pour les gens que je connaissais, c'était juste trop bien. Ils allaient pouvoir voir leurs client sous Google maps. Donc, c'est important de se dire qu'on va faire des releases souvent et on va faire des releases avec des features qui sont sympathiques pour les gens, les vrais utilisateurs. Même si nous, en tant que développeurs, on se dit :« Pouah, une carte Google, pfff, ça ne sert à rien, ce n'est pas rigolo, ce n'est pas compliqué au niveau algorithmique, etc ». Voilà, faut se mettre au niveau de l'utilisateur, penser à ce qu'ils ont envie, il faut leur donner des choses qui vont les faire rêver un minimum.

Faut se remettre en question. Et à mon avis, nous, nous c'est notre trip au boulot, c'est de réussir en étant des vrais gentils. Voilà, faut rester un gentil. Et c'est vachement bien quand on est sur des appels d'offre avec en face des boites qu'on sait qu'elles ne sont pas forcément très très propres, et nous de se dire on est assez propre, on est gentils et puis on gagne. Mais c'est encore plus motivant.

J'ai fini. Merci de m'avoir écouté. Et puis si vous avez des questions, c'est avec plaisir.

Auditoire: clap, clap, clap...

Question n°1 : Quand on est éditeur intégrateur et qu'on répond à un appel d'offre, on a pas le droit de croiser avec un intégrateur qui répond lui aussi à l'appel d'offre ?

Jean Michel Armand : Donc, il faut faire ça proprement. Alors, nous, on a pas encore ce problème là, on est éditeur intégrateur et on a pas encore d'intégrateurs, donc c'est facile, on répond tout seul. J'ai déjà discuté avec des gens qui sont des éditeurs qui ont déjà des intégrateurs, certains s'interdisent de répondre sur les appels d'offre géographiquement zonés, là où sont leurs intégrateurs. D'autres le font en ayant prévenu en aval leurs intégrateurs. Voilà, je pense que les deux solutions... La solution la plus simple, c'est de s'interdire de le faire. Après, ce n'est pas forcément au niveau business, on a peut-être pas l'opportunité de le faire. Dans ce cas là, soit prévenir en aval, soit faire une réponse commune. Voilà, vous y allez, on fait un partenariat ensemble, et puis on le fait ensemble. Il y a trois solutions propres de le faire.

Question n°2 : Si on veut parler tarification, y a la solution d'un système de module ?

Jean Michel Armand : Alors, nous, c'est ultra modulaire. Pour l'instant, sur Creme, tous les modules sont AGPL et c'est facile. Django est de toutes façons fait en sorte qu'on puisse tout découper en App et qu'on puisse très facilement ou ajouter une App. On s'est pas encore posé la question. Pour nous, tous nos modules sont AGPL. On a développé certains modules pour des clients qui ont décidé de le garder, qui sont AGPL, mais de ne pas nous le remettre dans le TRUNK. C'est eux qui décident, ils l'ont payé en entier, on leur dit:« Bah, ok, c'est de l'AGPL, vous en faites ce que vous voulez », alors ils le gardent, le code est disponible chez eux, mais ce n'est pas très utile pour eux. Mais nous, on a un parti pris, tous les modules qu'on fera seront AGPL. On a une petite spécificité, c'est qu'on a certains modules qu'on ne libère que quand ils ont été... En fait, on fait de la mutualisation en avance, c'est à dire qu'on a certain module, on va le développer, on va essayer de trouver quatre clients qui vont nous payer le développement. On le développe dès qu'on trouve le premier, donc le premier peut l'utiliser, le second, troisième et quatrième aussi, mais il ne sera mis dans le TRUNK que quand il aura totalement été payé sur quatre. Voilà, donc, on fait des choses un peu comme ça, mais sinon tout est AGPL sur nos modules.

Question n°3 : N'y a-t-il pas moyen de forcer l'intégrateur qu'il le conduise aussi à mettre une licence AGPL ?

Jean Michel Armand : Le jour où les intégrateurs le feront, si ce sont des intégrateurs propres, légalement, ils seront obligés.

Question n°4 : C'est à dire qu'en fait, vous ne libérez le code de vos produits qu'à partir du moment où ils ont été financés ?

Jean Michel Armand : Nan. Que sur certains petites modules très spécifiques dont nous on ne voit pas l'utilité forcément dans TRUNK, mais qu'un client nous demande, et on lui dit« Bah voilà, si tu veux que ce soit un peu moins cher, on se débrouille comme ça ». Ce n'est que sur des modules très spécifiques, honnêtement. La contre partie, c'est qu'on ne le libère que quand on a trouvé les autres mutualisant. Aujourd'hui, on a une douzaine de modules fonctionnels dans CREME, on l'a fait sur un module et demi. Donc c'est vraiment tout petit. Mais, ça permet à un moment ou à un autre de faire du développement TRUNK qu'on estime pas vital et qui ne rentre pas complètement dans la vision du machin, mais de l'offrir à plus de gens au cas où il y a plus de gens qui trouve ça intéressant. Mais ça arrive très peu souvent.