On imagine que pour le reste, l'open source est affaire de bénévoles, travaillant soirs et week-ends sur des projets communautaires, pour la gloire ou pour le bien de l'humanité.

Et on oublie bien souvent le troisième modèle de l'open source, celui qu'on pourrait appeler "coopératif", ou encore "mutualiste". Il a pourtant une importance extraordinaire, puisqu'on y trouve Linux soi-même, les projets de la fondation Apache ou de la fondation Eclipse. Du beau monde...

De quoi vivent ces projets ? Principalement de dons en nature, soit de code source directement, soit de temps de développeurs, payés par leur employeur, et travaillant sur les projets de la fondation. Pourquoi les entreprises font-elles ces contributions ? Pour l'essentiel, ce n'est pas affaire de marketing, il ne s'agit pas d'avoir son nom sur le spi d'un voilier géant. Elles sont au contraire relativement discrètes sur leur implication. Ce n'est certainement pas non plus par philanthropie ou dans une logique de mécénat. Leurs motivations sont de différentes natures. Participer à la gouvernance des projets, c'est à dire avoir son mot à dire dans les orientations qui sont prises, pour les diriger dans le sens de ses besoins. Construire une expertise interne sur ces projets, qui permettra de bien les intégrer à ses propres développements. Acquérir une légitimité sur le marché. Mais surtout, au final: disposer pour soi même d'un outil de qualité en partageant les coûts.

Il est très instructif de regarder la liste des plus grands contributeurs du noyau Linux.

Sony, Nokia, Samsung, Volkswagen, sont au nombre des contributeurs actifs. Pourquoi Volkswagen payerait ses salariés à améliorer le noyau Linux ?

Pour ces entreprises, Linux fonctionne sur une logique de coopérative agricole, une logique de mutualisation des moyens donc de division des coûts. Une variante de ce qu'on appelle parfois « coopétition », c'est à dire que l'intérêt bien réfléchi de chacun conduit à identifier un terrain de coopération dans un contexte général de compétition.

Créer seul un système d'exploitation solide et complet serait hors de portée, même pour un grand constructeur automobile. Utiliser un système propriétaire serait trop coûteux et pas toujours adapté à ses besoins spécifiques. Reste la mutualisation: chacun "met au pot" quelques développeurs, et ensemble ils disposent d'un OS de qualité exceptionnelle, sur lequel ils ont une certaine maîtrise. Bien sûr, cela signifie qu'aucun d'entre eux ne dispose d'un OS meilleur que celui de son concurrent: cet aspect là de la concurrence a été pratiquement neutralisé. Mais il leur reste encore bien assez de domaines dans lesquels ils peuvent porter le combat, être meilleur, écraser les concurrents. Au global, ce domaine de coopération apporte bien sûr de moindres coûts à chacun, et donc une meilleure compétitivité.

On retrouve cette logique coopérative sur la plupart des projets de fondations. Le moteur de recherche Lucene en est un bel exemple. Depuis 2002, Yahoo a été un important sponsor des travaux de son créateur, Doug Cutting, qui a ensuite été salarié de Yahoo, de 2006 à 2008, tout en continuant ses travaux sur ce projet de la fondation Apache. En 2006, le groupe de média CNET donne à la fondation Apache le source de SolR, un outil de recherche initialement à usage interne, qui rejoint le projet Lucene. Et Yahoo continuera de financer les projets qui gravitent autour de Lucene, en particulier Hadoop, devenu l'outil de référence pour la répartition de tâches à très grande échelle. On est bien ici dans une logique coopérative: CNET bénéficie de produits très supérieur à ce qu'il aurait pu financer seul, et de même, pour chaque jour financé par Yahoo, le bénéfice est décuplé puisqu'une vingtaine de commiters entourent Doug Cutting, payés par différents employeurs.

C'est un exemple particulièrement intéressant, qui pourrait être pris en modèle dans bien d'autres domaines. Dans un nombre extraordinaire de secteurs, des fédérations interprofessionnelles pourraient définir des terrains de coopération logicielle, stimuler des projets mutualistes...

D'une certaine manière, le modèle économique de l'éditeur logiciel traditionnel peut aussi s'assimiler à un financement coopératif: différents clients de l'éditeur payent un droit d'usage, et/ou un support, et la somme de ces contributions individuelles finance le développement du produit. La différence entre ce modèle éditeur standard et le véritable modèle coopératif est dans la prise de risque et dans le partage des bénéfices. L'éditeur prend des risques en investissant pour construire son produit, bien avant d'avoir des clients. En contrepartie de cette prise de risques, il escompte un profit important si son produit est un succès. Et en particulier, il espère vendre de nombreuses licences aussi cher que le permettra le marché, sans laisser croître ses coûts de développement en proportion. Dans un développement coopératif, les clients partagent le risque, et sont assurés en retour de coûts au plus bas et surtout, de tirer eux-mêmes les bénéfices d'échelle.

Pour autant, l'approche coopérative du développement n'est pas indissociable de l'open source. Dix entreprises peuvent s'associer et co-financer le développement d'une application, qui servira à chacune d'elles. Elles peuvent créer une petite structure pour en gérer les développements et les évolutions. Le domaine des ERP "verticalisés", des applications qui s'appuient sur un socle ERP pour en adapter les fonctionnalités aux besoins d'un secteur d'activité particulier, serait typiquement le domaine de prédilection de cette approche coopérative de l'open source.

En principe, il n'est pas requis que l'application résultant de cet effort coopératif soit open source. Et même, certains pourraient craindre qu'elle le soit, car elle pourrait alors être utile à d'autres qui n'auraient pas contribué à son financement.

L'open source n'accepte pas de frontière, pas de restriction dans la diffusion: si elle est open source, l'application ne pourra pas être réservée à ses seuls sponsors initiaux. Il faut avoir les nerfs solides, pour voir un concurrent non coopératif reprendre l'application sur laquelle on a investi.

Mais dans la pratique, on sait bien qu'il n'est pas si facile de "prendre" une application. Ayant démonétisé le copyright, l'open source a mis la connaissance, l'expertise, la maîtrise, au premier plan. L'entreprise qui n'aura pas participé aux travaux aura, dans la pratique, beaucoup de mal à profiter de l'application sans avoir construit une certaine maîtrise, et sans avoir son mot à dire quant aux orientations. En ne contribuant pas, elle se rendrait dépendante vis à vis de ses propres concurrents, qui seuls assureraient la gouvernance, définirait la roadmap du produit.

C'est pourquoi, pour un groupement d'entreprises dans une logique coopérative, la crainte de voire certains profiter sans avoir contribué, peut passer au second plan. Ce qui prime, c'est la croyance que d'autres au contraire viendront rejoindre les rangs des sponsors, apporter leurs propres idées, des moyens renforcés, des coûts encore divisés, pour viser une application encore meilleure. Bien sûr, il faut une certaine foi, mais quelques belles réussites ont ouvert la voie.