Rencontres Sociales

Regards

Entreprises à sources ouvertes

Appliquer les modèles de gouvernance des communautés de logiciels libres / open-source aux entreprises responsables

17 mai 2011 - Bastien Sibille

Introduction : ce que peuvent nous apprendre les communautés du libre / open-source

Une double tension caractérise notre entrée dans le XXIe siècle : une tension civilisationnelle liée à la crise du capitalisme financier, à la crise des modèles de production et de consommation et à la crise écologique ; une tension techno-économique liée au passage à une économie de l’immatériel qui ouvre de nouveaux débouchés industriels et de nouveaux modes de production s’appuyant fortement sur des technologies collaboratives numériques. Les entreprises qui veulent produire de la richesse de façon responsable sont confrontées à ces tensions et notre avenir dépend de leur capacité à les résoudre positivement.

Dans la réflexion nécessaire sur l’évolution des entreprises responsables et sur les politiques industrielles à mettre en place pour faire face à ces défis × [1], les modèles de production inventés par les communautés du logiciel libre / open-source sont précieux parce qu’ils constituent des innovations « en marche » dont on peut analyser le modus operandi. Que peuvent apprendre nos industries de la part de communautés qui réussissent à faire travailler ensembles des milliers de développeurs et d’utilisateurs de logiciels dispersés de part le monde ? Comment les entreprises responsables peuvent-elles s’enrichir des modèles de gouvernance et des processus de production définis par des communautés qui contribuent à l’écriture, à la maintenance et à l’utilisation de centaines de million de ligne de code informatique (au sens propre) dont la qualité est si grande qu’elles forment une très large part de l’architecture logicielle de l’internet ?

Mais encore : comment certaines communautés du libre parviennent-elles à faire de centaines de millier d’utilisateurs de leurs produits des co-producteurs grâce à des plateformes de rapports des bugs et des évolutions souhaitables ? Comment les communautés du libre sont-elles parvenus à faire du travail sur les logiciels un acte digne, là où le salariat informatique est souvent avilissant ? Comment les communautés du libre parviennent-elles à organiser le travail collectif de milliers de bénévoles et à le transformer en une œuvre collective ?

Ce texte a un double objectif : documenter les modèles de gouvernance des communautés du libre / open-source et décrire comment ceux-ci peuvent bénéficier aux entreprises responsables [2]. J’appelle « entreprises à sources ouvertes » les entreprises enrichies des modèles contributifs développés par les communautés du libre et montre qu’elles se caractérisent par l’ouverture de leur gouvernance, par la transparence de leurs processus et par la création de biens communs. Afin de bien faire comprendre la puissance opérationnelle de ces modèles, je veux commencer par décrire brièvement deux communautés de logiciels libres qui sont tout à fait remarquables : la communauté Debian, qui a produit et maintient les 323 million de lignes de code source d’un système d’exploitation qui est un des plus stables du monde ; la communauté Drupal, qui réunit aujourd’hui 830 000 utilisateurs et plus de 2000 développeurs et a développé un des logiciels d’édition de site internet et d’intranet les plus utilisés du monde.

Gouvernance des communautés du libre / open-source

Deux communautés du libre remarquables : Debian et Drupal

Debian est une figure particulière au sein des systèmes d’exploitation libres [3] : reconnue pour la très grande qualité des logiciels qui le composent, l’intransigeance de sa communauté à l’égard des licences appliquées au logiciels du système et son indépendance à l’égard de toute entreprise, Debian est l’archétype du libre. Aujourd’hui, Debian est probablement utilisée par plus d’un million d’utilisateurs, et ces utilisateurs ne sont pas des utilisateurs amateurs, mais généralement des informaticiens qui opèrent Debian sur des machines assumant des responsabilités importante : Debian est très largement utilisée sur toutes les machines qui demandent une grande stabilité, et notamment les serveurs d’applications sur internet (sites web par exemple).

Le code source de Debian est constitué de plus de 323 million de lignes de code qui sont rassemblées, maintenues et parfois par plus de 3000 volontaires répartis sur toute la planète – une estimation du coût de développement de ces 323 millions de lignes de code via la méthode COCOMO évalue la valeur du développement à plus de 8 milliards de dollars US. La communauté est soutenue par des donation venant d’organisations à but non lucratif, et notamment la « Software in the public interest » [4].

Le projet Debian s’organise autour de deux textes fondamentaux : la Constitution Debian [5] et le Contrat social Debian [6]. Ces deux textes spécifient la gouvernance du projet (nous y reviendrons) et le Contrat social explicite les valeurs essentielles que la communauté doit respecter. La première publication du code source a été faîte par Ian Murdock le 16 août 1993, accompagnée du Manifeste Debian qui décrivait la vision de Murdock d’un système d’exploitation maintenu de façon ouverte, dans l’esprit de Linux et de Gnu. Le projet a lentement évolué en 1994 et 1995 – il était alors financé par la Free Software Foundation. En 1996, Murdock passe la main à Bruce Perens comme responsable du projet. La communauté commence alors à se stabiliser à travers l’écriture du contrat social, très largement débattu sur sa liste de discussion.

Drupal est un système d’édition de sites internet. Il permet la création de blogs personnels, de sites d’entreprises, de partis politiques, de gouvernements tant dans leur partie « grand public » que dans leur partie d’intranet. Aujourd’hui, plusieurs centaines de millier de sites (il est très difficile de faire une estimation exacte du nombre de sites - wikipedia parle de 7,2 millions de sites, mais nous avons également trouvé des chiffres plus près de 300 000) utilisent Drupal pour des usages aussi différents que celui de la Maison Blanche ou celui de la communauté Ubuntu [7].

Drupal est un projet open-source depuis 2001. La première version du code a été publiée par Dries Buytaert puis développée par une communauté de contributeurs libres. La communauté d’utilisateurs compte aujourd’hui 830 000 membres et celle de développeurs plus de 2000 membres. Il faut immédiatement noter qu’utilisateurs et développeurs contribuent de façon égale au développement du système – c’est ce qui, on le verra, fonde la particularité de ce type d’organisation de la production. Cette communauté a produit, en plus du « cœur » du système Drupal, plus de 7 000 modules additionnels correspondants à des besoins bien spécifiques exprimés par la communauté d’utilisateurs. Drupal est aujourd’hui une communauté mondiale qui tient des conférences semi-annuelles alternativement en Europe et aux USA - lors de la conférence de San-Francisco en avril 2010, 3000 personnes avaient fait le déplacement. On compte 20 communautés nationales qui prennent en charge la traduction du cœur et des modules.

Debian et Drupal sont remarquables par leur taille, par la qualité de leur production et par l’exemplarité de leur vie communautaire. Mais elles ne sont que deux communautés libres parmi des centaines d’autres : que peut-on apprendre de la gouvernance de ces communautés ? Comment se structurent-t-elles ? Quels sont les outils qu’elles déploient ?

Modèles de gouvernance des communautés du libre

Par gouvernance des communautés de développement de logiciels libres, je veux désigner :
- les procédures de direction de la communauté - modes de nomination des dirigeants, instances de décision et détail de leur fonctionnement, modalités d’entrée et de sortie dans la communauté ;
- les procédures de développement du code - plan de développement, attribution du droit de commit, modalité de rapport des bugs, modalités d’écriture de la documentation ;
- les procédures d’utilisation du code - droit d’exploitation et de diffusion du code, documentation technique.

Trois grands modèles de gouvernance de communautés du libre sont observables aujourd’hui.

Le modèle « charismatique » dans lequel les communautés sont dirigées par un homme - je ne connais, malheureusement, pas de femme qui exerce cette fonction [8] – qui exerce le rôle de leader à la fois dans les processus de décision et dans la représentation de la communauté vers l’extérieur [9]. Cette personne, qui a généralement fondé la communauté, est à la fois son inspiratrice, son chef et son juge. Il n’y a pas d’élection des dirigeants de la communauté, pas de texte explicitant sa gouvernance, le plan de développement du code est difficilement accessible et le mode d’entrée dans la communauté pour participer au développement du code est à la fois non explicite et arbitraire [10]. Drupal, dont nous mentionnons la qualité un peu plus haut, fait parti de ce type de communautés. Dries Buytaert en est le « founder and lead developper ». Il veille sur le logiciel et ses évolutions. Il est le seul « core committer » permanent et a selon toutes vraisemblances nommé les quatre « branch maintainers » responsable de chacune des précédentes distributions. Il nomme les « maintainers » qui ont la responsabilité d’une portion du code du cœur du logiciel. Il accepte ou refuse, avec l’aide des « branch maintainers » les contributions des « core contributers ». Il faut, pour trouver ces éléments, fouiller avec attention le site internet de Drupal : si les façons de contribuer au code et à la communauté sont assez détaillées, il y manque une page synthétique sur la gouvernance de la communauté [11]. Il faut ajouter que la marque « Drupal » appartient à Dries, ainsi que le nom de domaine drupal.org. [12]

Le modèle dans lequel la hiérarchie est d’ordre capitaliste, au sens où le code est principalement maintenu est développé par une société de capitaux. C’est un modèle dans lequel « le capital décide ». Point besoin de le développer ici : il est à l’œuvre dans toute les entreprises « traditionnelles » et est si présent dans le monde du libre qu’on ne peut pas citer tous les exemples (Red Hat, OpenOffice etc.).

Le modèle dans lequel la hiérarchie est d’ordre « mérito-démocratique ». C’est un modèle dans lequel la communauté se dote d’organes élus de représentation et de décision. Les membres sont invités à participer à la gouvernance de la communauté eu égard à leur contribution au code source. C’est par exemple le cas d’Apache : Apache est une « non-profit organisation » gouvernée par un bureau de 9 directeurs lesquels sont élus pour un an par les membres de l’Apache Software Foundation. Il y a avait en 2007 156 membres de l’ASF, invités au motif de leur importante contribution au code d’Apache et dont l’invitation a été validée par un vote des personnes déjà membres. C’est également le cas de Debian : la communauté Debian est dirigée par un « project leader » qui est élu par les membres de la communauté de développeurs pour un an. L’acceptation d’un membre dans la communauté de développeurs est un processus méritocratique.

Les communautés « mérito-démocratiques » sont nombreuses. Elles représentent selon moi la quintessence de l’innovation organisationnelle que proposent les communautés développant des logiciels libres. Une étude fine de leurs pratiques permet de mettre au jour quelques règles fondamentales [13]. Trois critères essentiels caractérisent la bonne gouvernance de ce type de communauté de développement de logiciels libres : ouverture de la communauté, transparence de la gouvernance et production d’un bien commun.

Ouverture, transparence et production de biens communs dans les communautés du libre

Les communautés mérito-démocratiques ont généralement à leur tête un fondateur qui ouvre leur gouvernance à ceux dont l’investissement y est exemplaire et qui font consensus au sein de la communauté. Les dirigeants qui siègent au Conseil sont donc proposés sur des critères méritocratiques et approuvés par un vote de l’ensemble des membres de la communauté. Le Conseil assume les choix qui concernent la répartition des responsabilités entre les membres ou les équipes, les modalités d’acceptation des nouveaux membres et la communication de la communauté. Les processus d’intégration des nouveaux membres dans la communauté sont eux aussi méritocratiques et peuvent ou non être sanctionnés par un vote. La gouvernance des communautés du libre laissent généralement les membres des communautés très autonomes dans l’organisation de leur implication – la création de nouvelles équipes de travail n’est généralement pas restreinte.

La gouvernance de la communauté reste la plus ouverte possible à l’ensemble de la communauté. Cela implique l’utilisation d’un certain nombre d’outils :
- de transmission à toute la communauté des informations concernant l’état de la communauté ;
- d’écriture collective des règles de production, de la charte d’usage, de la mission de la communauté ;
- de communication permettant aux différentes équipes de travailler ensembles ;
- de sondage de la communauté et de choix collectifs.

Ces outils doivent être simples, adaptés aux besoins de ceux qui travaillent dans la communauté et ouverts. La responsabilité de leur mise en oeuvre et de leur usage effectif revient aux fondateurs puis aux leaders de la communauté.

L’ouverture de la gouvernance de la communauté sert l’objectif général de création d’un sentiment d’appartenance qui est absolument essentiel pour que les personnes qui constituent la communauté s’y investissent. Ici, l’ouverture des procédures de direction est primordiale mais elle n’est pas le seul élément. La capacité à raconter la communauté, à créer un fil narratif qui en fonde le sens est tout à fait capital. Une communauté doit croire dans son histoire pour la défendre et la vivre.

Au-delà de l’ouverture de la gouvernance de la communauté, il est très important que ses règles soient très clairement énoncées et facilement consultables. De la même façon, la transparence des buts et des objectifs de la communauté est fondamentale pour que de nouvelles énergies y soient associées. Cela est également nécessaire pour que chacun puisse voir avec une grande précision ce qu’il apporte au collectif. La transparence de l’organisation permettant d’atteindre ces buts et ces objectifs est également importante. Il faut que tous les participants aient une vision claire de la répartition des tâches entre les différentes équipes investies dans les processus de production. Il faut que le plan stratégique de production de la communauté soit connu de toutes et tous. Enfin, les communautés « mérito-démocratiques » du libre font attention à ce que la transparence des valeurs de la communauté soit respectée à travers la mise en ligne d’un code de conduite claire, encore appelé Charte d’usage qui encourage généralement le respect des membres et leur collaboration.

Afin que la transparence soit respectée, de nombreux outils numériques sont mobilisés : IRC, listes de discussion ouvertes avec des archives publiques, sites web clairs et complets, archives accessibles. Leurs usages sont explicités dans une documentation détaillée et accessible. Là encore, ces outils doivent être simples, adaptés aux besoins de ceux qui travaillent dans la communauté et ouverts. Afin qu’ils soient effectivement utilisés, des moyens de « récompenser », ou de rendre visible, l’investissement des membres de la communauté pour la transparence de celle-ci doivent être mis en place.

La transparence permet la création d’un sentiment de confiance dans lequel peut s’épanouir la création collective. Les liens qui s’y tissent entre les membres sont en eux mêmes une des richesses produite par la communauté.

Les communautés du libre vivent parce qu’elles ont une mission : produire un logiciel qui soit utile à la communauté. L’engagement des informaticiens dans les communautés du libre est souvent dicté par des considérations pratiques : ils s’y investissent parce qu’ils ont besoin des outils et que ceux-ci sont mis en place par des communautés ouvertes dans lesquels leur investissement en temps dans le logiciel est multiplié. Or cela ne pourrait pas être si le logiciel produit n’était pas un bien commun. Il va sans dire que personne ne donnerait gratuitement de son temps à un logiciel si celui-ci était la propriété d’une personne. D’autre part, l’investissement des informaticiens dans un projet est directement lié au fait qu’ils vont pouvoir tirer bénéfice de cet investissement en utilisant le logiciel dans leur propre contexte d’action – les logiciels qui sont des « biens communs » sont précisément des logiciels qui peuvent bénéficier à toute la communauté. Comment produire un bien commun ? Quelle infrastructure technique et juridique doit être déployée pour assurer cette production ?

Les communautés à sources ouvertes s’appuient d’abord pour cela sur un certain nombre d’outils collaboratifs. Elles utilisent en premier lieu des outils d’écriture collective du code. Ces outils permettent le partage d’un répertoire dans lequel le code est stocké et grâce auquel les personnes autorisées écrivent ou modifient le code. Ils offrent un historique des modifications apportées de façon à ce qu’il soit toujours possible de remonter dans le processus de création du code. Ils permettent également d’organiser la production du code en attribuant des tâches aux différents contributeurs. Ces outils sont généralement regroupé dans une « forge », lieu de production virtuel des logiciels.

Le second type d’outils concerne la critique collective du code. Il est tout à fait primordial que les utilisateurs puissent rapporter ce qui ne fonctionne pas dans le logiciel pour que ce dernier puisse être amélioré. Ces outils de traçage de bugs doivent être largement ouverts à tous les utilisateurs.

Le troisième et dernier type d’outil concerne l’écriture collective du fonctionnement du logiciel, sa documentation technique. Celle-ci doit être facilement accessible et ouverte en écriture. Elle met en jeu des outils de type « wiki ».

Ces outils sont fondamentaux parce qu’ils permettent la diffusion des savoirs nécessaires pour la communauté vive. Les communauté du libre sont avant tout des communautés d’apprentissage et des lieux de démocratisation des savoir techniques. Pour que de nouvelles personnes puissent intégrer la communauté, il faut qu’elles acquièrent un niveau de connaissance sur le logiciel nécessaire pour interagir avec sa production. Cela est nécessaire à la fois pour des raisons d’expertise technique mais également pour des raisons de dignité du travail fourni par la personne et de valorisation de l’investissement qu’elle réalise. Les transferts de savoirs sont au fondement de la vie des communautés open/source. Ces transferts ont lieu via la documentation, mais également via des outils qui permettent aux développeurs de se suivre les uns les autres (compagnonage informatique) [14]. Ils permettent aux nouveaux entrants d’acquérir l’expertise nécessaire pour participer au développement du code, et aux dirigeants de la communauté de se nourrir des savoirs nouveaux que les nouveaux entrants apportent. L’infrastructure technique n’est toutefois pas suffisante. Une communauté du libre ne peut perdurer que si le mode de protection juridique de la richesse immatérielle produite collectivement est adapté. Quel régime de droit d’auteur doit être appliqué à une œuvre collective souvent produite par une communauté dont les membres sont dispersés de part le monde et qui peut, assez vite, générer d’importants revenus ?

Les licences libres ou open-source [15] qui sanctionnent et protègent l’autorité collective sont la réponse concrète à cette question. De façon générale, elle assurent quatre libertés : liberté d’exécution, de lecture, de modification et de diffusion. Il faut bien comprendre que ces licences n’équivalent pas à un versement dans le domaine public du logiciel : un droit d’auteur spécifique continue de lui être appliqué, mais c’est un droit qui protège la communauté de développeurs et d’utilisateurs du logiciel.

Les licences libres sont nombreuses : la General Public Licence (GPL), Apache Licence, Berkeley Software Distribution Licence (BSD), Mozilla Public Licence (MPL) etc... [16]. Il faut noter à cet égard l’extension de leur modèle à des œuvres de l’esprit qui ne sont pas des logiciels mais des textes, images, sons etc. à travers la licence Creative Commons [17]. Elles sont également efficaces, puisqu’une jurisprudence existe en Amérique du Nord au moins depuis 2004 [18].

La question principale qui traverse le paysage des licences libres est celle de leur « viralité ». La principale licence libre – la GPL – impose que le code source dérivé du code source initial soit diffusé sous la même licence que celui-ci. Ces licences sont les plus fortes en termes de contraintes. Mais il existe tout un éventail de puissance de protection du bien commun. La LGPL permet par exemple qu’un logiciel protégé par une licence GPL puisse être lié à un logiciel propriétaire. Les licences les plus permissives, de type Apache, permettent quant à elles que le code source libre soit utilisé pour l’édition de logiciels propriétaires.

Les licences libres qui protègent un code ouvert sont une forme de contrat social : elles définissent très exactement ce qu’il adviendra de la production commune.

S’enrichir de l’expérience des communautés du libre : vers des entreprises à sources ouvertes ?

Quels enseignements pouvons nous tirer des modes de gouvernance des communautés du libre pour les entreprises et les industries de l’avenir ? Comment dériver les principes de gouvernance ouverte, de transparence et de biens communs dans un contexte entrepreneunarial plus vaste que celui de l’économie logicielle ? Quels sont les structures et les outils à mettre en place ?

Ouvrir la gouvernance

La première classe d’outils à mettre en place dans les entreprises à sources ouvertes doit permettre d’élargir les instances décisionnelles en y faisant participer toutes les partie prenantes de l’entreprise. Les conseils d’administration, les assemblées générales, les conseils de surveillance peuvent aisément être retransmis sur le web via des flux vidéo ou audio assortis d’outils de prise de parole distante. Il ne s’agit bien sûr pas ici d’ouvrir l’entreprise aux quatre vents : la transmission et la participation aux instances décisionnelles sont restreintes et les entreprises peuvent et doivent choisir à qui elles ouvrent leur gouvernance.

La participation élargie à la gouvernance doit également s’appuyer sur des outils de choix collectifs. Les plus évidents sont évidemment les outils de vote à distance via le web. Ceux-ci permettent d’augmenter sensiblement la participation aux votes lors des assemblées générales. Les outils de sondage en ligne des différentes parties prenantes en amont des conseils ou des assemblées décisionnaires pourraient également être plus systématiquement utilisés. Pourquoi par exemple ne pas sonder les sociétaires des entreprises à sources ouvertes sur les ordres du jours des assemblées générales ou des conseils d’administration ? Enfin, des outils moins connus d’aide à la décision collective sont également utilisables – je pense notamment ici aux outils de priorisation des choix.

Des outils d’écriture collaborative de la charte d’usage de l’entreprise – son règlement intérieur – et de la mission de cette dernière peuvent également être mis en place. Qu’on me comprenne bien : il ne s’agit pas, là non plus, d’ouvrir des documents, aussi importants que le règlement intérieur, à un processus d’écriture incontrôlé. Mais il existe des outils numérique d’annotation des textes : pourquoi ne pas s’en servir pour permettre aux parties prenantes de l’entreprise, et notamment à ses salariés, d’annoter les textes régissant la vie interne ou encore présentant la mission de l’entreprise afin d’en proposer des modifications ? Pourquoi ne pas faire le pari de l’intelligence collective du groupe ? Si les modifications proposées sont intéressantes, elles pourront être intégrées selon des processus décisionnels classiques [19].

Repenser la transparence

Les entreprises à sources ouvertes doivent utiliser, comme toutes les entreprises, des outils classiques de publication d’informations sur le web : site web, lettre d’information électronique etc... Mais elles ne s’arrêtent pas là. Elles ajoutent à leur outils de publication des espaces d’interaction entre toutes les parties prenantes de leur activité. Ces outils peuvent être des IRC, des listes de discussion ouvertes avec des archives publiques ou des réseaux sociaux... Ils permettent d’augmenter la transparence non pas en organisant une communication entre l’entreprise et une personne physique ou morale en particulier, mais en permettant aux différentes parties prenantes de l’entreprise d’être en communication les unes avec les autres sans avoir à passer par l’entreprise elle-même.

L’entreprise à source ouverte permet à ses clients de communiquer entre eux et de s’organiser entre eux pour obtenir les informations qu’ils souhaitent avoir. L’exigence de « réponse » – l’entreprise à source ouverte est une entreprise responsable, qui se met en posture de répondre de ses actes – s’en trouve considérablement accrue car les questions qui émanent de groupes organisés sont mieux motivés et, généralement, plus impératives.

L’entreprise à source ouverte met à la disposition de ses parties prenantes des espaces de collaboration qui lui échappent et la force à être transparente.

Fabriquer des biens communs

Les entreprises à sources ouvertes n’organisent pas une économie de la rente : pas de brevets, pas de secrets de fabrique jalousement gardés, pas de consommateurs pris en otage. Les biens qu’elles produisent sont eux aussi à source ouverte. Les entreprises à source ouverte construisent leur plan d’affaire sur le travail qu’elles s’apprêtent à fournir et non sur un capital accumulé.

Les sociétés informatiques qui produisent du code open-source sont ici un exemple tout à fait parlant. Ces entreprises réussissent tout à fait sur le plan économique. Pourtant, leurs produits sont librement accessibles en ligne et peuvent être disséqués à l’envie. Dès lors, comment ces entreprises fonctionnent-elles ? En vendant des services – du travail – autour de ces produits. Leur fonctionnement ouvert est leur principale force car il leur permet d’associer leurs clients et leurs partenaires à la production de leurs produits en leur permettant de faire des rapports de bugs et de proposer des évolutions.

Pour les entreprises classiques, cela consiste à imaginer que leurs clients deviennent une force de production à part entière en participant à l’identification des problèmes sur les produits et à la définition de leurs évolutions. Les produits ainsi réalisés doivent appartenir à la communauté de leurs utilisateurs et de leur producteurs. Les entreprises mettent à disposition de leur usagers des interfaces qui leur permettent d’interagir avec les produits en en rapportant les dysfonctionnements et en en proposant des évolutions. Ces plateformes sont des outils de production collaborative. Elles doivent offrir un certain nombre de fonctions très utilisées sur les forges de logiciels open-source : historique des modifications du code source des produits, attribution de tâches à la communauté large des utilisateurs du produit, espace de documentation sur les produits, espace de critique et de remontée de bugs sur les produits. Le travail réalisé sur ces plateformes par les acteurs multiples des entreprises ouvertes ne peut pas et ne doit pas être privatisé par les entreprise. Cette privatisation aurait pour effet immédiat de stopper l’apport d’intelligence par les clients et les partenaires à la démarche de l’entreprise. Il faut donc placer le résultat de ce travail collaboratif sous une des nombreuses licences libres.

Trois propositions

Je voudrais pour finir esquisser quelques propositions pour appuyer le développement des entreprises à sources ouvertes dans le cadre de la mise en place d’une politique industrielle audacieuse et engagée dans le sens d’une économie de la contribution.

Travailler sur la structuration juridique des entreprises à sources ouvertes

Il faut approfondir la réflexion sur la structuration juridique des entreprises à sources ouvertes. Deux types de structures juridiques me semblent aujourd’hui capables d’assumer la structuration particulière qu’elles nécessitent :
- les sociétés coopératives d’intérêt collectif (SCIC), en ce qu’elles permettent d’associer toutes les parties prenantes à la gouvernance de l’entreprise à travers la mise en place de différents collèges : collège des fondateurs, collège des financeurs, collèges des collectivités territoriales, collège des utilisateurs, collège des salariés ;
- les sociétés démocratiques (SAS ou SA dont les statuts mettent en place des procédures d’élection des dirigeants par les salariés) parce qu’elles permettent de faire participer à la gouvernance de l’entreprise leurs salariés, qui élisent la direction, et d’associer au capital de l’entreprise les différentes parties prenantes : utilisateurs, autres communautés de développeurs, financeurs etc...

Il faut approfondir nos connaissances des statuts adéquats pour les SCIC et les société démocratique qui font du logiciel libre / open-source. Il faut trouver des réponses à la question de la rémunération de la prise de risque technologique dans le cadre des SCIC. La stabilité des personnes à l’origine de l’innovation technologique qui, souvent, en ont assumé seules le risque lors de la phase de développement de l’innovation, est problématique, comme l’est la rémunération de la prise de risque. Il faut par ailleurs réfléchir plus avant aux problèmes que soulève la démocratie d’entreprise dans les sociétés de capitaux, et notamment dans les rapport entre les processus démocratiques et les instances traditionnelles de représentation des salariés.

Poser la question du financement de la production de biens communs innovants et du hacking

La question du financement de la production de bien communs et du hacking peut être résumée ainsi : comment financer des projets de développement de logiciels ou d’usages innovants dont le code source n’est pas protégé par le droit d’auteurs conventionnel si bien qu’aucune rente de licence n’est possible ?

Un dicton couramment utilisé dans les communauté du libre est qu’un logiciel libre n’est gratuit qu’une fois que son développement a été financé. Or la phase d’amorçage de la production du code est très compliquée. L’économie du logiciel libre repose sur les services. Mais avant qu’il y ait les services, il doit y avoir un code autour duquel vendre du service. Comment financer ces développements ? Les canaux classique du financement sont compliqués. En effet, les financeurs cherchent toujours à se prévaloir du risque d’échec du projet qu’ils financent. Pour ce faire, ils veulent des gages qu’ils pourront récupérer une certaine portion de l’investissement. Cela est simple quand celui-ci a permis d’acheter des bien matériels – machines, immobilier... Cela est simple quand l’investissement a permis d’acheter des bien immatériels qui peuvent être revendus en tant que tels : brevets, marques ou encore logiciels protégé par un copyright. Mais l’équation est beaucoup plus difficile lorsque le bien produit grâce à l’investissement est un logiciel libre, un bien commun ou un usage innovant car il ne peut pas être valorisé et revendu en tant que tel.

Faut-il mettre en place des fonds de capital risque spécifiques qui mettent en place des structures capables d’absorber le risque lié à la production de biens communs ?

Par ailleurs, les innovations d’usage consistent généralement en un détournement de technologies existantes ou en la création de liens entre des technologies jusque là utilisées séparément – autrement dit en du « hacking ». Or les innovations d’usage ne sont souvent pas reconnues au même titre que les innovations technologiques.

Proposer la richesse d’une gouvernance à sources ouvertes aux acteurs économiques

Il faut travailler à étendre les processus est les instruments déployées dans les communautés du libre dans des entreprises non liées à l’industrie logicielle. Ici, un rapprochement avec les structures d’économie sociale et solidaire peut s’avérer particulièrement stratégique. Les coopératives, les mutuelles et les associations sont les entreprises qui s’approchent naturellement le plus des processus à source ouverte. Elles pourraient donc bénéficier très rapidement des innovations organisationnelles et instrumentales apportées par les communautés du libre / open-source. Cela viendrait sans nul doute répondre à la question centrale qui les traverse aujourd’hui : celle de la traduction en pratique des valeurs qui fondent leurs statuts.

En théorie, deux éléments structurent la gouvernance des structures de l’économie sociale et solidaire [20] : démocratie et faible lucrativité. D’abord, celles-ci sont, de par leurs statuts (sauf pour les entreprises qui sont solidaires au titre de l’insertion par l’activité économique), tenues d’observer une gouvernance démocratique. Les travailleurs dans le cas des coopératives de production, les sociétaires dans le cas des mutuelles, des coopératives de consommateurs ou des coopératives d’intérêt collectif, les associés dans les associations, élisent les instances dirigeantes des structures et approuvent les décisions importantes lors des Assemblées Générales. Deuxièmement, parce qu’elles encadrent la lucrativité de leur modèle d’affaire, les entreprises d’économie sociale et solidaire doivent rendre compte de leur activité selon des critères particuliers plus liés à la création de valeur sociale et environnementale qu’à la création de richesses monétaires. Cette spécificité des critères de la reddition de compte doit s’accompagner de spécificités dans les modalités pratiques de la reddition de compte : on ne communique pas et ne discute pas de la même façon un rapport financier et un rapport social et environnemental.

Mais l’histoire montre que la protection statutaire des processus démocratiques n’est pas suffisante pour assurer qu’ils aient bien lieu. Il faut plus qu’un texte pour que les femmes et les hommes qui s’investissent dans ces structures puissent réellement y donner de la voix. Plusieurs problèmes se posent. D’abord, celui de la faible implication des sociétaires ou des salariés dans les très grosses structures de l’économie sociale : comment faire participer à la gouvernance des entreprises de l’économie sociale des volumes importants de sociétaires ? Ensuite, celui de la complexité des sujets à traiter : comment faire en sorte que les sociétaires de grandes entreprises de l’économie sociale puissent comprendre et décider de choix de gestion extrêmement compliqués ? Enfin, la capacité des structures à faire sortir les choix importants de leurs instances démocratiques, en les technicisant notamment – le rôle de la « technocratie » d’économie sociale étant ici assez similaire à celui de la technocratie étatique.

Sur ces points, les processus et instruments que nous avons vu à l’oeuvre dans les communautés du libre / open-source peuvent s’avérer fort utiles. On a vu que les commuanuté du libre parvenaient, grâce à un certain nombre d’outil et à des modes spécifques de structuration et d’animation des communautés à faire participer un très grand nombre d’utilisateurs et de développeurs. Pourquoi ne pas utiliser ces méthode pour animer les communautés virtuelles de sociétaires des entreprises de l’économie sociale et solidaire ?

Par ailleurs, le défi de la complexité des choix soumis au collectif peut être surmonté grâce aux outils numériques déployés par les communautés de libriste visant à augmenter l’intelligence collective de leur groupe : documentations en ligne, forums, canaux d’échanges immédiats (IRC)... La pratique d’aide de son prochain et d’explication des difficultés techniques qui a cours dans les communautés du libre pourrait également être analysé et reproduite dans le cadre de l’expertise des sociétaires sur les documents qui leur sont fournis en amont des Assemblées générales.

Conclusion : sur les entreprises à sources ouvertes comme piliers d’une économie de la contribution

Voici à grands traits esquissés ce que pourraient être des entreprises à sources ouvertes. Des entreprises faisant le pari d’ouvrir leur gouvernance, d’assurer une grande transparence de leur action et de produire des biens communs. A la croisée de l’innovation apportées par les communautés de développeurs de logiciels libres et de la tradition des mouvements coopératif, mutualistes et associatif, ces entreprises seraient fortes de l’engagement de toutes leurs parties prenantes. Elles trouveraient, dans la diversité de leurs acteurs, des réponses aux défis systémiques qui nous attendent. Elles sentiraient, en se mettant à l’écoute de leurs salariés, de leurs consommateurs, de leurs investisseurs, les modifications des attentes auxquelles il faudra répondre. Des entreprises à sources ouvertes, précisément parce qu’elles sont ouvertes, prendraient soin du monde en prenant soin d’elles mêmes. Elles pourraient rendre leur dignité à deux actes essentiels que nos sociétés consuméristes ont vidé de leur sens : l’acte de « produire » tout d’abord, l’acte de « consommer » ensuite. Dans les entreprises à sources ouvertes, ceux qui produisent ne seraient plus coupés de leur production. Ils pourraient ainsi recoller au sens de leur acte productif et passer de « l’emploi », qui consume le salarié comme on consume une matière première, au travail qui, parce qu’il peut être bien fait et améliorer le monde, élève celui qui le conduit. D’autre part, les entreprises à sources ouvertes, parce qu’elles co-produiraient des biens communs avec les consommateurs sortiraient ceux-ci de la consommation. Les consommateurs ne seraient ainsi plus passifs : ils seraient acteurs de ce qu’ils consomment. Ils ne seraient plus destructeurs de richesses produites pour être détruites, mais co-producteurs de richesses produites pour être durables.

URL d’origine du document
Mai 2010 - version 1.0
Licence Creative Commons By-Nd

Notes

[1] Martine Aubry et Bernard Stiegler (« Soigne ta gauche », Philosophie magazine n°47, mars 2011, p. 29-33) ont souligné les éléments constitutifs de cette double tension et l’importance d’en relever les défis à travers la mise en place, par l’Etat, de politiques industrielles ambitieuses.

[2] Dans « entreprises responsables », je crois que « responsable » doit être entendu dans son sens le plus simple : les entreprises responsables sont celles qui sont capables de répondre de leurs actes devant toutes leurs parties prenantes : salariés, consommateurs, citoyens, financeurs, propriétaires... Les débats sont aujourd’hui vifs autour des critères permettant de définir quelles sont les entreprises pouvant à juste titre se revendiquer « responsables », et les chapelles sont nombreuses : entreprises d’économie sociale et solidaire, entreprises sociales, entreprises « normalisées » (ISO 26000, GRI etc...)...

[3] Les « systèmes d’exploitation » sont la couche logicielle qui permet d’exploiter une machine, comme Windows pour le monde du logiciel privatif.

[4] http://www.spi-inc.org

[5] http://www.debian.org/devel/constitution

[6] http://www.debian.org/social_contract

[7] Système d’exploitation libre forké de Debian et utilisé par plusieurs millions de personnes – http://www.ubuntu.com

[8] On compte de nombreuses femmes dans le monde de l’open-source – beaucoup plus que leur visibilité ne peut le laisser penser... D’où l’importance qu’elles soient représentées à la mesure de leur engagement dans la gouvernance des projets open-source. Voir http://geekfeminism.wikia.com/wiki/... (merci à Johan Mathé de m’avoir indiqué cette page).

[9] Cette personne est généralement appelée BDFL pour « Benevolent Dictator For Life » - littéralement « Bienveillant Dictateur à Vie »

[10] Ce modèle est fréquent dans les communautés du libre, tant dans les systèmes d’exploitation (voir par exemple le rôle de Linus Torvalds dans le développement du noyau linux) que dans certains langages de programmation (Perl et Larry Wall, PHP et Rasmus Lerdorf, Python et Guido van Rossum. Le cas de Python est particulièrement révélateur : Guido van Rossum dirige une équipe de « core developpers » qui ont un accès en écriture sur le dépôt Cpython. Ils peuvent recevoir une aide ponctuelle d’autres développeurs mais à travers d’autres interface de travail, et notamment l’interface de remontée de bugs « roundup ». Si les modalités d’acceptation dans la Python Software Foundation sont clairement explicitées, ce n’est pas le cas pour la participation à la communauté de développement : les modalités d’attribution des droits d’écriture sur le code ne sont pas indiquées sur le site).

[11] Cf. la page qui concerne les « core developpers » sur le site de Drupal (dans la catégorie « About ») : http://drupal.org/node/21778

[12] Ce dernier point est précisé sur le site de l’association Drupal http://association.drupal.org/about/faq

[13] Cette étude est fondée sur ma propre expérience des communautés de développement de logiciels libres. Je me suis également appuyé sur le très beau livre de Jono Bacon, The Art of Community (O’Reilly, 2009) qui relate la mise en place de la vaste et puissante communauté Ubuntu.

[14] L’exemple de GitHub est ici tout à fait intéressant. Merci à Christian Faure d’avoir attiré mon attention sur la fonction de « compagnonage » que permet GitHub – http://www.github.org)

[15] Telles que définies par la Free Software Foundation (http://www.fsf.org/) ou l’Open-Source Initiative (http://www.opensource.org/).

[16] Un chiffre intéressant sur l’usage des licences lires : en 2008, sur 100,000 projets de logiciels libres hébergés par Google, les licences GPLv2 et v3 représentent 42,6% des projets, la licence Apache représente 25,8%, les licences du MIT, BSD et LGPL à peu près 8% pour chacune d’entre elles. http://google-opensource.blogspot.c...

[17] http://creativecommons.org/

[18] Ainsi, dans un arrêt important de 2008 (Jacobsen v. Katzer, United States Court of Appeal for the Federal Circuit, 2008), la Cour d’appel a confirmé que le non respect de la viralité de la GPL (c’est à dire que les contributeurs qui modifient le code source original redistribuent leurs modifications) était passible de poursuite sur la base d’une violation du droit d’auteur.

[19] L’ouverture de la gouvernance de l’entreprise aux salariés doit se faire en bonne intelligence avec les instances classiques de la représentation salariale.

[20] On compte parmi celles-ci : les associations loi 1901 et 1875, les sociétés coopératives de production, les société coopératives d’intérêt collectif, les coopératives loi 47, les mutuelles, les sociétés faisant de l’insertion économique, les sociétés démocratiques.

Dans la même rubrique

Sur le web (fils RSS et sites associés)

Actualités

Tous les articles de la rubrique

Livres et publications

Tous les articles de la rubrique

Creative Commons License Sauf mention contraire, le contenu de cette page est sous contrat Creative Commons
Ce site est réalisé avec logo spip logiciel sous licence GNU/GPL - Contact - Plan du site - Rédaction