L’atelier alternera présentation du projet, application de la solution à des scénarios conçus collaborativement, et intelligence collective pour envisager de nouveaux champs d’application de la technologie.

Avec Andra CHAKROUN, développeuse OpenFisca et LexImpact, Entrepreneur d’intérêt général.

Un brevet porte sur une invention brevetable relative à un produit ou à un procédé et sert à contrôler l’utilisation qui sera faite d’une invention. Contrairement au droit d'auteur, il n’est pas possible de “simplement” réécrire la fonctionnalité brevetée.

En France, comme en Europe, les brevets ne peuvent en principe pas porter sur des logiciels. Ce n’est cependant pas le cas aux États-Unis ou au Japon.

Les brevets logiciels sont très contestés et font l’objet de nombreux abus, parmi lesquels figurent notamment les patent trolls : il s’agit de sociétés dépourvues de département R et D (Recherche & Développement) qui vont acheter des brevets tiers afin de négocier des licences ou d’agir en justice.

Sous couvert de favoriser la diffusion de l’innovation, elles cherchent uniquement à maximiser le gain relatif à leurs actifs.

En réaction au système des patent trolls, certains acteurs industriels ont choisi de se regrouper pour former des groupements de brevets à titre défensif. IBM, Google, Red Hat, etc. sont à la tête d'initiatives collectives afin de défendre certains secteurs économiques.

De cette manière, ils se protègent mutuellement contre toute action en contrefaçon de leurs brevets respectifs et ont parfois vocation à favoriser l’innovation dans un domaine donné (comme en matière d’énergie pour Tesla).

Certains de ces groupements vont plus loin encore dans cette démarche, en promettant aux communautés Open Source de ne pas leur opposer leurs brevets.

Ainsi, L’Open Invention Network (OIN) - consortium composé d’industries de haute technologie - a conduit l’initiative nommée « Linux Defenders » qui a vocation d’aider à protéger les communautés de logiciels Open Source contre les dangers et attaques récurrentes en matière de brevets.

Le détenteur d’un brevet peut autoriser ceux qui le souhaitent à reproduire son invention. Ainsi, il est tout à fait possible pour le titulaire d’un brevet d’accorder une licence à quiconque souhaite l’utiliser dans le cadre d’un projet Open Source.

Certaines licences prévoient ainsi des clauses spécifiques en matière de brevets, comme la licence Apache ou la licence GPL.

En ce sens, la licence GPL version 2 contient une clause implicite empêchant toute société distribuant un logiciel sous cette licence de poursuivre ensuite les utilisateurs subséquents (ses propres utilisateurs, mais également les utilisateurs de ses utilisateurs) pour violation de brevets. La version 3 de la licence GNU GPL va encore plus loin, et inclut une clause explicite qui va étendre cette obligation de protection des brevets.

Le terme Inner Source a été inventé par Tim O’Reilly en 2001, pour désigner l’utilisation des techniques et mécanismes de l’Open Source au sein de l’organisation.

À travers la culture, les pratiques et la méthodologie telles qu'utilisés et appliqués dans les projets open source, elle s'appuie sur la collaboration, la transparence, le mérite, et l'autonomie au sein des entreprises. Ce dernier point, étant un élément crucial, rend l'application de l'innersourcing parfois compliquée tant elle demande une réforme complète de la culture et de la pensée du modèle de l'entreprise.

Cette collaboration est rendue possible par la transparence des processus, ceux-ci étant accessibles à l'ensemble des participants. Toutes les décisions, les discussions, ainsi que les étapes de la vie du projet doivent être mises à disposition de tous. Cela permet à ceux qui prennent le projet en cours d'avoir accès au même niveau d'information que ceux qui sont déjà présents depuis le début.

De même tous les outils doivent être accessibles. Cela permet de maintenir une culture et une co-création entre les équipes laissant place à un terrain fertile pour l'innovation au sein de l'entreprise. Cela favorise également un recrutement qualitatif en étant plus attractif et une fidélisation des talents en interne. Ce partage développe une amélioration de la base de connaissance des individus, une mise en commun des méthodologies et une modélisation des processus à travers les équipes ainsi qu'un "brain-storming" permanent appelant à une plus grande créativité.

Enfin, l'autonomisation des acteurs permet une meilleure priorisation des travaux par les équipes, le développeur travaille sur ce qu'il préfère, cela encourage la méritocratie (c.-à-d. une reconnaissance par rapport aux contributions réelles, les tâches de gestion s'en trouvent donc allégées). Cette responsabilisation rend l'entreprise attractive pour les employés présents et futurs. Prendre des responsabilités, c'est s'investir, rechercher les meilleures opportunités, être créatif, performant et se sentir plus en prise avec la tâche à accomplir, la rendant ainsi plus intéressante.

L'outil open source Bitergia permet d'analyser la communauté et les contributeurs rattachés à une entreprise. Il permet en effet de visualiser rapidement la localisation de ces contributeurs, le type de contribution apporté et savoir si les modèles open source sont utilisés.

Très proches du modèle open source et largement présentes dans l'innersourcing, les méthodes agiles représentent des pratiques de gouvernance de projet, se veulent plus pragmatiques que les méthodes traditionnelles et proviennent du manifeste agile rédigé en 2001.

Elles impliquent au maximum tous les acteurs autour du projet, y compris le client, et permettent une grande réactivité à ses demandes.

Les méthodes agiles reposent sur un cycle de développement (un cycle comporte un petit nombre de phases) et les cycles sont répétés autant de fois que l’on en a besoin, au fur et à mesure, afin de réadapter le projet en fonction de son avancement.

Le manifeste Agile pose 4 principes qui ne vont pas sans rappeler ceux de l’Open source :

• Les individus et leurs interactions, plus que les processus et les outils
• Des logiciels opérationnels, plus qu’une documentation exhaustive
• La collaboration avec les clients, plus que la négociation contractuelle
• L’adaptation au changement, plus que le suivi d’un plan

Pour ce qui est du lean, cette méthode vise à minimiser le gaspillage, avec une gestion “plus juste” des ressources.
À cet effet, le lean se fixe comme objectif d’éradiquer trois « démons » de l’organisation du travail :

• le Muda : tout ce qui est sans valeur
• le Muri : l’excès, la surcharge de travail engendrée par des processus non adaptés :
• le Mura : la variabilité, ou l’irrégularité

Un des gaspillages à éradiquer dans le lean est la non-utilisation des ressources intellectuelles du personnel, cela pouvant être évité en appliquant les principes de l’Open source : chaque personne souhaitant participer au projet est en mesure de le faire et n’est pas bridée pour des raisons irrationnelles.

L’éthique des méthodes agiles et du lean, et celle de l’Open source sont relativement similaires, on y retrouve d’ailleurs la communication et la collaboration comme clef de réussite du projet.

La principale source de similarité entre ces méthodes est l’accent qu’elles mettent sur le partage et l’évolution continuelle du projet.

Les notions d'interopérabilité, d'urbanisation des systèmes d'information, de format ouvert, de gestion de la donnée sont entièrement disjointes des notions de logiciels libres et open source, bien que fortement liées dans un contexte historique et culturel.

On observe une convergence naturelle entre les objectifs de l'interopérabilité et ceux de l'open source dans la réduction de la dépendance à un fournisseur particulier, ce que l'on appelle classiquement "vendor lock-in". Avec la sophistication croissante des systèmes d'information, les interactions avec les différentes composantes se sont développées. De plus, du point de vue des vendeurs de solutions la capacité qu'avaient leurs produits à n'interagir qu'entre eux était le moyen de conserver une clientèle captive et donc d'éliminer la concurrence sans avoir à rivaliser directement avec celle-ci.

Ces stratégies d'enfermement sont de fait opposées à une approche ouverte aussi bien au niveau philosophique (liberté des utilisateurs) que technique (ouverture du code). De plus, les solutions open source se sont développées en favorisant au maximum les interactions avec les solutions tierces. Elles sont également apparues comme solutions alternatives sur les marchés verrouillés par des acteurs dominants. Dans ce cadre, l'interopérabilité est un facteur crucial pour rendre leur adoption possible.

L'open source est venue apporter des cas d'application concrets aux principes théoriques de l'urbanisation des systèmes d'information, en proposant notamment des solutions techniquement et économiquement plus intéressantes.

Cela a permis de démontrer l'importance de concevoir des systèmes d'information correctement urbanisés, c'est-à-dire composés de briques fonctionnant harmonieusement entre elles, tout en étant indépendantes les unes des autres.

C'est d'ailleurs sur ce fondement que la gendarmerie a graduellement mis en œuvre des solutions open source au sein de son système d'information. En termes d'urbanisation et d'interopérabilité ces avancées ne profitent pas seulement aux solutions open sources, mais bien à toutes les solutions inscrites dans une pratique de standard ouvert, étant la plupart du temps des acteurs entrants innovants.

Cela a induit des évolutions techniques pour automatiser cette pratique et notamment la généralisation des outils de gestion des dépendances dans les différents langages (maven pour java, composer pour PHP, PIP pour Python, npm/yarn pour JavaScript, Cargo pour Rust, etc.).

Cela a aussi entraîné des évolutions organisationnelles pour gérer la présence massive de code tiers dans les développements réalisés au sein des organisations, en particulier du point de vue de la sécurité et de la légalité.

Comme on l'a vu précédemment, les licences Open Source confèrent des droits, mais également des devoirs à respecter au risque de graves conséquences.

Il est ainsi impératif d'intégrer la conformité à ces licences dans le processus des différentes étapes de la chaîne de développement.

On peut distinguer trois étapes principales dans ces processus de conformité :

• Identification des composants
• Validation des licences associées
• Exécution des obligations

La première étape consiste à déterminer les composants Open Source entrant dans la composition d'un développement ainsi que la ou les licences qui leur sont associées.

Si une politique spécifique est déjà en place au moment du développement, cela peut se faire de façon déclarative. Dans le cas de l'usage d'outils de gestion de dépendance, ceux de premier niveau sont facilement connus puisqu'ils sont déclarés explicitement, et l'outil permet de calculer automatiquement celles des niveaux suivants (c'est-à-dire les dépendances des dépendances, etc.).

Lorsque la phase d'identification se fait a posteriori, par exemple lorsque le code développé est récupéré d'une entité tierce ou en l'absence d'une politique interne de gestion des composants open source, elle peut être facilitée par certains outils : outil recherchant des textes de licences ou de mentions de droits d'auteur (du type Fossology), ou comparant le code analysé à une base d'empreintes des projets Open Source publics (Black Duck, Flexera, etc.).

Une fois l'ensemble des composants tiers et leurs licences respectives identifiées, il s'agit de valider leur compatibilité entre eux (certaines licences pouvant avoir des exigences contradictoires) et avec les objectifs de l'entreprise pour son développement : l'aspect le plus impactant est généralement le caractère copyleft de certaines licences parce qu'il a de fortes implications sur les modèles économiques possibles.

Une fois la liste des composants établis validée (on parle généralement de Bill of Material), il s'agit d'exécuter les obligations découlant des licences impliquées, que ce soit en matière de mentions de paternité (dans la documentation ou l'application elle-même) ou de mise à disposition de code source.

Encore une fois, cet effort contribue globalement à une meilleure qualité juridique et renforce l’organisation de l’entreprise.

Bien que l'intégralité des grands groupes considère avoir initié leur transition digitale, on se rend compte que la plupart n'en sont qu'au démarrage. Cette transformation étant à la fois une opportunité et une menace pour les entreprises, une incapacité de réagir avec rapidité face à cette évolution peut leur faire perdre l'avantage par rapport à leurs concurrents.

De plus en plus d'entreprises sont convaincues que l'innovation ouverte, fondée sur des mécanismes d'ouverture et de collaboration, doit jouer un rôle prépondérant dans l'accélération de leur transformation numérique.

En effet, le numérique permet aux entreprises de parler un langage commun qui les rend à même de faciliter leur mutualisation et de s'impliquer dans les projets qu'ils utilisent au quotidien en tant que contributeurs ou prescripteurs de ces logiciels. Sur le long terme, l'enjeu consistera pour tous les acteurs industriels et publics de miser ensemble sur des ressources leur permettant d'innover et pérenniser leur évolution digitale.

Plusieurs grands groupes ont notamment fait le choix stratégique d'opter pour l'Open Source comme levier de leur transformation numérique.

Par exemple, c'est le cas de la Société Générale par Françoise Mercadal-Delasalles, Directrice des Ressources et de l'Innovation : "L'Open source est un formidable accélérateur de notre stratégie de digitalisation de la banque".

Mais également celui du groupe Voyage SNCF Technologies par Gilles de Richemond, CEO : "Chez VSC Technologies, l'utilisation des produits Open Source fait partie de notre quotidien depuis l'origine et pour la grande majorité de nos besoins. Notre transformation ces quatre dernières années n'aurait jamais pu avoir lieu en dehors du monde open source".

Autrement dit, l'Open Source fait partie de leur quotidien.

Ensuite, on retrouve deux écosystèmes ayant vocation d'accompagner la transformation numérique de leurs acteurs : Open Law et La Fabrique des Mobilités. Ainsi, ces structures associatives permettent de favoriser le développement numérique au sein d'un écosystème en mettant à disposition des ressources ouvertes.

Comme expliqué en introduction, l’Open Source est désormais omniprésent, incontournable, ancré dans le paysage. Cela donne l’impression trompeuse d’une situation de stabilité, alors que le phénomène est encore jeune, et se renouvelle constamment, car le contexte technologique est très mouvant.

Au cours des dernières années, plusieurs incidents sont venus rappeler que tout n’était pas si stable.

L’exemple le plus marquant concerne OpenSSL, une bibliothèque logicielle permettant de sécuriser les échanges sur Internet. Cette brique fondamentale est utilisée par des milliers de produits, des millions de site Web et d’applications critiques, notamment dans le domaine bancaire et financier.

Cette bibliothèque a été affectée par une faille de sécurité majeure, surnommée Heartbleed, compromettant la sécurité de millions de transactions dans le monde entier.

L’analyse des causes de cette faille a mis en évidence les moyens dérisoires dont disposait le projet et l’absence de contribution des utilisateurs.

En réponse à cet incident, un ensemble d’entreprises grandes consommatrices de logiciels libres (Google, Intel, Bloomberg, etc.) ont lancé la Core Infrastructure Initiative, hébergée par la Linux Foundation afin de tirer les leçons de cet incident et de donner des moyens au projet OpenSSL, mais aussi à d’autres projets dans une situation similaire (OpenSSH, GnuPG, Linux Kernel Self Protection Project, etc.).

Le problème de manque de moyens affecte un périmètre bien plus large de logiciels et renvoie à la notion de “Le bus factor” aussi dit de « résistance à l’écrasement ». C’est-à-dire que la pérennité du projet repose sur un nombre limité de personnes et qu’un “simple” accident serait susceptible de compromettre gravement le projet.

Ce phénomène se retrouve autant au sein de projets communautaires que de projets industriels, et relève surtout de la question de la gouvernance.

À cela s’ajoute que la structure actuelle des développements fait que de nombreux projets dépendent de très nombreux « petits » projets. De fait, la santé des petits projets revêt aussi une importante majeure (c’est un cas rencontré par exemple dans le cadre de leftpad).

Ces éléments renforcent la prise de conscience progressive d’une nécessité de contribution directe ou indirecte par les utilisateurs finaux des projets (en choisissant ses prestataires selon leur participation effective aux communautés des projets Open Source).

Outre la pérennisation des outils qu’elles utilisent, ce type de contribution porte de nombreux avantages pour les entreprises qui en tirent une meilleure maîtrise et, plus généralement, tous les bénéfices de l’Open Source.

Pour les projets avec une gouvernance éditeur, une source de revenus peut être la vente de licences propriétaires. Cette vente peut porter :

• soit sur une version plus évoluée que le produit Open Source distribué (on oppose généralement une version “community” à une version “entreprise”),
• soit pour des produits complémentaires au produit Open Source (sous forme de module ou de greffon),
• soit pour le même produit que le produit Open Source, mais dégagé de certaines obligations liées à sa licence Open Source (comme la clause de Copyleft, exemple assez représentatif de MySQL).

Certains éditeurs peuvent également vendre des souscriptions ou des abonnements : du point de vue de l’utilisateur, cela ressemble beaucoup à la vente de licence, en revanche ce que paie l’utilisateur n’est pas lié à l’usage du code en tant que tel, mais pour son usage dans un contexte facilité : à la fois en termes de certifications (usage de la marque de l’éditeur) et technique (facilité de mise à jour, etc.). L’exemple le plus connu est ici celui de l’entreprise Red Hat.

Le modèle économique le plus volontiers associé à l’Open Source est la vente de service autour du logiciel :

• Cela peut se faire de façon classique : l’entreprise vend des prestations basées sur son expertise sur le logiciel : intégration, conseil, formation, support, etc.
• Plus récemment, cela peut aussi être le développement de services sous forme de plateforme SaaS basée sous le logiciel Open Source. Le client conserve la possibilité d’installer et d’administrer le logiciel sur son parc, mais l’utilisation directe du service hébergé chez un tiers peut être plus rentable pour lui. C’est notamment le cas de l’offre de service de la Société Aquia, à l’origine du célèbre logiciel Drupal.

Il est également fréquent que des acteurs financent le développement d’un logiciel Open Source, car celui-ci est nécessaire à leur activité métier, sans constituer un élément différenciateur en lui-même. La mutualisation que permet l’Open Source rend cette stratégie plus rentable qu’un développement interne.

D'autre part, il peut s’agir aussi bien de vente de matériel ou encore de services reposants sur du logiciel Open Source. De ce fait, les constructeurs de matériel (IBM, Intel, Huawei, etc.) et les géants du Web reposent tous énormément sur les logiciels Open Source, et sont des contributeurs importants à des projets communautaires majeurs ou eux même à l’origine de projets (Linux, Android, etc.).

En termes de financement alternatif, certains projets Open Source s’appuient sur des logiques de mécénat / donation ; ou encore de publicité.

Certains projets Open Source communautaires font appel aux dons de leurs utilisateurs pour financer leurs développements, soit de façon ponctuelle, soit de façon permanente. Pour que ce modèle puisse fonctionner de façon permanente, il est nécessaire que le projet soit dynamique et proche de ses utilisateurs. À noter que des projets comme Libre Office bénéficient à la fois d'un mécénat de particuliers et d'entreprises, voire d'États, bien que les dons individuels soient plus importants.

D'autres projets communautaires se financent uniquement sur la publicité : le logiciel libre étant susceptible de diffusion large et rapide il constitue un bon support pour embarquer des messages ou des services. Mozilla, par exemple, a des accords avec les moteurs de recherche lui ayant permis de financer une grande part du développement de Firefox.

Trouver son modèle économique libre n’est pas donc pas nécessairement aisé. Cependant, il faut noter que parfois la viabilité économique d’un projet passe par une forme Open Source communautaire et non par une entreprise privée, qu’elle soit propriétaire ou Open Source.

Par exemple, le projet Blender initialement propriétaire n’a trouvé sa viabilité économique qu’en passant sous forme de projet communautaire grâce à une implication totale dans cette direction : productions crowdfundées disponibles sous licences libres, etc.

En d'autres termes, cela peut être sous une multitude de formes se trouvant entre l'économie sociale et solidaire et des aspects plus associatifs.

En conclusion :

« Il n’y aura pas d’autre Red Hat ». C'est un sujet fréquemment évoqué. Certains exemples de rachats font rêver (comme celui de MySQL), et le succès de RedHat aussi, mais c'est une réussite liée à un contexte historique particulier et aujourd'hui l'Open Source tend plutôt à une répartition de la valeur au profit d'une multitude d'acteurs.

L’Open Source n’est pas adapté à créer une captation vers un acteur unique. En effet, une grande partie de la valeur créée est diffusée dans l’ensemble de l’économie numérique, et non concentrée dans un unique acteur. C’est cet aspect diffus qui rend l’Open Source si important d’un point de vue sociétal global.

Red Hat est souvent cité comme exemple de réussite, comme modèle, que l’on cherche à imiter ou à décliner à d’autres domaines que Linux. On a vu plusieurs sociétés se revendiquer « le RedHat de » (Open Stack, etc.) et le succès de RedHat est certes bien réel (l’entreprise réalise un CA de plus d’1 ,Md de $), néanmoins ce modèle s’appuie sur un contexte historique et technologique particulier et les nouveaux modèles amènent à favoriser des structures plus petites, agiles et complémentaires entre elles.

Parmi eux, les acteurs à but non lucratif jouent un rôle fondamental. Il en existe plusieurs types, qui répondent à des besoins différents et dont les leviers d’action varient.

Les fondations sont des acteurs clés de l’écosystème, garants du développement et de la pérennité de nombreux projets open source.

Elles interviennent à plusieurs niveaux, tout en ayant des spécificités propres en fonction des contextes et objectifs des projets qu’elles portent.

Parmi leurs actions, elles fournissent la puissance logistique, l’infrastructure et les outils nécessaires aux projets open source pour aboutir à la mise à disposition d’un produit fini. Inclusives, elles permettent ainsi à des acteurs de natures différentes de travailler ensemble.

De plus, elles coordonnent et animent le fonctionnement de la communauté, en mettant à disposition des membres des outils de discussion et de travail collaboratif, et en formalisant des règles de gouvernance collaboratives et transparentes encadrant les relations entre les parties prenantes.

Elles peuvent également sécuriser juridiquement et protéger le travail des contributeurs aux projets qu’elles hébergent, permettre de recevoir des dons et des ressources de personnes physiques et morales, ou encore, défendre les marques des projets.

Qui sont ces fondations ? Certaines fondations ou associations portent plusieurs projets logiciels en parallèle, comme la fondation Apache (qui développe des logiciels open source sous la licence Apache), la fondation Linux (qui a pour but de protéger et standardiser Linux), ou encore la fondation Eclipse (qui porte de multiples projets OS), etc.

D’autres fondations sont consacrées à un projet logiciel spécifique, ou à un ensemble restreint de logiciels. Ainsi, un projet comme Libre Office est géré par The Document Foundation, tout comme Mozilla, Open Stack, Gnome ou encore Drupal qui bénéficient chacun de leur propre fondation dédiée.

D’autres acteurs à but non lucratif – des associations et des fondations principalement – ont pour principal objectif de promouvoir le logiciel libre : elles définissent les principaux concepts qui fondent le logiciel libre et l’open source.

→ Parmi les plus anciennes et influentes figurent la Free Software Foundation, l’Open Source Initiative et le Software Freedom Law Center.

D’autres organisations vont plus loin, en veillant activement à l’application de ces principes. Ces organisations, comme la Software Freedom Conservancy, ou le Software in the Public Interest, mènent des actions en justice pour défendre les utilisateurs dont les libertés n’auraient pas été respectées, ou bien les contributeurs dont les licences de projets n'auraient pas été honorées.

Certains acteurs – principalement des associations – ont pour mission de faire évoluer les cadres juridiques et réglementaires qui favorisent l’usage des logiciels libres. En France, des associations comme l’April, Framasoft, l’AFUL sont particulièrement actives, tandis qu’au niveau européen, on remarque par exemple l’action de la Free Software Foundation Europe ayant également pour vocation de soutenir l'évolution du logiciel libre.

En parallèle, des associations professionnelles ont pour objectif de structurer la filière du logiciel libre comme le Conseil National du Logiciel Libre (CNLL) en France, l’Open Source Business Alliance qui est son homologue allemand, ou encore l’Adullact en France qui agit plus au niveau des collectivités locales et des administrations, notamment en matière de mutualisation des ressources.

Enfin, de plus en plus, des acteurs industriels - parfois concurrents - identifient l’intérêt de mutualiser, de mettre en commun leurs ressources et compétences afin d’accélérer collectivement le développement de projets Open Source.

Certains font le choix de créer une structure à but non lucratif pour porter et organiser leur action, comme l’alliance GENIVI dans le secteur des transports qui a pour objet de promouvoir l’adoption d’une plateforme d’infotainment (ou d'info divertissement) pour véhicule. C'est aussi le choix de OW2, association indépendante dédiée au développement d’une base de logiciels d’infrastructure, jouant un rôle similaire à la fondation Eclipse.

Il est ainsi possible d’évoquer les communautés, l'industrie du Logiciel Libre (au sens large) qui comprend Les bénéficiaires finaux (en tant que clients et prescripteurs de spécifications), ou encore les fondations.

Les acteurs privés

Les éditeurs Open Source sont des sociétés qui investissent dans le développement d’un produit logiciel qu’elles distribuent tout ou en partie sous une licence Open Source. On peut par exemple citer :

• RedHat (distribue une version GNU Linux),
• la PME française SensioLabs (à l'origine du framework Symfony),
• Alfresco, qui édite un système de gestion de contenus

On retrouve ensuite une autre catégorie d'entreprise : les "Pure Players", sociétés spécialisées dans un domaine particulier et contribuant à des projets Open Source communautaires :

• Collabora (UK, contributeurs à LibreOffice et LibreOffice Online),
• OSlandia (FR, contributeurs aux projets QGis et PostGIS),
• VideoLAbs (FR, contributeurs au logiciel VLC)

Pour compléter la liste des acteurs privés, on peut mentionner des sociétés de service spécialisées en Logiciel Libre. Elles jouent principalement un rôle d’intégrateur et d'interface avec le client et offrent aussi des guichets uniques de support sur de larges ensembles de composants Open Source. C'est notamment le cas de :

• Smile , Alter Way, Savoir Faire Linux, …

Des entreprise de Service Numérique généralistes jouent un rôle similaire, et éventuellement en partenariat avec des acteurs plus spécialisés :

• Cap Gemini, Atos, CGI, etc. :

Enfin, on retrouve des entreprises utilisatrices de logiciels libres dans tous les secteurs d’activité : le modèle de ce type de logiciel permet une fluidité entre le rôle d’utilisateur et de contributeur. On constate également que de plus en plus d’entreprises s’impliquent activement dans cette logique, soit pour contribuer à des projets Open Source, soit pour publier leurs propres développements. Cette tendance a commencé par les constructeurs de matériel avant de s'étendre à d'autres domaines. En France la Société Générale, la SNCF, EDF sont particulièrement actifs dans le domaine de l'OS.

Forges publiques

Une autre composante importante dans le domaine de l' Open Source est constituée des éditeurs de forges. Ce sont des plateformes mises à disposition des contributeurs afin de développer leur projet de manière collaborative. La plupart sont des acteurs privés, mais leur position les oblige à avoir une certaine loyauté dans leurs pratiques (c’est cette absence de loyauté qui a été reprochée à sourceforge).

Leur pérennité n’est pas forcément assurée (tel Google Code qui a fermé récemment) ce qui rend d’autant plus intéressant des projets tels que Gitlab (qui propose une version Open Source de son logiciel sur sa plateforme de forge publique).

À noter une nouvelle fois : le projet Software Heritage permet d’assurer une pérennité par l’archivage de tous les codes sources passés, présents et futurs transitant sur ces plateformes. C'est donc une mémoire colossale maintenue par un acteur français et soutenue par différents autres acteurs dans le monde entier.

Les acteurs à but non lucratif sont aussi très nombreux dans le paysage de l’Open Source, et jouent des rôles particulièrement structurants pour l’écosystème.

Ils prennent une dimension variable selon qu’ils portent sur un projet, qu’ils soient portés par une fondation ou encore qu’ils fassent partie d’un ensemble plus important soutenu par un consortium ou une fondation “parapluie”.

Leur rôle est tel qu’une vidéo propre leur est consacrée.