Logiciels libres et open source

Guide pour PME

Publié sous licence CC Attribution-Sharealike 2.5

Rapport édité par : Carlo Daffara, email : cdaffara@conecta.it
Réalisé dans le cadre du projet OPENTTT EU
Financé dans le cadre du programme FP6-033982
Site Internet : www.openttt.eu

1
 Logiciels libres et open source
Guide pour PME

Édition : 1.8 Décembre 2007 (livrable D 8.1.1), publié sous licence CC Attribution-Sharealike 2.5. Texte de licence
disponible sur http://creativecommons.org/licenses/by-sa/2.5.
Rapport édité par : Carlo Daffara, email : cdaffara@conecta.it. Page du document http://guide.conecta.it . Réalisé
dans le cadre du projet OPENTTT EU
Financé dans le cadre du programme FP6-033982. Site Internet du projet : www.openttt.eu. Illustration de couverture
par Sven Geier, http://www.svengeier.net/fractals. L’auteur remercie particulièrement Roberto Galoppini
(www.robertogaloppini.net) pour son soutien et ses recherches, Pamela Jones et les nombreux lecteurs de Groklaw
ayant contribué à l’amélioration du chapitre 2.

2
 Table des Matières
Introduction ................................................................................................................................................... 5
1. Qu'est-ce qu'un logiciel libre et open source ? ................................................................................ 6
Le FLOSS comme modèle de licence ................................................................................................. 6
Le FLOSS comme modèle de développement ................................................................................ 9
2. Dix mythes sur le logiciel libre et open source ................................................................................ 12
1er Mythe : Il s’agit d’une histoire Linux-vs-Windows. ...................................................................... 12
2e Mythe : le FLOSS n'est pas fiable ou ne reçoit aucun soutien ................................................. 12
3e Mythe : Les grandes entreprises n'utilisent pas le FLOSS. .......................................................... 14
4e Mythe : le FLOSS est l’ennemi de la propriété intellectuelle. ................................................... 15
5e Mythe : le FLOSS : une histoire de licences .................................................................................. 16
6e Mythe : si je donne mon logiciel à la communauté FLOSS, des milliers de développeurs
vont tout à coup commencer à travailler pour moi gratuitement. ............................................ 16
7e Mythe : le FLOSS ne concerne que les programmeurs, étant donné que la majorité des
utilisateurs ne regarde de toute façon jamais sous le capot ....................................................... 16
8e Mythe : gagner de l'argent avec FLOSS est impossible ............................................................ 17
9e Mythe : le mouvement FLOSS n'est pas viable, car les gens cesseront de développer des
logiciels open source dès qu'ils verront que les efforts des autres sont bien mieux payés .... 18
10e Mythe : le FLOSS tente de rattraper Microsoft et le monde des affaires ............................. 19
3. Modèles élémentaires d'adoption du FLOSS ................................................................................... 20
L’échelle d’adoption du FLOSS .......................................................................................................... 20
4. Trouver et sélectionner le logiciel ...................................................................................................... 23
Sites basés sur Forge : ........................................................................................................................... 23
Sites d’annonces de logiciel : ............................................................................................................. 24
5. Meilleure méthode pour l'adoption du FLOSS ................................................................................. 29
Directives de gestion ............................................................................................................................ 29
S’assurer de l'engagement de la direction pour la transition ...................................................... 29
Préparer une vue d'ensemble de ce qui est attendu de la migration ou de l'adoption, y
compris des critères mesurables ........................................................................................................ 30
S’assurer que le programme est réaliste ........................................................................................... 30
Vérifier la passation de marché actuelle de logiciel/de l'Informatique et la procédure de
développement .................................................................................................................................... 30
Rechercher des conseils ou des informations sur des transitions similaires ................................ 31
Eviter une transition de « grand changement » et préférer des migrations progressives ....... 31
Nommer au moins une personne pour interagir avec la communauté OSS ou le vendeur
OSS, et essayer de trouver des sources d'informations en ligne .................................................. 33
Directives techniques ........................................................................................................................... 33
Comprendre la façon dont OSS est développé ............................................................................. 33
Réaliser un examen complet du logiciel et du matériel qui seront touchés par la migration,
et déterminer les fonctionnalités que la société recherche ........................................................ 34
Utiliser la flexibilité d’OOS pour développer des adaptations locales........................................ 34
Il existe beaucoup plus de logiciels disponibles que ceux installés par défaut........................ 35
Dans le choix des packages, toujours favoriser la stabilité par rapport aux fonctionnalités . 35
Concevoir l'infrastructure de support de l’automatisation des processus en vue de réduire
le nombre de « disparités d’adaptation » ........................................................................................ 35
Présenter un système de ticket ........................................................................................................... 36
Composer et mettre à jour un manuel d’instruction détaillé ....................................................... 36
Directives sociales ................................................................................................................................. 36
Donner des informations sur OSS ........................................................................................................ 36
Ne pas imposer le changement aux utilisateurs, mais leur donner des explications .............. 36
Utiliser la migration comme occasion d’améliorer les compétences des utilisateurs ............. 37
Faciliter l’expérience et l’apprentissage .......................................................................................... 38
6. Modèles commerciaux basés sur le FLOSS ...................................................................................... 39
Financement externe d'entreprises ................................................................................................... 39
Financement public .............................................................................................................................. 40

3
 Financement de « l'amélioration nécessaire » ................................................................................ 40
Financement indirect / Perte .............................................................................................................. 41
Utilisation interne .................................................................................................................................... 41
« Le meilleur savoir, c’est ici » sans contraintes................................................................................ 42
« Le meilleur savoir, c’est ici » avec contraintes .............................................................................. 42
« Le meilleur code, c’est ici » sans contraintes ................................................................................ 43
« Le meilleur code, c’est ici » avec contraintes/Licences fonctions du temps ........................ 43
Licence double ...................................................................................................................................... 43
Développements non financés .......................................................................................................... 44
Modèles commerciaux basés sur les services spécialisés ............................................................. 44
Support pour le choix du logiciel........................................................................................................ 45
Support pour l'installation ..................................................................................................................... 45
Support pour l'intégration .................................................................................................................... 46
Certification de l'appropriation technique ...................................................................................... 46
Certification légale ............................................................................................................................... 46
Formation ................................................................................................................................................ 47
Contrats de maintenance et de support continus ........................................................................ 47
Services de migration ........................................................................................................................... 48
Commercial-on-open........................................................................................................................... 49
Services de médiation .......................................................................................................................... 49
Custom development .......................................................................................................................... 50
Evaluation de l'utilisation des modèles commerciaux FLOSS ....................................................... 50
Bibliographie............................................................................................................................................... 55
Annexe 1: estimation du nombre de projets FLOSS actifs ................................................................. 59
Annexe 2: tableaux de résultats de l’évaluation QSOS ..................................................................... 62

4
 Introduction
« Le logiciel libre et open source constitue la tendance à long terme et universelle la
plus importante que l'industrie du logiciel ait connue depuis le début des années
1980 ». Il s’agit de l’une des conclusions d'un récent rapport de l’IDC [IDC 06], qui
montre combien la perception du FLOSS (Free/Libre Open Source Software) a
changé au cours des dernières années. À présent, la majorité des développeurs
dans le monde utilisent un logiciel open source [Forr 07], et les plateformes FLOSS
sont utilisées d'une façon ou d'une autre par une grande partie des entreprises.
Malgré cette situation, il existe toujours un obstacle important au processus
d'adoption pour les petites et moyennes entreprises, tant en termes d’utilisation de
FLOSS de manière interne que dans la création de produits et services centrés sur les
produits FLOSS. L'objectif de ce rapport est de donner une vue simple et détaillée
des aspects fondamentaux du FLOSS, de la façon de l'adopter dans une
petite/moyenne entreprise, et enfin de la façon de construire une entreprise viable
en l’utilisant.

5
 1. Qu'est-ce qu'un logiciel libre et open source ?
Le fait de découvrir que le marché du logiciel basé sur des packs « prêts à l’emploi »
pouvant être directement et facilement achetés par l'utilisateur est relativement
récent peut en étonner plus d’un. Au début, le logiciel était embarqué dans le
matériel par le fabricant. Toutefois, le développement des modèles commerciaux
des fabricants (se basant sur la vente de matériel) étant entre autres complexe et
coûteux, les utilisateurs se sont mis à partager le code source et à s’échanger des
conseils en collaborant tous ensemble. C’est ainsi que des groupes d'utilisateurs ont
vu le jour, tels que SHARE (Society to Help Avoir Redundant Efforts, créé en 1955 et
centrée sur les systèmes IBM) ou encore DECUS (pour les ordinateurs numériques et
plus tard pour les systèmes HP), tous deux encore actifs aujourd’hui. Le code était
également partagé dans les journaux universitaires, comme dans la célèbre rubrique
« Algorithmes » du journal des « Communications de l'ACM ».

Au cours du processus de « dégroupage » (c’est-à-dire la séparation des catalogues

de matériels et de logiciels), les premiers logiciels « prêts à l’emploi » sont apparus sur
le marché dans les années 1970. Avec l'avènement des premiers ordinateurs
personnels (l'Apple II, le PC IBM et beaucoup d'autres), le marché du logiciel sous film
plastique devient le plus familier pour les utilisateurs, et constitue toujours aujourd'hui
une part importante du paysage informatique mondial. Il est cependant important
de remarquer que ce marché ne représente que 25% de la valeur totale du marché
du logiciel, le reste étant composé de logiciels personnalisés, développés sous
contrat, et de logiciels maisons [OECD 02].

Le FLOSS comme modèle de licence1

Dans la lignée de la tradition instaurée par les instituts universitaires tel que le MIT,
Richard Stallman a fondé en 1983 la Fondation du Logiciel Libre (FSF - Free Software
Foundation) dans le but de trouver un moyen de conserver la liberté pour les

1 Richard Stallman et la FSF ont introduit le terme « free software ». Plus tard, l'Initiative Open Source a
proposé le terme « open source software », pour dit-on éviter toute confusion avec le terme anglais
« free », que la FSF utilisait plus particulièrement pour préserver le concept sous-jacent de liberté. Le
terme « logiciel libre » a été introduit pour la même raison, et utilisé en particulier en Europe. Le terme
« FLOSS » a été introduit par Richard Gosh dans le cadre du projet financé par l'UE, « Logiciel Libre et
Open Source : rapport et étude » entamé en 2002 pour rassembler tous les termes désignant le logiciel
libre et open source comme décrit dans cette section. Dans ce rapport nous utiliserons principalement
le terme FLOSS.

6
utilisateurs d'étudier, de comprendre et de modifier les logiciels, en liaison directe
avec la culture pirate informatique d'ouverture et de partage de l'information.
L'objectif de la FSF était de créer une toute nouvelle mise en place du système
d'exploitation Unix, à ce moment-là une référence importante pour les plus grandes
entreprises et centres de recherche. Dans ce but, Stallman et beaucoup d'autres ont
créé un développement et un environnement d'exploitation complets, pour lesquels
à la fin des années 1980 le noyau (le centre sous-jacent d'un système d'exploitation)
était le seul composant manquant. Ce vide fut bientôt comblé, en 1991, par deux
équipes différentes : les efforts menés par Linus Torvalds ont donné naissance au
noyau Linux, tandis que William et Lynne Jolitz ont écrit une série dans le Journal du
Dr. Dobbs sur le moyen de transférer Unix BSD sur des ordinateurs i386, créant ainsi la
base pour un système d'exploitation complet gratuit pour les ordinateurs personnels
modernes [DB 00].

La Fondation du Logiciel Libre met particulièrement l’accent sur les « quatre libertés »
sous-jacentes :

. La liberté d'exécuter le programme – pour quelque usage que ce soit

. La liberté d'étudier le fonctionnement du programme, et de l'adapter à ses besoins
(liberté 1). Pour ceci, l'accès au code source est une condition préalable.
. La liberté de redistribuer des copies de manière à pouvoir aider son prochain
(liberté 2)
. La liberté d'améliorer le programme et de publier ses améliorations afin que la
communauté entière en bénéficie (liberté 3). Pour ceci, l'accès au code source est
une condition préalable.

C'est pour cette raison que la FSF a créé une série de « licences de logiciels libres »,
dont la GPL (general public license) et la LGPL (lesser general public license), qui
sont les plus couramment utilisées, tant en termes de nombre de projets que de
nombre de lignes de code couvertes.

Malheureusement, trop souvent le terme « logiciel libre » est interprété comme

« gratuit », c'est-à-dire sans prix ; ce qui a contraint la FSF à introduire le slogan libre »
comme dans « liberté d'expression », pas comme dans « bière gratuite »2.
L'environnement du logiciel libre a évolué à grande vitesse, jusqu'au développement
d’environnements complets pour les utilisateurs tels que GNOME et KDE, et la
conception en 1998 de la marque déposée pour l’open source, créée pour offrir
une alternative plus pragmatique aux orientations quelque peu « politique » de la
FSF. La définition de l’Open Source se base sur une série e conditions :

Libre redistribution La licence ne doit pas empêcher de vendre ou de donner le

logiciel en tant que composant d'une distribution d'un ensemble contenant des
programmes de diverses origines. La licence ne doit pas exiger que cette vente soit
soumise à l'acquittement de droits d'auteur ou de royalties.

Code source Le programme doit inclure le code source, et la distribution sous forme
de code source comme sous forme compilée doit être autorisée. Quand une forme
d'un produit n'est pas distribuée avec le code source correspondant, il doit exister un
moyen clairement indiqué de télécharger le code source, depuis l'Internet, sans frais
supplémentaires. Le code source est la forme la plus adéquate pour qu'un

2 NdT : en anglais, le mot « free » veut dire libre, mais aussi gratuit, d'où la confusion possible

7
programmeur modifie le programme. Il n'est pas autorisé de proposer un code
source rendu difficile à comprendre. Il n'est pas autorisé de proposer des formes
intermédiaires, comme ce qu'engendre un préprocesseur ou un traducteur
automatique.

Travaux dérivés La licence doit autoriser les modifications et les travaux dérivés, et
leur distribution sous les mêmes conditions que celles qu'autorise la licence du
programme original.

Intégrité du code source de l'auteur La licence ne peut restreindre la redistribution

du code source sous forme modifiée que si elle autorise la distribution de fichiers
« patch » aux côtés du code source dans le but de modifier le programme au
moment de la construction. La licence doit explicitement permettre la distribution de
logiciel construit à partir du code source modifié. La licence peut exiger que les
travaux dérivés portent un nom différent ou un numéro de version distinct de ceux
du logiciel original.

Pas de discrimination entre les personnes ou les groupes La licence ne doit opérer
aucune discrimination à l'encontre de personnes ou de groupes de personnes.

Pas de discrimination entre les domaines d'application La licence ne doit pas limiter
le champ d'application du programme. Par exemple, elle ne doit pas interdire
l'utilisation du programme pour faire des affaires ou dans le cadre de la recherche
génétique.

Distribution de la licence Les droits attachés au programme doivent s'appliquer à

tous ceux à qui le programme est redistribué sans que ces parties ne doivent remplir
les conditions d'une licence supplémentaire.

La licence ne doit pas être spécifique à un produit Les droits attachés au programme
ne doivent pas dépendre du fait que le programme fait partie d'une distribution
logicielle spécifique. Si le programme est extrait de cette distribution et utilisé ou
distribué selon les conditions de la licence du programme, toutes les parties
auxquelles le programme est redistribué doivent bénéficier des droits accordés
lorsque le programme est au sein de la distribution originale de logiciels.

La licence ne doit pas contaminer d'autres logiciels La licence ne doit pas apposer
de restrictions sur d'autres logiciels distribués avec le programme qu'elle couvre. Par
exemple, la licence ne doit pas exiger que tous les programmes distribués grâce au
même médium soient des logiciels « open-source ».

Les deux groupes tiennent une liste des licences conformes aux termes de la
définition du Logiciel Libre, ou la liste des conditions pour utiliser le terme « open
source ». En fait, il existe plus de 50 licences identifiées pour « open source » ou
« logiciel libre », mais heureusement ces dernières peuvent être classées d'une
manière très simple comme [Sun 06, UU 05]:

. « reconnaître le mérite » : l’utilisation, la modification, et la redistribution sont

autorisées, mais le mérite à l'auteur d'origine est du en cas de redistribution.
Exemples: licence BSD, Licence Apache v2.

8
. « communiquer les changements » : l’utilisation, la modification, et la redistribution
sont autorisées, mais le code source pour tout changement doit être communiqué à
l'auteur d'origine, en cas de redistribution. Exemples: licences du style Mozilla (Mozilla
Public License).
. « tout communiquer » : l’utilisation, la modification, et la redistribution sont
autorisées, mais le code source de tout produit dérivé doit être communiqué, en cas
de redistribution. Exemple: GPL.

Lorsque le code de différents projets est mélangé et redistribué, le problème de la

compatibilité de la licence devient important. Une matrice extrêmement détaillée
avec une compatibilité de licence en regard de la GPL (y compris la licence GPLv3
récemment lancée) est disponible à [FED 07]. Dans tous les cas, dès qu'un produit est
lancé ou distribué, il est recommandé de demander conseil auprès d'un avocat
compétent dans les licences FLOSS et la propriété intellectuelle (idem pour les
lancements des logiciels propriétaires).

Le FLOSS comme modèle de développement

Tandis que FLOSS en tant que définition (couvre exclusivement le régime de licence,
par extension « l’ouverture » du code offre la possibilité de partager les efforts de
développement entre les différents groupes, d'une façon semblable à celle des
premiers groupes d'utilisateurs des années 1960. Dans ce sens, Eric Raymond a
présenté dans son journal d’influence « La cathédrale et le bazar » le concept du
développement réparti. Ainsi, il présente le contraste entre le style « bazar », par
lequel chaque développeur est libre de décider sur quelle partie du code travailler,
et l'approche « cathédrale » ou de développement formalisé, rigide et structurée
[Raym 00].

Même si le concept s'est rapidement installé, la réalité veut que les projets de
développement accomplis en collaboration tendent à être effectués dans un
continuum entre la cathédrale et le bazar. Par exemple, pour la plupart des grands
projets il existe une structure officielle (comprenant de nombreux sous projets, plus
ouverts à des participations externes), alors que d'autres sont strictement officiels
(par exemple, les projets qui utilisent le code FLOSS dans un environnement certifié,
tel que l’électronique aéronautique ou les systèmes critiques). Le point important
soulevé par Raymond est le fait que tant la programmation que les activités
auxiliaires, telles que la réparation de bugs et la production de documents, peuvent
être partagés par une grande communauté, en créant des « communautés de
logiciels virtuelles » qui fournissent volontairement des efforts et des ressources. Ceci
représente également un avantage pour une grande communauté d'utilisateurs
experts, qui peuvent également apporter leur contribution d'une manière
importante, comme présenté dans [VH 03, VH 05].

Lorsqu'une telle collaboration prend place, elle ne concerne pas toujours le code
source, comme cela est commenté dans [Jul 06] : « Au cours de l'année 2000,
cinquante participants externes à l’Open Cascade ont apporté leur aide sous
plusieurs formes : le transfert de logiciels vers d'autres systèmes (IRIX 64 bits, Alpha
OSS), la correction de défauts (pertes de mémoire…), la traduction du didacticiel en
espagnol, etc. À l’heure actuelle, il existe soixante-dix participants actifs et l'objectif
est d'en atteindre cent. Ces participants externes sont importants. L’Open Cascade
estime qu'ils représentent environ 20% de la valeur du logiciel ».

9
Une vision semblable a été présentée dans [Sei 06], où l’un des chefs du projet KDE3
a présenté les éléments qui participent de manière collective à KDE:

. Modèles
. Documentation
. Interaction Homme-ordinateur
. Marketing
. Assurance de Qualité
. Développement de logiciels
. Traduction

Si l’on considère la compatibilité globale du logiciel avec à la tâche, il est clair que
les participations ne concernant pas le code sont aussi importantes que celles qui le
concernent. Par exemple, les traductions, la documentation et la qualité globale
sont vitales pour que le logiciel soit adopté par les utilisateurs finaux dans le monde
entier.

Un autre exemple vient de [Mue 07], où le nombre de participants dans les sous-
projets Openoffice.org sont dénombrés :

3 KDE est un environnement de bureau complet, créé à l’origine comme alternative libre à
l’environnement Unix CDE, qui a ensuite évolué pour englober des bibliothèques, des logiciels
d’application et des supports de formation.

10
Comme l’on peut le déduire du graphique en aires, il existe approximativement
autant de participants ne contribuant pas au code source que de participants
travaillant sur le développement de produits et des projets connexes (directement
liés au programme source).

Cette forme de collaboration peut même exister entre des sociétés concurrentes.
Par exemple, des informations sur les faiblesses probables dans la sécurité sont
partagées en commun entre les différents vendeurs concurrents Linux. Ainsi, Mark
Cox de RedHat (une société de distribution de Linux largement utilisée) a analysé les
résultats de deux années de réparations d’incidents, et a réalisé que le plus grand
partage d'informations venait des autres confrères distributeurs FLOSS [Cox 07].

Ces dernières années, les entreprises ont commencé à adopter ce modèle de

collaboration pour développer des logiciels et des services, tantôt en complément à
des communautés volontaires, tantôt en entamant de nouveaux projets et en
fournissant des ressources substantielles pour leur suite. Cette dernière étape
(l'étape de commercialisation) est plus centrée sur la viabilité des modèles
d’entreprise adoptés par lesdites entreprises, et constitue le sujet principal du
chapitre 6.

11
 2. Dix mythes sur le logiciel libre et open source
En 1999, Tim O'Reilly, fondateur d'une célèbre maison d'édition orientée sur l’open
source, a présenté un discours à des cadres du Fortune 500 s’intitulant « Dix mythes
sur le logiciel libre et open source ». Étant donné que ces mythes sont encore
considérés aujourd'hui comme un obstacle pour l'adoption du FLOSS (comme le
montrent de récents rapports [CIO 07, ED 05, Forr 07]), nous essayerons de donner ici
une réponse pragmatique orientée PME à chacun d’entre eux.

1er Mythe : Il s’agit d’une histoire Linux-vs-Windows.

Les débats les plus récents sur le FLOSS se sont concentrés sur une perception du
« tout ou rien ». Par exemple, en introduisant le FLOSS dans une entreprise, une
migration complète du logiciel est souvent considérée comme nécessaire. Cette
situation, plus le fait qu'il n'existe qu'une connaissance limitée des projets FLOSS, à
l'exception de quelques-uns bien connus (comme Linux, Apache, OpenOffice.org),
a laissé croire que le FLOSS est principalement créé et ciblé comme un concurrent
direct des produits Microsoft. En réalité, il existe un nombre énorme de projets actifs
dans pratiquement tous les domaines informatiques, y compris des projets ciblés
entreprises (tels que les systèmes ERP). La plupart d'entre eux sont multiplateformes et
capables de fonctionner sur Microsoft Windows, le OS X d’Apple (lui-même basé sur
plus de 300 projets open source) ou Linux. Comme le montre l'Annexe 1, il existe plus
de 18.000 projets FLOSS suffisamment stables et mûrs pour être adoptés par les PME.

2e Mythe : le FLOSS n'est pas fiable ou ne reçoit aucun soutien

Ce mythe est basé sur l’idée commune que le FLOSS est développé exclusivement
par des bénévoles d'une manière non coordonnée ou déstructurée. Toutefois, cette
idée est erronée pour plusieurs raisons :

. L’idée du bénévole : il est vrai que les participations bénévoles constituent une part
importante (et parfois majoritaire) des projets à grande échelle. Cela dit, près de
50% des développeurs ont reçu une compensation financière pour avoir travaillé sur
des projets FLOSS, soit payée directement pour améliorer les projets, soit payée pour
les soutenir. Ceci a été démontré dans de récentes études [Gosh 05, Gosh 06] et

12
peut être déduit directement du fait que dans l'industrie du logiciel au sens large,
68% des produits de logiciel comprennent directement un code dérivé du FLOSS.

. Les programmeurs rémunérés sont meilleurs : même pour le pourcentage de

participations venant de bénévoles, il est communément perçu que celles-ci
seraient de moindre qualité, étant donné qu'il n'existe pas d'avantage financier pour
délivrer un logiciel de qualité. Ceci fait abstraction du fait que les avantages
intrinsèques sont dans de nombreux cas plus efficaces qu'une compensation
pécuniaire [Gosh 06], et du fait que parfois les utilisateurs souhaitent améliorer du
logiciel qu'ils utilisent [VH 03]. Ce second effet, appelé l'innovation ouverte, a été
démontré dans une étude passée comme ayant une influence importante. Ainsi,
près de 25% des innovations dans des domaines tels que la sécurité du logiciel, les
systèmes de cartes à circuits imprimés et le logiciel de bibliothèques ont été conçus
et introduits par des utilisateurs expérimentés. Ce même effet donne un feedback
essentiel sur la conception, étant donné qu'un grand projet recueille tant de bonnes
que de mauvaises expériences dans l'utilisation du logiciel (par exemple, la page
« Témoignages et d'Expériences4 » de l’Ubuntu de Linux, qui permet une forme de
« direction » ouverte du projet et l'identification de points à problèmes.

. Il n'existe aucun soutien : la plupart des projets à grande échelle sont liés à des
entreprises qui offrent un soutien rémunéré, d'une manière semblable aux entreprises
de logiciels propriétaires. La disponibilité d'un code source et les droits de le modifier
présentent également l'avantage supplémentaire que le soutien peut être obtenu
même pour des projets qui ne sont plus actifs depuis longtemps, ce qui diffère
complètement du logiciel propriétaire dans lequel aucune clause séquestre ne
figurait dans le contrat d'achat.

. Le FLOSS n’est pas fiable par nature : beaucoup pensent que le FLOSS, étant
développé de manière libre et déstructurée, est par nature de moindre qualité par
rapport aux logiciels propriétaires. En réalité, la plupart des projets FLOSS sont
organisés dans une structure semi stricte, et seuls les projets très modulaires sont « de
style bazar » par nature, ce qui permet un découplage interne à grande échelle.
Quoi qu’il en soit, l'impact du développement de style FLOSS a été évalué dans
plusieurs études, et nous avons trouvé par exemple dans [Suc 04] : « Nous soutenons
l'hypothèse selon laquelle le logiciel libre et open source encourage plus de
créativité. Le taux de croissance ou le nombre de fonctions ajoutées était supérieur
dans les projets open source par rapport aux projets closed source. Autrement dit,
l'approche open source peut être capable de fournir plus de fonctions dans le
temps que l'approche closed source. Les professionnels souhaitant saisir une part de
marché en fournissant des fonctions supplémentaires devraient envisager la
méthodologie open source pour atteindre ce but. En termes de défauts, notre
analyse montre que le taux de modification ou les fonctions modifiées en tant que
pourcentage des fonctions totales est plus élevé dans les projets open source que
dans les projets closed source. Ceci soutient l'hypothèse que les défauts peuvent
être trouvés et corrigés plus rapidement dans les projets open source que dans les
projets closed source, cela pouvant constituer un avantage supplémentaire pour
utiliser le modèle de développement open source ». Ces faits sont cohérents avec
les résultats des vendeurs d'outils d'identification de défaut de logiciels, tels que
Reasoning, qui ont réalisé que tandis que le nombre de bugs dans les premiers
lancements de projets va de pair avec les développements propriétaires, celui-ci

http://ubuntuforums.org/forumdisplay.php?f=103
4

13
s'améliore rapidement, et pour certains projets le nombre de défauts est
significativement inférieur à celui de la moyenne du code propriétaire [Reas 06a,
Reas 06b]5. Ce fait a également été confirmé par d'autres études, telles que les
rapports de Coverity.

Le fait que le FLOSS soit globalement fiable peut également déduit d’enquêtes telles
que [CIO 07], dans laquelle 79% des personnes interrogées ont répondu positivement
à l’affirmation « L'expérience de mon entreprise avec les produits open source autres
que Linux est tellement satisfaisante que nous envisageons d'étendre leur utilisation ».

Dans ce sens, il n'est pas surprenant que plusieurs projets FLOSS aient obtenu des
certifications de sécurité, ou aient été utilisés dans des appareils médicaux, des
systèmes de contrôle et dans l’électronique aéronautique. Par exemple, le système
VISTA, un système de soins électroniques à grande échelle développé par le
Département de la Défense des Etats-Unis pour ses propres hôpitaux de vétérans, est
à présent utilisé dans plus de 1000 hôpitaux et cliniques rien qu'aux Etats-Unis, ainsi
que dans bon nombre d'autres établissements à travers beaucoup de pays. D'autres
exemples comprennent l’utilisation de Linux dans les systèmes d'Image de
Résonance Magnétique Siemens pour les diagnostics, l’utilisation de l'environnement
open source ADACORE dans l’électronique aéronautique de vol, la certification
FIPS-140 de deux des plus importantes boîtes à outils de cryptage (OpenSSL et NSS),
et bien d'autres encore.

Si nous prenons comme exemple les niveaux d’intégration de la sécurité IEC 61508
[Daf 06-2]:

La Direction de la Santé et de la Sécurité au Royaume-Uni, dans une étude de 2002

[HSE 02] a démontré que Linux était suffisamment robuste, et qu'il pourrait être
certifié jusqu'à SIL3 avec peu d'efforts. Ceci le rendrait permettrait de l’utiliser dans
les annonces de contrôle du trafic aérien, les systèmes de contrôle des chemins de
fer et le processus de contrôle d'usines.

3e Mythe : Les grandes entreprises n'utilisent pas le FLOSS.

Il s’agit du mythe le plus facile à dissiper : mis à part les sociétés d'Informatique qui
font activement la promotion de logiciels open source tels que IBM, HP, Sun, Oracle
et autres, près de 86% des 1000 entreprises Fortune ont déployé ou testé le FLOSS, et
l’on retrouve le même pourcentage en Europe [Aug 04]. Parmi elles, 35% ou plus

« À un niveau de densité de 0.09 défauts par KLOC, la version de MySQL que nous avons examinée
5

possède un nombre de défauts à peu près six fois inférieur à la moyenne des projets propriétaires
comparables »

14
déploient plus de 20% de leurs systèmes comme FLOSS, tandis que 11% des
entreprises indiquent que plus de 20% de leurs logiciels sont des FLOSS. Alors que
l'utilisation dans l’infrastructure serveur centrique et Informatique est plus habituelle,
près de 26% des grandes entreprises citent l'utilisation de Linux, et un pourcentage
beaucoup plus grand indique l'utilisation de certains autres packages FLOSS, tels que
OpenOffice.org et Firefox sur Windows. Un fait curieux qui ressort également d'autres
études est que beaucoup d'entreprises et d'administrations publiques ne sont pas
conscientes de leur usage interne de FLOSS, tantôt par simple ignorance des termes
de la licence, tantôt parce que le produit est offert ou embarqué dans ce qui
semble être une offre propriétaire traditionnelle (par exemple, de nombreux produits
de sécurité et de réseau, ou de produits d'entreprises comme VMware ESX server,
utilisent le FLOSS de façon interne).

4e Mythe : le FLOSS est l’ennemi de la propriété intellectuelle.

Plusieurs aspects sont liés à ce mythe :

. La licence GPL est « virale » : la licence la plus largement utilisée possède une
clause particulière stipulant que lors de la redistribution d’un produit de logiciel
dérivé du code d’un logiciel GPL, le produit en entier doit être conforme aux
conditions de cette dernière. Ceci a incité certaines entreprises à prétendre
que « l'aspect viral de la GPL constitue une menace pour la propriété intellectuelle
de toute organisation qui en fait usage »6. En réalité, dans la plupart des cas, cette
clause offre simplement un moyen d’éviter l'appropriation d'un code sans
reconnaître les participations ou le mérite, ce qui est l’une des raisons pour laquelle
beaucoup de développeurs préfèrent la GPL à d'autres licences. Un simple usage
du FLOSS en soit n'exige aucune modification de la licence d'un logiciel développé
de façon interne, et la majorité des entreprises utilisent couramment un logiciel
propriétaire en plus du code de licence GPL, tel que le noyau Linux.

. La communauté des logiciels open source vole la propriété intellectuelle d'autres

entreprises : il s’agit là principalement de la suite d'une affaire juridique, au cours de
laquelle la société SCO a intenté un procès contre IBM en 2003. Ainsi, elle a accusé
IBM d’avoir abusivement inclus du matériel sous licence dans le noyau Linux. Dans la
plainte originale, il était mentionné qu’IBM « a utilisé les informations confidentielles et
propriétaires de SCO dans Linux, le système d'exploitation libre »7, et que plusieurs
millions de lignes du code du noyau de Linux avaient été volés du code source
d’Unix de SCO. Aujourd’hui, quatre ans plus tard, les juges ont rejeté la majorité des
plaintes, laissant moins de 300 lignes de code (principalement les codes d’interface
standards) encore sous examen, sur plus de 6 millions de lignes de code du noyau
Linux moderne. Récemment, Microsoft a publié des déclarations semblables. Ainsi,
6 Comme mentionné par Craig Mundie, vice président de Microsoft, dans un exposé à l'Ecole Commerciale Stern de
l'Université de New York en 2001. D'autres représentants de Microsoft tels que Bill Gates ont déclaré « il est impossible
pour une entreprise commerciale d'utiliser la GPL ou de bâtir quoi que ce soit grâce à elle », ou encore Steve
Ballmer : « Linux est un cancer qui s'accroche à la propriété intellectuelle de tout ce qu'il touche...si vous utilisez un
logiciel open source, tout le reste de votre logiciel doit être open source » (Interview accordée au Chicago Sun-
Times,2001).
7 Une copie de la plainte originale et une liste complète de documents sur cette affaire (ainsi qu'une
importante analyse) se trouvent sur le site GrokLaw, http://www.groklaw.net.

15
Steve Ballmer8, le Directeur Général de Microsoft, a déclaré que « ce produit (Linux)
utilise notre propriété intellectuelle brevetée », pour donner ensuite une estimation
chiffrée des brevets Linux et d'autres produits FLOSS enfreignant la propriété
intellectuelle de Microsoft. En réalité, ces projets structurés FLOSS sont soumis à des
politiques sévères pour accepter des correctifs et des participations externes. À titre
d'exemple, le projet Eclipse est soumis à un processus sévère de diligence requise,
qui couvre les participations externes, les affectations de droits de code, l'analyse du
code et la compatibilité de la licence. La Fondation Eclipse utilise également des
outils automatiques pour contrôler la copie du code, le scannage de mots-clés avec
portée juridique, et un examen minutieux du lancement avant la mise à jour du
code [Cam 06]. Des processus semblables sont en place dans d'autres projets FLOSS
[Rig 06].

5e Mythe : le FLOSS : une histoire de licences

Tandis qu’au sens strict du terme, un projet FLOSS est défini par sa licence, la plupart
des aspects open source sont réellement liés à l'ouverture et aux aspects du
développement accomplis en collaboration, comme décrit dans le chapitre 1.

6e Mythe : si je donne mon logiciel à la communauté FLOSS, des milliers de

développeurs vont tout à coup commencer à travailler pour moi
gratuitement.

Impossible de garantir que le simple fait de « décharger » le code source sur Internet
fera naître un projet FLOSS. De plus, plusieurs exemples en ce sens se sont révélés
négatifs (parce que la communauté risque de considérer cela comme un « vidage
d’ordures »). En réalité, pour qu'une certaine collaboration prenne forme, il faut en
premier lieu qu’une bonne communication, une stratégie d'interaction et des efforts
se mettent en place. De plus, investir dans la création d'une communauté et dans la
dispersion des efforts augmente la probabilité d'un partage des efforts dans les deux
sens. Il est important de mentionner que des études comme OSSWatch ou [CIO 07]
ont démontré qu'une part importante des entreprises et des administrations
publiques (entre 14% et 25%) apportent des correctifs ou participent de manière
active aux communautés FLOSS.

7e Mythe : le FLOSS ne concerne que les programmeurs, étant donné que la

majorité des utilisateurs ne regarde de toute façon jamais sous le capot

Le fait que la plupart des utilisateurs ne soient pas intéressés par le code source ne
veut pas dire que disposer d'un code source est inutile. Ainsi, plusieurs aspects positifs
peuvent être identifiés :

. La disponibilité du code permet aux utilisateurs finaux de rémunérer éventuellement

quelqu'un pour des modifications ou pour poursuivre la maintenance, même quand
le projet FLOSS original disparaît ou n’est plus actif.

8 http://blogs.zdnet.com/hardware/?p=54

16
. « Sous le capot » ne se trouve pas seulement un code, mais également de
nombreux autres aspects en dehors de ce dernier, qui sont vitaux à un projet,
comme les traductions, la documentation, les exemples, etc. Beaucoup d'utilisateurs
peuvent participer à de tels aspects même si ils ne sont pas programmeurs.

. Pour certains projets, disposer du code permet une diminution importante du coût
ou augmente de façon significative la flexibilité de la solution offerte. Par exemple,
dans le projet MuleSource (un système intergiciel sophistiqué), on constate que 64%
des utilisateurs réalisent au moins une modification du code source.

8e Mythe : gagner de l'argent avec FLOSS est impossible

Beaucoup de chercheurs ont même déclaré d'une manière ou d'une autre que la
nature libre de la disponibilité du code exclut toute possibilité d'exploitation
commerciale. Voici par exemple un extrait de [Hahn 02] : « La GPL empêche en
réalité les entreprise à but lucratif d’utiliser quelque partie du code que ce soit, étant
donné que tous les produits dérivés doivent également être distribués sous la licence
GPL ». Bien entendu, ceci est incompatible avec les résultats économiques obtenus
par des entreprises comme HP (qui a fait état en 2003 de plus de 2.5B$ de revenus
liés à Linux), ou les 400M$ de revenus rapportés par RedHat. Dans [Gosh 06] il est
estimé que :

. Définis de façon générale, les services liés au FLOSS pourraient atteindre une part
de 32% de tous les services informatiques d'ici 2010, et la part liée au FLOSS dans
l'économie pourrait s'élever à 4% du PNB européen d'ici 2010.

. Le FLOSS soutient directement une proportion de 29% des logiciels développés de

manière interne en Europe (43% aux Etats-Unis).

. Le FLOSS fait gagner potentiellement à l'industrie plus de 36% des investissements en

R&D de logiciels, ce qui peut entraîner des bénéfices accrus ou être dépensés plus
utilement dans d’autres innovations.

. La valeur notionnelle de l'investissement en Europe dans le logiciel FLOSS est de 22

milliards d’euros (36 milliards aux Etats-Unis), ce qui représente 20.5% du total des
investissements dans les logiciels (20% aux Etats-Unis).

Des chiffres semblables sont prévus par des groupes de consultance indépendants
comme Gartner : dans [Gar 06], il est prévu que d'ici deux ans, près de 25% du total
du marché du logiciel seront basés sur le FLOSS (soit par l'intermédiaire de
fournisseurs externes, ou par des développements internes).

17
Un autre aspect pertinent est que la plupart des entreprises ayant adopté le FLOSS
font état d'économies de coûts significatives. Celles-ci peuvent être directement
consacrées à des services professionnels externes, ou inclues dans une marge de
profit supplémentaire. Par exemple, dans [Inf 07] :

Dans une enquête menée auprès de 800 directeurs de l'Informatique, InfoWorld a

constaté que parmi tous ceux ayant adopté le FLOSS, ceux qui ont recueilli les
bénéfices les plus significatifs sont ceux qui ayant déployé le plus de produits open
source, 24% des « grands utilisateurs » (plus de 100 produits) faisant état d'économies
de plus de 60%. Il est également intéressant de remarquer que seul un faible
pourcentage (moins de 9%) déclare ne pas avoir eu d'économies, ou que les coûts
ont augmenté en comparaison avec les logiciels propriétaires.

9e Mythe : le mouvement FLOSS n'est pas viable, car les gens cesseront de
développer des logiciels open source dès qu'ils verront que les efforts des
autres sont bien mieux payés

Ceci est relié au 2e mythe, l'idée selon laquelle le FLOSS est développé par des
bénévoles, et que les entreprises ne peuvent bénéficier que d'une façon parasitaire
du programme développé gratuitement. Comme examiné dans cette partie, en
réalité la majorité des entreprises et des bénévoles participent d'une façon

18
collaborative et non concurrentielle ; de même, la licence la plus largement utilisée
(la GPL) a contraint les entreprises à inverser leurs efforts en rendant la diffusion du
code source obligatoire lors de chaque diffusion du code dérivé des projets GPL.

10e Mythe : le FLOSS tente de rattraper Microsoft et le monde des affaires

Le concept de l'innovation du logiciel est vraiment ancré dans deux aspects

différents : l'innovation technique et l'innovation dans le domaine. Alors que
l'innovation technique est principalement invisible pour l'utilisateur, « l’innovation
dans le domaine » (par exemple un nouveau type d'application) est clairement
évidente. C’est peut-être pour cette raison que l’on pense que la plupart des
logiciels FLOSS sont une sorte de copie de quelque autre logiciel propriétaire
(bureautique).

En réalité, au contraire, la majorité des logiciels propriétaire ne sont pas innovants

sous cet aspect. Alors que très peu d'exemples de nouveaux concepts (comme
l'idée de tableau de Dan Bricklin) peuvent être rencontrés, les principaux logiciels
correspondent aux travaux que les gens exécutent journellement, et il existe comme
tel un gros désavantage pour l'innovation. Très peu d'études comparent le FLOSS à
des logiciels propriétaires d'une manière objective, et l'une d'elle est [Kli 05] :

Le résultat final est que du point de vue de l'innovation dans le domaine, près de
12% des projets le panel sont considérés innovants, un pourcentage comparable à
celui du marché du logiciel propriétaire. En ce qui concerne l'innovation technique,
[Suc 04] indique que « Nous soutenons l'hypothèse selon laquelle le logiciel open
source encourage plus de créativité. Autrement dit, l'approche open source peut
être capable de fournir plus de fonctions dans le temps que l'approche closed
source ».
Une autre étude, [ARC 07], indique que « les entreprises utilisant des packages
bureautiques autres que Microsoft sont plus innovantes (indice moyen 0,2) que celles
que faisant uniquement usage de Microsoft (indice moyen 0,15). La corrélation entre
l'innovation et l'utilisation de logiciel open source au niveau de l’entreprise est
également confirmée dans des études comparatives internationales menées par
des chercheurs de l'Université d'Harvard »9.

9 Emphase dans le texte original.

19
 3. Modèles élémentaires d'adoption du FLOSS
Dans une entreprise, la valeur du FLOSS peut provenir de plusieurs domaines
différents :

remplacement/migration élémentaire : l'utilisation du FLOSS dans

l'infrastructure Informatique, souvent en remplacement d'un logiciel
propriétaire
nouveau développement: l'introduction du FLOSS pour un nouveau projet
interne à l'entreprise (adoption)
vente de services basés sur le FLOSS
vente de produits comprenant le FLOSS comme un composant majeur

Dans ce sens, une entreprise peut trouver le FLOSS utile d'un point de vue tactique
(le FLOSS est plus facile à mettre en œuvre, et engendre moins de contraintes qu’un
vendeur traditionnel, ou peut aider à introduire des produits sur le marché dans un
délai plus court) ou d'un point de vue stratégique (création de nouveaux marchés,
adoption de plusieurs modèles commerciaux). Pour être viable, une entreprise doit
adopter un modèle commercial permettant de traduire l'adoption du FLOSS en une
diminution des coûts ou une augmentation des revenus, et doit également prendre
en compte le fait qu'au moins une partie de la communauté participante peut se
trouver hors du contrôle de l'entreprise (comme cela arrive couramment dans des
projets FLOSS à grande échelle, la majorité des participants ne travaillant pas
uniquement pour une entreprise).

L’échelle d’adoption du FLOSS

Ces différentes zones correspondent à des étapes individuelles dans l’échelle

d’adoption du FLOSS, et peuvent être résumées comme suit (modifié de [Car 07]) :

20
La première étape (utilisation) concerne une simple adoption ou migration,
habituellement sans autre contact avec la communauté, de l’un ou plusieurs
packages FLOSS. Cette adoption se fait dans de nombreux cas à la base,
directement par les employées, et se concrétise dans un souci d’exploration ou de
réduction des coûts. De nombreux exemples de packages adoptés sont liés aux
applications de bureautique, telles que le navigateur Firefox ou l’application de
productivité personnelle OpenOffice.org. Dans certains cas, de petits serveurs
d’application spécialisés sont introduits, tels que les serveurs mails ou web pour
introduire des applications web.

A ce stade, il n’y a habituellement pas de contribution envers la communauté, qui

dans de nombreux cas n’est pas encore considérée comme un homologue dans
l’interaction potentielle. Cependant, la majorité des entreprises ayant commencé à
adopter le FLOSS pour leur infrastructure informatique interne l’étendent de manière
active. Ainsi, une enquête [CIO 07] montre que parmi les entreprises ayant adopté
Linux, 65% ont l’intention d’étendre son utilisation, tandis que seul 1% ont l’intention
de la réduire. Ces résultats positifs ont tendance à rendre le FLOSS plus familier en
général ainsi que le modèle de collaboration sous-jacent, et à faciliter la mise à jour
des étapes successives.

La seconde étape (« participation ») implique une implication active de l’entreprise

dans le développement du projet FLOSS adopté. Cette participation peut s’exprimer
directement en termes de code ou de présence à des évènements, indirectement
par le sponsoring, ou simplement par la promotion du projet. Cette étape nécessite
un support explicite de la direction, et offre des retours positifs aussi bien pour le
projet que pour l’entreprise (qui réduit le coût de l’implémentation de nouvelles
fonctionnalités en partageant le coût de développement avec la communauté). Il
existe également une reconnaissance explicite de la participation et des activités
des développeurs internes, et de leur interaction avec les projets FLOSS. Un exemple

21
d’entreprise se trouvant à cette étape est Apple (OSX tire profit de plus de 340
projets FLOSS différents).

Au cours de la troisième étape (« défense »), l’entreprise base une partie importante
du modèle commercial sous-jacent sur les projets FLOSS, et consacre des efforts
considérables à la participation aux activités. Les activités basiques de support lors
de l’étape de participation sont renforcées et étendues afin de faire de l’entreprise
un point de gestion clé, s’occupant non seulement de participations produites au
niveau interne, mais également des développeurs. Ceci fait de l’entreprise une
partie beaucoup plus grande du projet, et offre de plus nombreuses opportunités
commerciales grâce à cet élargissement.

La quatrième étape (« collaboration et redéfinition ») est caractérisée par une

extension du modèle de coopération, à partir d’une collection séparée de projets
individuels vers des efforts coordonnés en vue d’influencer le marché et la
perception de l’environnement par le client. Non seulement l’entreprise modifie la
plus grande partie de sa structure interne pour accommoder les processus de
développement, mais encourage également la création d’un réseau de partenaires
et de projets indépendants, considérés comme des élargissements potentiels de
l’activité de l’entreprise (même si certains de ces projets peuvent devenir des
concurrents potentiels).

Le coût et les activités spécifiques à chaque étape peuvent être résumés comme
suit :

Étape Principaux centres de coût

Utilisation Identification d’un logiciel
potentiellement intéressant, adoption,
migration, formation
Participation Période de développement, sponsor
Défense Période de développement, sponsor,
interaction communautaire, support à
des tierces parties
Redéfinition Période de développement, projet et
coordination

Il peut être étonnant que parmi les principaux centres de coût de la première étape
(« utilisation »), l’identification du logiciel applicable est proéminente. Ceci est
confirmé par des études indépendantes, telles que le projet de migration EU COSPA.
En utilisant des données de [COS 05], nous constatons que le « processus de
recherche » (qui implique à la fois des recherches pour le logiciel et pour la
documentation) est responsable d’environ 40% des coûts de support. Dans certains
cas, il dépasse même les coûts généraux de formation d’une migration à grande
échelle.

22
 4. Trouver et sélectionner le logiciel
Comme cela a été brièvement mentionné dans le chapitre précédent, le processus
de sélection du logiciel est souvent négligé, mais est un composant extrêmement
important d’une migration vers le FLOSS ou de l’adoption du FLOSS. Comme
mentionné dans l’Annexe 1, il existe plus de 18000 projets open source mûrs et
stables, et la majorité d’entre eux ne dispose pas de budget « promotionnel » ou ne
sont pas soutenus par des entreprises pouvant fournir un soutien de marketing ou de
diffusion.

Trois étapes différentes doivent être envisagées pour réussir à identifier un ensemble
de packages FLOSS :

identifier vos besoins

chercher les packages correspondant à vos besoins fonctionnels
sélectionner le package approprié à partie de l’ensemble adéquat

La première étape est souvent négligée, mais elle est cruciale pour une adoption
réussie. Dans de nombreux cas, il n’existe pas d’accord parfait pour un produit
propriétaire donné, mais des alternatives tout aussi bonnes, exécutant tout aussi bien
l’activité nécessaire (et parfois mieux). Dans ce sens, une liste de fonctions
« nécessaires » et « utiles » peut constituer une première étape pour la sélection.

Après avoir rédigé la liste, il est nécessaire de trouver les packages pouvant
répondre à vos besoins. Il existe plusieurs sites Internet importants offrant des
informations sur le logiciel disponible, à la fois de façon générale (par exemple
SourceForge, qui agit principalement comme un référentiel de projets) et de façon
détaillée, par des revues et des comparaisons avec le logiciel propriétaire.

Sites basés sur Forge :

Ces sites fournissent principalement du support et des services de téléchargement,

et hébergent un nombre de projets allant de 150000 (SourceForge) à quelques
centaines. Une fonction de recherche intégrée est possible. La plupart sont basés sur

23
le code SourceForge, sa nouvelle implémentation (GForge), ou sur des plateformes
collaboratives de développement offrant des services similaires (stockage,
communication par email, version du code et support de modification, recherche
de bugs). Voici certains de ces sites :

http://sourceforge.net/
http://savannah.gnu.org/
https://gna.org/
http://alioth.debian.org/
http://www.berlios.de/
http://codehaus.org/

Sites d’annonces de logiciel :

Ces sites sont principalement de nouveaux agrégateurs, qui offrent des informations
détaillées sur des versions récentes d’un package FLOSS, ainsi que des informations
sur les licences, les pages d’accueil et des captures d’écran.
http://freshmeat.net/
http://sourcewell.berlios.de/

Liste de logiciels équivalents :

http://www.linuxrsp.ru/win-lin-soft/table-eng.html
http://www.osalt.com/

La plupart des diffusions Linux comprennent également un outil de recherche du

package, comme Debian ou l’outil Synaptique d’Ubuntu :

24
Cet outil offre du support de recherche et d’installation pour tous les packages
pouvant être installés, inclus dans les « référentiels » de diffusion, les sites spécialisés
offrant des packages des projets FLOSS disponibles. Les référentiels sont
habituellement divisés en « stables » et « instables », pour offrir aux utilisateurs le choix
entre le logiciel stable et la dernière version (avec les dernières caractéristiques, mais
pas testé en profondeur). Il est important de remarquer qu’aujourd’hui aucune
diffusion moderne ciblée utilisateur exige que ce dernier voie ou interagisse avec le
code source FLOSS. Dans ce sens, pour installer un package il est nécessaire de
procéder à la compilation du code ou à des activités similaires, le package lui-
même devant être considéré comme expérimental, et son adoption devant être
limitée là où il existe un support interne et spécialisé.

Une fois qu’un ensemble d’applications potentiellement utiles a été définin, il est
fondamental de procéder à une évaluation des différentes applications. Cela peut
être fait en appliquant la méthode QSOS, créée dans le contexte du projet de l’UE,
disponible sur http://www.qsos.org . Le projet tire projet des activités précédentes
dans le même domaine, comme l’Open Source Maturity Model de Navica, OSMM
de CapGemini ou les Business Readiness Ratings, et utilise une approche en 4
étapes :

La méthode est divisée en plusieurs étapes, l’étape « définition » étant utilisée pour
définir l’élément utilisé dans les étapes évaluation/sélection/qualification. La
définition est basée sur les éléments suivants :

Familles de logiciels : classification hiérarchique des domaines du logiciel et

description des grilles de fonctionnalités associées à chaque domaine
Type de licences : classification des licences libres et open source
Types de communautés : classification des organisations de communautés
existant autour d’un logiciel libre et open source, et en charge de son cycle
de vie

25
L’étape d’évaluation est faite en deux étapes, la première étant la collecte
d’informations pertinentes et factuelles sur le projet FLOSS (appelée dans la
terminologie QSOS la « carte d’identité »), la seconde étant la création d’un
formulaire d’évaluation, basé sur trois critères :

Couverture fonctionnelle
Risques du point de vue de l’utilisateur
Risques du point de vue du fournisseur de service

La carte d’identité collecte les données suivantes :

Informations générales :

Nom du logiciel
Référence, date de création, date de lancement de la carte d’identité
Auteur
Type de logiciel
Brève description du logiciel
Licences auxquelles le logiciel est soumis
URI du projet et site de démonstration
Systèmes d’exploitation compatibles
Origine du fork (si le logiciel est un fork)

Services existants :

Documentation
Nombre d’offres de support contractuelles
Nombre d’offres de formation
Nombre d’offres de consultance

Aspects fonctionnels et techniques :

Technologies d’implémentation
Prérequis techniques
Fonctionnalités détaillées
Calendrier de lancement

Synthèse :

Tendance générale
Commentaires

L'évaluation est basée sur une évaluation fonctionnelle, avec une règle de cotation
qui utilise le 0 pour indiquer une fonctionnalité qui n'est pas couverte par le projet
FLOSS, le 1 pour une couverture partielle et le 2 pour une couverture complète (le
produit exécute la fonctionnalité demandée). Voir dans l’Annexe 2 la liste complète
des tables de cotation.

Après chaque évaluation individuelle, deux critères de sélection différents peuvent

être appliqués : strict (élimination directe dès que le logiciel ne satisfait plus aux

26
demandes formulées dans l'étape de qualification) ou lâche (plutôt que d'éliminer
les logiciels non-éligibles, il les classe en mesurant les vides au moyen de filtres
d'application).

L'approche la plus pertinente pour les PME se retrouve dans la sélection lâche, étant
donné que la stricte peut dans plusieurs cas ne pas délivrer de solution appropriée.
L'approche lâche utilise deux pondérations, une pour la fonctionnalité :

Et une pour le risque de l'utilisateur :

27
Une autre partie du projet QSOS, l'outil O3S offre un graphique et une comparaison
simples :

28
 5. Meilleure méthode pour l'adoption du FLOSS
La procédure de migration et d'adoption est un effort complexe, multidisciplinaire
qui touche à différents domaines et exige une totale compréhension de la façon
dont les automatisations de processus individuels sont composés et réalisés et
comment les gens interagissent avec des systèmes Informatiques dans leur travail
journalier. Dans ce sens, une migration FLOSS est un effort important, et ainsi la
plupart des efforts compliqués peuvent facilement échouer. Il existe plusieurs
obstacles dans la réalisation d'une migration, et certains de ces obstacles peuvent
être facilement évités en recourant à des pratiques simples. La plupart des difficultés
ne sont pas vraiment techniques par nature, mais organisationnelles, et exigeront
plus d'effort de la part de la direction supérieure. L'impact social de la migration est
un autre aspect important de la migration (comme l'adoption de l'utilisateur), qui
peut exiger une attention particulière.

Directives de gestion

La principale ligne de conduite pour réussir une migration vers le FLOSS commence
toujours par une évaluation claire du paysage Informatique, une vue claire des
besoins et des avantages de la transition et du support continu. Les différences des
modèles de développement OS et du support peuvent exiger un changement
important dans la manière dont le logiciel et les services sont expliqués et obtenus, et
en général un déplacement de responsabilité d'entreprises externes vers le
personnel interne.

S’assurer de l'engagement de la direction pour la transition

Le support et l'engagement de la direction ont à de nombreuses reprises été

identifiés comme l'un des variables les plus importants pour la réussite d'efforts
Informatiques complexes, et les migrations FLOSS ne sont pas une exception. Cet
engagement doit être garanti pendant une période de temps suffisante pour couvrir

29
la totalité de la migration. Ceci signifie que dans des organisations où les directeurs
de l'Informatique changent souvent, ou dans lesquelles la direction change pendant
des périodes de temps fixes (par exemple, dans les administrations publiques dans
lesquelles des changements arrivent fréquemment) il doit exister une procédure en
place (pour transmettre la direction de la migration. L'engagement devrait
également s'étendre au financement (étant donné que les transitions et la formation
exigeront des ressources, tant monétaires qu'internes). La meilleure façon d'assurer
une bonne coordination est de désigner une équipe disposant d'expériences
diverses (de direction et technique) pour délivrer un rapport continu et assurer la
direction journalière.

Point de résolution des problèmes : si les seules personnes travaillant sur la

planification de la migration viennent de l'Informatique/MIS, il peut y avoir une
insuffisance d'informations de la direction supérieure et de planification du
financement pour la poursuite de la migration après l'étape initiale.

Préparer une vue d'ensemble de ce qui est attendu de la migration ou de

l'adoption, y compris des critères mesurables

La transition peut débuter pour plusieurs raisons, y compris un meilleur contrôle des
coûts Informatiques, l'indépendance à l'égard des fournisseurs, la flexibilité ou le
support de normes de données open. Pour être sûr que la migration produit
réellement des avantages ou est conforme au projet de migration, il est essentiel de
connaître à l'avance les critères qui seront utilisés pour évaluer les progrès. Ces
exigences doivent être réalistes, en particulier les attentes de diminutions TCO
doivent être comparées avec les données publiques disponibles pour comparaison.

Point de résolution des problèmes : si le seul avantage perçu résulte du fait que « le
logiciel provient librement du réseau », il peut y avoir une série de suppositions
erronées qui aboutiront probablement à un jugement négatif de la migration.

S’assurer que le programme est réaliste

L'introduction d'une nouvelle plateforme Informatique exigera toujours une quantité

de temps importante. Par la méthode empirique, le temps pour réaliser une transition
entière vers le FLOSS peut être considéré comparable à celui de l'introduction d'un
grand ERP pour une nouvelle entreprise (application pour la planification des
ressources de l'entreprise). Pour de plus petites transitions, l'effort de temps devrait
être réduit en conséquence.

Point de résolution des problèmes : quand la durée de la migration est mesurée en

jours, et qu'aucun effort après la migration n'est planifié, la procédure peut être
contrainte de s'arrêter après que les ressources planifiées auront été utilisées.

Vérifier la passation de marché actuelle de logiciel/de l'Informatique et la

procédure de développement

30
Comme l'effort de mise en œuvre se déplace d'un logiciel commercial vers un
logiciel open source, la passation de marché et la procédure de développement
nécessitent d'être mises à jour en conséquence. En particulier, la concentration peut
se modifier d'achat vers les services, étant donné que il y a moins d'achat de logiciel
« prêts à l’emploi » (acheté commercialement), et ce changement peut exiger des
modifications dans la façon dont le budget Informatique interne a été alloué.

Les logiciels développé) de manière interne exigeront une transition de portage (?)
ou de transfert vers le nouveau logiciel qui est soit une plateforme multiple ou des
interfaces normales d'utilisation accessibles (par exemple, les applications Internet),
et ceci devrait être tenu en compte dans le projet Informatique global.

Point de résolution des problèmes : Si aucun changement de passation de marché

ou de développement n'est projeté, la direction peut ne pas avoir compris la portée
des modifications requises pour l'adoption du FLOSS.

Rechercher des conseils ou des informations sur des transitions similaires

Etant donné que le nombre d'entreprises et d'administrations ayant déjà réalisé une
migration est à présent considérable, il est facile de trouver des informations sur ce
que l'on espère et sur la façon de procéder. Dans ce sens, le projet COSPA a
développé une base d'informations en ligne qui est accessible sur le site principal de
COSPA (http://www.cospa-project.org), les administrations publiques peuvent
également contacter leur centre local de Compétence Open Source, qui fournira
les informations et le support pour la procédure de migration.

Eviter une transition de « grand changement » et préférer des migrations

progressives

La majorité des migrations à grande échelle qui sont réalisées en une grande étape
unique (impliquant le changement abrupt d'un environnement Informatique vers un
autre) sont habituellement caractérisées par des coûts de support et techniques
extrêmement élevés. Si le besoin de support de plus d'un environnement augmente
le coût de support et de gestion, des migrations « en douceur » ou progressives
apportent habituellement une meilleure expérience globale pour les utilisateurs et
ont pour résultat un bouleversement minimal sur les procédures de l'entreprise.

Un exemple de migration en douceur peut débuter par la migration des applications

du côté des serveurs, qui sont habituellement courantes ou basées sur réseau, et
donc plus faciles à remplacer, en laissant les applications bureau et utilisateurs en
dernier. Un tel procédé peut être représenté comme suit : [KBST 06]

31
32
Nommer au moins une personne pour interagir avec la communauté OSS ou
le vendeur OSS, et essayer de trouver des sources d'informations en ligne

L'avantage important de OSS est la disponibilité de ressources libres en ligne, sous la

forme de bases d'informations, de listes d'abonnés, de wikis (sites en collaboration)
qui peuvent donner un support substantiel dans beaucoup de cas comparables aux
offres commerciales. Le plus grand problème est d'identifier de telles sources
d'informations. Dans ce sens désigner les ressources à trouver, classifier et interagir
avec de telles sources est un moyen de diminuer le coût du support. Une façon
courante de donner une source unifiée d'informations est de créer une petite page
sur Intranet comprenant des liens vers des ressources en ligne.

Point de résolution des problèmes : si personne ne sait où trouver des informations sur
les outils qui sont utilisés, ou si chacun doit faire par soi-même des recherches sur des
sites Internet pour trouver des conseils d'utilisation.

Directives techniques

Une différence importante dans les adoptions du FLOSS est le modèle de

développement différent adopté par la majorité des projets open source, et la
différence dont l'adoption et les mises à jour sont traitées, pour réduire autant que
possible les problèmes d'interopérabilité.

Comprendre la façon dont OSS est développé

La majorité des projets sont basés sur un modèle de développement en

coopération, par un noyau de développeurs délivrant la majorité du code
(habituellement travaillant pour une société commerciale) et un grand nombre de
participants en-dehors de ce noyau. Ce modèle de développement livre un code
de grande qualité et un cycle de développement rapide, mais il exige également
un effort important dans le dépistage de modifications et de mises à jour. L'adoption
d'un package OSS devrait être proposé :

Quand le projet lui-même est « en vie », c'est-à-dire qu'il possède une

communauté de développement active. Voir les chapitres précédents sur la
manière de choisir et d'analyser un projet de développement.

Quand il existe une nette distinction entre un logiciel « stable » et « instable ».

Dans beaucoup de projets, il existe deux courants distincts de
développement, l'un consacré à l'intégration des dernières modifications et
suppléments, et l'autre centré sur l'amélioration de la stabilité et les
réparations de bugs. Périodiquement, les développeurs « gèleront »" un
développement pour transformer la version instable en une version stable, et
créer le développement d'une nouvelle version d’avant-garde. Cette
distinction permet aux développeurs de donner satisfaction tant aux
utilisateurs désireux d'expérimenter la dernière fonctionnalité, et ceux qui
utilisent le logiciel pour des opérations journalières, mais il exige un effort de
plus pour recueillir les informations et les nouvelles versions.

33
Si de nouvelles fonctionnalités ou corrections sont nécessaires, il peut être plus facile
de demander une version commerciale bénéficiant de support du logiciel. Dans
beaucoup de cas, le vendeur commercial participera également financièrement
au projet open source.

Point de résolution des problèmes : quand le directeur IT des développeurs pense

que OS est une sorte de logiciel commercial que quelqu'un a placé gratuitement sur
Internet, et qu’il « fonctionne, tout simplement ».

Réaliser un examen complet du logiciel et du matériel qui seront touchés par

la migration, et déterminer les fonctionnalités que la société recherche

Une migration ne peut être réussie si la situation de départ n'est pas connue. La
majorité des entreprises et administrations n'ont pas de procédure en place pour
contrôler les plateformes de logiciels et de matériels, et sont donc incapables de
quantifier le nombre d'outils et de logiciels qu'il est nécessaire de remplacer ou
d'intégrer dans une migration OSS. La procédure d'examen doit également tenir
compte du nombre d'utilisateurs compétents, de l'utilisation moyenne dans
l'organisation, et si le logiciel utilise des protocoles de communication libres ou
fermés et des formats de données. Cet examen sera à la base de la décision de
quels utilisateurs migreront les premiers, et pour prendre en compte le coût du
redéveloppement du logiciel ou de la migration vers un format autre de données.
Des outils d'inventaire automatique de logiciels sont facilement disponibles, et
peuvent diminuer le coût de réalisation de l'inventaire et permettre un contrôle
précis des logiciels installés (donc diminuer le coût d'entretien).

Certains aspects qui devraient être examinés sont :

Les formats de données utilisés, tant au niveau de l'échange de

documentation, de la base de données qu'au niveau du protocole de réseau
La liste des applications utilisées, y compris celles développées de manière
interne, les macros et les documents actifs
Les fonctionnalités disponibles
Les défauts et les problèmes de l'infrastructure actuelle

Il est essentiel que le logiciel de migration puisse répondre aux mêmes exigences de
fonctionnelles que l'infrastructure Informatique actuelle, et normalement l'améliore
en termes fonctionnels ou dans la qualité inhérente (comme la disponibilité, la
fiabilité, la performance).

Utiliser la flexibilité d’OOS pour développer des adaptations locales

L'élément qui différencie OSS c'est la flexibilité et la liberté qui offre aux utilisateurs et
aux développeurs de créer des nouvelles versions ou des versions adaptées du
package. Cette flexibilité peut accroître fortement la valeur perçue d’OSS, par
exemple il est possible de créer des packages personnalisés qui comprennent des
configurations locales, des polices particulières et d'autres équipements
supplémentaires comme des macros préétablis, et des formats habituellement
utilisés dans la société. De même, l'apparence habituelle et la sensation peuvent

34
améliorer de façon importante l'acceptation par l'utilisateur, tant par la présentation
d'un bureau plus agréable à regarder, et par le maintien de liens habituels et
d'accès aux menus.

Cette personnalisation peut être intégrée d'une façon simple dans la majorité des
diffusions Linux, ou en créant un référentiel local de logiciels. Il faut remarquer que
dans beaucoup de cas, il n'est pas nécessaire de délivrer un logiciel ou un code,
étant donné que la plupart des adaptations sont liées au choix du package
approprié, à la modification de l'apparence graphique, ou à la fourniture de formats
et de présélections.

Il existe beaucoup plus de logiciels disponibles que ceux installés par défaut

Les problèmes de licence et de développement limitent de manière importante le

nombre de logiciels qui sont généralement compris dans l'installation par défaut de
la majorité des diffusions Linux les plus utilisées. Par exemple, seuls quelques-uns
incluent une capacité de playback pour les formats audio et vidéo les plus
courants, suite aux problèmes de licence et de brevet. Pour les mêmes raisons,
certains packages pouvant être intéressants pour seulement une minorité
d'utilisateurs ne sont pas inclus.

C'est la raison pour laquelle il est important de rechercher et d'inclure dans les
installations par défaut un package supplémentaire qui peut être utile pendant la
période de transition. De tels packages comprennent des polices supplémentaires,
des outils multimédia, et d'autres packages qui peuvent être utiles dans un
environnement mixte.

Dans le choix des packages, toujours favoriser la stabilité par rapport aux
fonctionnalités

Parmi les nombreux packages possibles disponibles pour chacune des fonctions, il
existe toujours un équilibre entre les fonctionnalités et la stabilité. En général, parmi
les packages possibles qui satisfont aux exigences fonctionnelles de la migration ; la
préférence doit être donnée à celui qui est le plus stable, et donc avoir une
utilisation plus longue du monde réel (et donc plus d'informations disponibles pour le
gestionnaire et une variabilité plus faible entre les différents lancements.

Point de résolution des problèmes : Quand le gestionnaire IT désire la dernière version

de tout ce qui se trouve sur le bureau de l'utilisateur.

Concevoir l'infrastructure de support de l’automatisation des processus en

vue de réduire le nombre de « disparités d’adaptation »

Chaque transition d'une infrastructure ICT vers une autre entraîne quelques
« disparités d’adaptation », à savoir des petites différences et incompatibilités. Ceci
peut être observé par exemple en traduisant une documentation d'un format de
données vers un autre. L'infrastructure globale devrait diminuer le nombre de tels
points de transition, par exemple en reconcevant les formats de documentation

35
dans le format libre ODT au lieu de réutiliser les versions développées précédemment
en utilisant les outils propriétaires. Ceci réduit fortement les différences de formatage
et de style qui se présentent quand un format est traduit dans un autre.

Présenter un système de ticket

Une difficulté pour chaque déploiement d'une nouvelle Informatique est d'estimer la
satisfaction de l'utilisateur et le degré d'acceptation de la nouvelle solution, en
particulier dans les entreprises moyennes dans lesquelles les réactions de l'utilisateur
sont plus difficiles à recueillir. Un système de ticket disponible en ligne peut offrir un
moyen facile et simple de d'identifier les points faibles du déploiement, et peut être
utile pour identifier les utilisateurs qui ont besoin de formation supplémentaire par
l'analyse des statistiques de propositions par utilisateur. Il peut également indiquer les
faiblesses du déploiement, par exemple en indiquant plusieurs tickets liés à un
domaine particulier.

Composer et mettre à jour un manuel d’instruction détaillé

Un effort de migration à grande échelle exige une action coordonnée, ainsi que des
informations claires et à jour. Le meilleur moyen de fournir ces informations passe par
un « manuel de migration », un point simple d'informations qui reprend la collecte de
la documentation préparée pour la migration (y compris la logique, le projet en
détails et la documentation technique) et le programme, mis à jour selon les progrès
du projet. Ceci simplifie également la gestion du projet quand un changement se
produit dans l'équipe réalisant la migration.

Directives sociales

Donner des informations sur OSS

Un obstacle important pour l'adoption d’OSS est l'acceptation par l'utilisateur, qui a
habituellement une connaissance très limitée de l’open source et des normes de
données open. Dans beaucoup de cas, OSS est perçu comme étant de moindre
qualité étant donné qu'il est « libre/gratuit », téléchargeable sur Internet comme
beaucoup de paquets de logiciels partagés ou comme des projets amateurs. Il est
important de mettre fin à cette perception, ainsi que de donner des informations sur
la façon dont OSS est conçu et quels sont la justification et le modèle commercial
qui en sont à la base.

Ne pas imposer le changement aux utilisateurs, mais leur donner des

explications

La modification d'infrastructure Informatique impose un changement important dans

la façon dont les utilisateurs travaillent et utilisent les ressources internes. Ce
changement peut entraîner de la résistance de la part des utilisateurs. Un tel
changement peut être /rendu plus simple en expliquant clairement pourquoi et

36
comment la modification interviendra, et quels avantages seront présentés sur le
long terme tant de manière interne (comme des coûts plus faibles, une meilleure
flexibilité et sécurité) et qu'à l'extérieur (franchise, adhésion aux normes
internationales, moins de charge sur les utilisateurs externes).

Il est important de donner suffisamment d'informations et de support pour pouvoir

sauter le « fossé d'opposition » : [IBM 06]

Point de résolution des problèmes : quand les utilisateurs internes pensent que la
migration a été faite pour payer un logiciel moins cher.

Utiliser la migration comme occasion d’améliorer les compétences des

utilisateurs

Etant donné qu'une formation pour la nouvelle infrastructure est nécessaire, elle peut
être utilisée pour améliorer globalement les compétences ICT. Dans beaucoup de
sociétés et d'administrations publiques par exemple, une petite formation officielle
est habituellement organisée pour les utilisateurs. Ceci sert non seulement à
accroître la confiance, mais elle peut également être utilisée pour harmoniser les
compétences entre les groupes et en général améliorer le rendement.

Ceci peut entraîner une certaine résistance des prétendus « gourous locaux », qui
peuvent percevoir cette amélioration globale comme une diminution de leur mission
sociale en tant que chefs techniques. La meilleure façon de riposter) à une telle
résistance consiste à identifier ces utilisateurs, et à leur proposer d'avoir accès à du
matériel de formation de niveau plus élevé (qui peut se trouver sur un site interne
accessible au public, par exemple).

De même, il peut être utile d'identifier les « champions locaux », c'est-à-dire les
enthousiastes du FLOSS, qui peuvent donner du support d’utilisateurs à d’autres
utilisateurs, et leur offrir des opportunités de formation supplémentaire ou d'être
reconnus. En général, il est utile de créer une page Intranet accessible fournissant
des liens pour tous les différents packages de formation.

37
Faciliter l’expérience et l’apprentissage

La liberté de licence qui est l'élément principal d’OSS permet une rediffusion libre du
logiciel et du support de formation. Dans ce sens, fournir aux utilisateurs des CD Linux
(qui n'exigent pas d'installation de disque dur) ou du support sur papier qui peut être
emporté à domicile peut aider à l'acceptation globale.

38
 6. Modèles commerciaux basés sur le FLOSS
Une des premières classifications des modèles commerciaux possibles avait été
conçue en 2001 par le travail du Groupe Européen de Travail sur le logiciel Libre et
Open Source [DB 00]. La taxonomie, adaptée aux derniers développements du
marché, est :

Entreprises financées par l’extérieur

 Financement de « l'amélioration nécessaire »

 Financement indirect

Financement interne ou à partir des revenus

 « Le meilleur savoir, c’est ici » sans contraintes

 « Le meilleur savoir, c’est ici » avec contraintes
 « Licences particulières »

Développements non financés

Financement externe d'entreprises

Nous considérons dans cette catégorie des groupes ou des sociétés qui
développent des logiciels open source à l'initiative (du moins dans le sens du terme)
de certaines organisations externes. Habituellement ces entités externes déterminent
la façon dont les fonds doivent être dépensés, et où les efforts de développement
sont menés. L'entité développeuse ne suit que plus ou moins ces directives. Dans un
certain sens, on pourrait dire que l'entité externe « parraine » le développement de
certains logiciels open source donnés. Dans cette catégorie, nous pouvons
distinguer au moins trois exemples, en fonction de qui finance le projet et pourquoi.
Nous les avons appelé le financement public, le financement de « 'amélioration
nécessaire », et le financement indirect.

39
Financement public

Les groupes de travail ou les individus obtiennent le financement pour développer

un produit de bon logiciel, de la documentation, des études de cas ou autres.
Habituellement, les seules contraintes imposées par l'entité qui finance sont que les
fonds doivent être utilisés pour terminer jusqu'à la fin du projet. Ceci est typique de
grands projets scientifiques, et le financement vient habituellement des universités ou
des subventions nationales de la science. En fait, beaucoup de grands projets, dans
la radioastronomie, l'informatique de la chimie, et la biologie sont financés de cette
manière. De plus, certains consortiums pour le développement d'outils Internet et de
technologies ont (ou ont eu) une telle structure de financement. Il est important de
remarquer que dans ces cas l'institution de financement n'attend pas de récupérer
l'investissement, ou d'en bénéficier directement. Habituellement, une certaine
attente d'amélioration sociale constitue la raison du financement.

Financement de « l'amélioration nécessaire »

Une entreprise ou une organisation peut avoir besoin d'une nouvelle version ou
d'une version améliorée d'un « package de logiciels, et financer quelque consultant
ou fabricant de logiciels pour effecteur le travail. Ensuite, le logiciel résultant est
rediffusé comme open source pour tirer avantage du grand nombre de
développeurs compétents capables de le déboguer et de l'améliorer.

Un bon exemple des avantages de ce modèle peur être rencontré dans un article
écrit par Aari Jaaksi, directeur open source chez Nokia, qui décrit l'expérience de la
conception des produits Nokia N770 et N800, basée sur Linux : « Les plus grandes
économies de coûts proviennent de l'utilisation de composants déjà existants. Nous
avons utilisé plusieurs composants et des sous-systèmes libres en tant que tels, sans
aucune modification. Nous avons également amélioré plusieurs composants afin de
mieux rencontrer nos exigences. Une telle amélioration est meilleur marché que la
création à partir de zéro de la fonctionnalité recherchée. Environ deux tiers du
programme du Nokia 770 est licencié sous une licence open source. Ces
composants nous ont permis de fabriquer le logiciel à meilleur marché que nous
l'aurions pu en utilisant des technologies fermées et propriétaires » [Jaak 06].

Dans [Gosh 06], on estime qu'il est possible d'atteindre des économies en termes de
recherche de logiciels et de développement de 36% grâce à l'utilisation du FLOSS,
qui est, en soit, le plus grand « marché » actuel du FLOSS, comme le montre le fait
que la majorité des développeurs utilisent au moins certains logiciels open source
dans leur propre code (56.2%, comme rapporté dans [ED 05]).

Dans au moins une instance les avantages de l'utilisation de FLOSS pour le

développement de produits ont été évalués, dans le contexte du projet Européen
INES [INES 06]. Le projet recherchait l'usage de FLOSS dans les systèmes de contrôle
industriels développés par les PME Européennes, et a mesuré l'impact économique
résultant :

40
 Avantage économique % des sociétés:

Reproductions Internes 100%

Bénéfice Accru 100%
Réduction du temps par rapport au marché 84%
Réduction des Coûts de Développement 79%
Réduction des Coûts de Production 79%
Amélioration de la Qualité du Programme 79%
Amélioration de la Réutilisation de la Conception 79%
Rendement du capital investi > 200 sur 3 ans 74%
Augmentation de la Rentabilité du Produit 68%

Il est intéressant d'observer que les sociétés qui adoptent ce modèle participent en
retour dans de nombreux cas au code en développement même si explicitement
cela n'est pas imposé par la licence du projet FLOSS, en vue de réduire le coût de
l'intégration de réparations particulières du produit et tirer profit du support externe.

Financement indirect / Perte

Une société peut décider de financer des projets open source) si ces projets peuvent
entraîner une source de revenus importante pour les produits qui y sont liés, et pas
directement au code source original ou au logiciel. Un des cas les plus courants est
l'écriture du logiciel recherché pour faire fonctionner le matériel, par exemple, les
pilotes de systèmes d'exploitation pour du matériel particulier. En fait, beaucoup de
fabricants de matériel distribuent déjà gratuitement des pilotes de logiciels. Certains
d'entre eux distribuent déjà certains de leurs pilotes (en particulier ceux pour le
noyau Linux) comme logiciels open source.

La source de perte est généralement le modèle commercial traditionnel, ce qui est

courant égale open source pour créer ou s'élargir vers un autre marché sous des
conditions différentes. Par exemple, les vendeurs de matériel investissent dans le
développement de pilotes de logiciels pour des systèmes d'exploitation open source
(comme Linux) pour étendre le marché du matériel lui-même. D'autres exemples
sont liés à l'établissement d'une plateforme ou d'un protocole particulier; par
exemple le projet Eclipse était une réussite extrême pour créer un grand écosystème
d'outils et de projets qui le complètent et l'améliorent. La majorité des sociétés ont
abandonné leur propre environnement de développement intégré développé de
manière interne, et utilisent Eclipse comme base même pour des produits
commerciaux.

Utilisation interne

Certains projets peuvent débuter comme une alternative à moindre de coût des
systèmes d'entreprise individuelle. Dans ce cas, la société développeuse n'a pas (du
moins au début) de projet pour recueillir un revenu externe lié à la vente du logiciel
ou des services qui y sont liés. Les sociétés développent un certain système parce
qu’il leur est utile, et ensuite décident de le rendre open source, et de le diffuser
largement, juste pour tirer avantage de la source de développement open source. Il

41
est probable qu'elles obtiendront une certaine participation, des améliorations et
des réparations de bugs de la part de développeurs externes intéressés par le
logiciel, et quelques rapports de bugs. Plus tard, le produit peut même obtenir une
certaine acceptation sur le marché, et la société développeuse pourrait même en
recueillir certains avantages.

Part exemple, une grande entreprise disposant de plusieurs milliers d'ordinateurs de

bureau peut décider de créer un certain logiciel de manière interne, et de rendre
ce logiciel disponible sous une licence open source pour recueillir les avantages
d'une plus grand base de développeurs pouvant être intéressés à dépanner. Un
aspect intéressant concerne les récentes enquêtes qui montrent que 25% des
sociétés travaillent avec d'autres sociétés dans le même secteur pour développer
des logiciels open source particuliers à l'industrie [CIO 07].

« Le meilleur savoir, c’est ici » sans contraintes

Dans cet exemple, une société travaille en tant que consultant rémunéré, avec des
contrats conclus sur la base du niveau de connaissances plus élevé de ses
employés. Toute société peut mettre en œuvre ce modèle, puisque il n'y a pas de
restrictions qui empêchent un technicien compétent d'acquérir arbitrairement une
profonde expérience des systèmes de logiciels open source. Evidemment, ceci
signifie également que toute firme utilisant ce modèle s'expose au risque d'être
remplacée par une autre, si le niveau de compétence est atteint mais pas
maintenu. C'est un des modèles parfaits « basés sur les services » qui sera reprécisé
plus en détails plus loin dans ce chapitre.

« Le meilleur savoir, c’est ici » avec contraintes

Afin d'empêcher les concurrents de « vole » ses clients, une firme peut ixer des limites
arbitraires à la procédure de partage des connaissances, au moyen de brevets ou
de droits d'auteur qui ne sont pas conférés de manière directe dans la licence
FLOSS. Elles peuvent être appliquées en fixant dans une licence plus contraignante
juste une petite (mais essentielle) partie du code, habituellement considérée
comme la « boîte noire », ou en ajoutant une série de matériels avec droits d'auteur
non librement redistribuables, et en ajoutant dans la licence une obligation de les
présenter à l'utilisateur final (« badgeware »), empêchant donc les autres de
s'approprier le code.

Dans un cas particulier, il peut être nécessaire d'avoir des conditions externes, non
liées au code (comme des certifications de code) qui par nature peuvent être
onéreuses à reproduire, et celles-ci peuvent être ajoutées dans la distribution du
code pour créer un actif non transférable. Par exemple, le projet
PROGRAMME*ASTER est un système complexe de simulation utilisé par la société
française de service public EDF dans des systèmes aussi complexes que (dans) les
centrales nucléaires. Le projet dispose d'une version GPL, et une version de qualité
contrôlée et certifiée qui a passé les tests de certification nationaux pour être utilisée
dans la conception de systèmes de sécurité cruciale. D'autres exemples sont les
certifications comme EALA+ qui ont été récemment obtenues par les vendeurs Linux.

42
« Le meilleur code, c’est ici » sans contraintes

Dans ce modèle, une société développe un certain code open source, et vend des
services de consultance et de maintenance s'y rapportant. Ceci est semblable à
l’idée « le meilleur savoir, c’est ici », mais sans avantage additionnel en termes de
temps, puisque un concurrent a besoin de plusieurs mois pour créer un programme
semblable, ou pour comprendre toutes les complexités du code de quelqu'un
d'autre. Ceci procure un avantage de temps à la société ou au groupe qui crée le
logiciel en premier lieu.

« Le meilleur code, c’est ici » avec contraintes/Licences fonctions du temps

Un point intéressant dans la licence d'OSS concerne les licences fonctions du temps,
quand l'objet d'un logiciel modifie la licence avec le temps ou sans événement
particulier (par exemple, le lancement d'une nouvelle version du code). Le premier
exemple connu de ce modèle a été le post-scriptum de l'interprète Alladin
Ghostscript, et dernièrement certaines sociétés de sécurité ont fourni des signatures
de sécurité à des clients payants, et les ont lancées sous une licence publique après
quelques jours.

Ce modèle convient particulièrement aux logiciels qui se modifient rapidement ou à

d'autres matériels (par exemple, les signatures de sécurité et de virus) et est moins
praticable pour le logiciel, parce que la version ancienne devient une base pour la
création d'un produit amélioré qui peut être concurrentiel avec l'un (sous licence
commerciale). C'est ce qui s'est exactement passé pour Alladin, qui a rencontré un
concurrent open source (GNU Ghostscript) basé sur une version antérieure du
programme, en plus des nombreuses améliorations effectuées par les développeurs
open source.

Licence double

Un des rares modèles n'ayant pas de contrepartie dans le monde commercial du

logiciel, la licence double est utilisé par les sociétés qui veulent tirer profit de sociétés
qui désirent utiliser ou tirer profit d’un package open source sans les conditions de
redistribution de la licence OS. Par exemple, la banque de données MySQL a deux
licences, une GPL (pour l'utilisation d'OSS) et une autre commerciale. Le client qui
veut utiliser MySQL dans un produit commercial sans diffuser le code paye une
licence commerciale.

Beaucoup d'autres projets débutent par l'utilisation d'un tel procédé, qui mélange le
modèle de logiciel commercial traditionnel et en permettant de payer pour un
développement continu. L'inconvénient c'est que le modèle ne peut réellement être
utilisé que pour des packages qui doivent avoir un lien avec le code pour une
efficacité maximum ou parce que il n'y a pas de protocole courant pour l'échange
de données. Ceci signifie que par exemple la licence double est difficile pour des
packages comme les serveurs de courrier, qui utilisent des protocoles courants
standardisés pour communiquer avec les clients.

43
La licence double exige de traiter certains aspects juridiques et communautaires.
Par exemple, des correctifs ou des modifications de la part de participants externes
exigent de reconnaître explicitement l'auteur des deux licences, et la gestion de la
communauté exige une gestion précise de la frontière entre les aspects
commerciaux et open source du projet.

Développements non financés

S’il y a suffisamment « d'effet de réseau », un financement peut ne pas être

nécessaire, seul un effort minimal doit être fourni pour organiser les lancements et les
correctifs. Des exemples de ce genre de projets open source sont le noyau Linux, les
diffusions GNU/Linux comme Debian, les systèmes d'exploitation basés sur BSD tels
que FreeBSD, NetBSD, ou OpenBSDn, et la bibliothèque Mesa OpenGL. Ces efforts
débutent dans de nombreux cas comme l'effort d'un seul homme, ou d'un petit
groupe, et par une bonne organisation et un travail bénévole, ils créent une large
structure de réseau pour la maintenance du code. Même avec un financement
limité de certains projets, tous ces efforts réussissent sans une subvention externe ou
sans des dons d'argent explicites. En fait, c'est le cas pour des centaines de petits
projets open source.

Modèles commerciaux basés sur les services spécialisés

Les modèles commerciaux basés sur les services spécialisés reposent sur l'idée de
l'optimisation, à savoir la capacité d'une société spécialisée à fournir un service pour
un prix global au client qui est inférieur à celui qu'une société engagerait en
l'accomplissant elle-même. Pour avoir une vue d'ensemble des domaines sujets à
cette optimisation potentielle, nous pouvons donner une vue d'ensemble des étapes
faisant partie de l'adoption d'une nouvelle technologie ICT :

Choix du logiciel (si des composants packagés, ready-to-use, sont utilisés)

Installation
Intégration
Certification de l'appropriation technique
Certification légale
Formation
Contrats de maintenance et de support continus10
À la fin, migration de l'ancien système vers le nouveau

Comme nous le verrons, seules de rares sociétés sont spécialisées dans un modèle
unique, mais le composent ensemble pour créer des packages de services, dans le
sens de les rendre comme un genre de « blocs de construction de modèles
commerciaux ». Nous fournirons toutefois d'abord une vue d'ensemble de chaque
bloc pour donner une estimation des efforts et des difficultés inhérentes à chaque
étape.

10Keen, P. « gérer les économies du capital d'information » : la maintenance /représente 40% par an pendant 5 ans
en moyenne du coût initial du logiciel.

44
Support pour le choix du logiciel

Le choix du logiciel est réellement une phase à étapes multiples, qui commence par
l'identification des besoins et une connaissance du marché des logiciels en
sélectionnant une combinaison de packages qui minimisent le nombre de
programmes devant être créés. Cette procédure de minimisation est complexe, en
prenant compte non seulement les caractéristiques techniques du logiciel à
considérer, mais elle doit également offrir une estimation de « l'enjouement » du
projet OS, la probabilité que son développement se poursuivra, et la disponibilité de
consultants et de la documentation.

Une société qui désire offrir ce genre de service doit réaliser un investissement
important en termes de connaissance des différents packages et outils disponibles.
Comme le nombre de projets qui sont commercialement accommodants ou qui
utilisent PA peut être estimé supérieur à 18000, un effort important est demandé pour
simplement suivre les mises à jour ou les annonces. C'est encore plus compliqué par
le fait que la majorité des projets n'ont pas de « mécanisme de commercialisation »
explicite, qui diffuse les informations sur les aspects et les capacités d'un package de
logiciels comme les firmes de logiciels commerciaux. Ceci signifie que les sociétés
qui souhaitent offrir des services de consultance pour le choix de logiciels doivent
consacrer un certain effort simplement pour surveiller les sites Internet et les listes
d'abonnés, et en extraire des informations sur les nouvelles versions ou les nouveaux
packages. Cet effort peut être estimé d'1 homme/heure par jour pour des segments
limités (par exemple, seulement pour l'entreprise de contact Java), à 5
hommes/heure par jour pour plusieurs segments de logiciels différents.

L'activité réelle de consultance est assez simple, et consiste en des entretiens en

détail et des analyses des besoins du client, suivi par la préparation d'une liste de
packages proposés. Il est également possible d'estimer le coût d'intégration, en
utilisant les données de la communauté technique des logiciels concernant les
projets COTS (Common Off The Shelf).

Support pour l'installation

Une activité de support très courante dans la communauté OSS est l'installation.
Ceci provient de deux différents aspects : l'excellente modularité du logiciel (qui
oblige l'installation de nombreux composants différents pour créer un système de
travail) et la relative indisponibilité d'installateurs de logiciels sophistiqués, ce qui est
courant dans le secteur commercial.

Ceci est toutefois en train de changer, grâce à la standardisation dans le monde

Linux des systèmes de package, qui ne rend presque pas nécessaire l'installation du
logiciel à partir de composants open source. La disponibilité d'installateurs de
package basés sur RPM (RedHat package manager utilisé également par le Suse
Linux de Novell et Mandriva Linux) et DEB (utilisé par Debian et les dérivés, comme
Ubuntu) a augmenté avec la dépendance aux systèmes d'entretien qui a fortement
réduit la complexité de l'installation, à présent principalement liée à la modification
de dossiers de configuration appropriés pour adapter l'installation à un
environnement ICT particulier.

45
Support pour l'intégration

Une autre des étapes les plus courantes dans la consultance basée sur OSS c'est
l'étape d'intégration, qui concerne tant l'étape de configuration spécifique
nécessaire pour « rentrer » un composant open source dans une structure existante,
que le développement personnalisé nécessaire pour ajouter les fonctionnalités
manquantes ou corriger les incompatibilités.

L'intégration peut exiger un effort important pour des projets de grande envergure,
avec un volume relativement grand de code personnalisé ou l'intégration de
composants commerciaux si aucun autre choix n'est possible. Cette variabilité est la
raison à la base de la forte pression sur les normes (tant de-facto que de-jure) qui est
le moyen le plus simple pour diminuer le coût d'interface entre les composants
disparates des logiciels.

Certification de l'appropriation technique

Elle se fait principalement par les intégrateurs d'adhésion et les consultants externes,
et peut se produire sous deux formes: la certification de l'adhésion à une norme
internationale (par exemple les normes de sécurité ou de qualité) et la certification
de l'appropriation pour des environnements particuliers. Dans un sens, dans les deux
cas l'intégrateur ou le certificateur fournit l'assurance que le package de logiciels est
conforme à une série de règles particulières, et est passible légalement de cette
conformité. Les certifications de portée limitée, comme les assurances de sécurité,
sont entièrement comprises dans le champ des PME, tandis que les assurances de
qualité de composants de grande envergure sont franchement difficiles à atteindre
si le projet open source lui-même n'a pas de mécanisme explicite en place pour la
gestion du projet11.

La majorité des distributeurs Linux réalisent ce test d'appropriation d'une manière très
simple, en choisissant la version candidate la plus crédible d'un package open
source en fonction de l'objectif de distribution (par exemple, pour la distribution
appelée « édition d'entreprise » seules des versions stables sont utilisées, tandis que
pour les distributions « avant garde » c'est la dernière version instable qui est choisie).

Certification légale

Ceci est un modèle relativement récent, qui s'est dégagé des problèmes perçus par
le mélange de codes sous licences multiples, et de plusieurs procès12. La certification
légale a rapport avec les domaines suivants:

L'utilisation correcte d’OSS et des licences commerciales

La certification de brevets

11 Par exemple, le package open source de simulation CODE-ASTER d'EDF (la société publique française) est certifié
approprié pour être utilisé dans la simulation et la conception de centrales nucléaires; et l'environnement AdaCore
ADA (basé sur des composants open source) est utilisé dans beaucoup de sociétés d'aviation et dans des
environnements à disponibilité élevée avec la certification, DO-178B.
12 Il est intéressant de remarquer que la majorité de ces procès ne concernent que marginalement des licences

open source, et que l'incertitude a été d'une certaine façon propagée par les sociétés commerciales qui sont
menacées par l’open source sur leur marché.

46
 Toute autre certification de Propriété Intellectuelle

Le premier domaine concerne le mélange et l'utilisation correcte de composants,

qui peuvent avoir différentes licences et différentes restrictions. Alors que plus de 70%
des logiciels libres et open source sont en fait lancé sous la GPL, plus de 50 autres
licences existent, et certains composants essentiels sont lancés sous une licence non-
GPL (le logiciel de la fondation A, Mozilla/Firefox ou l'environnement de
développement intégré Eclipse).

Quand on utilise et intègre beaucoup de composants différents, il est essentiel d'être

en mesure de vérifier que l'ensemble du code est utilisé d'une manière correcte et
justifiée. C'est réellement une tâche qui exige des capacités juridiques, plus que
techniques, et pour cette raison elle est perçue par la communauté OSS comme
étant un exemple « tangentiel ».

La certification de brevets et IP offre une forme « d'assurance » contre des plaintes

de tiers sur des brevets de logiciels ou autres matériels soumis aux droits d'auteur qui
peuvent se trouver dans l’OSS utilisé dans un projet. Comme toute forme
d'assurance, elle est totalement exigeante en termes de fonds monétaires, étant
donné que les plaintes pour des brevets peuvent entraîner des procès coûtant de
multiples millions d'Euros (voyez l'exemple du récent procès pour le brevet d’Eolas
contre Microsoft corp. avec plus de 500 millions de dollars de dommages et intérêts
réclamés).

Formation

La formation est un autre modèle courant commercial, étant donné que beaucoup
de projets open source ne disposent pas de processus de formation comparable à
celui des sociétés commerciales. La formation demande habituellement du
personnel de façon intensive, et exige certains efforts pour la création du support
initial de formation devant être utilisé pendant les cours. Une bonne estimation du
travail requis est qu'il faut s'investir pendant environ 3 à 8 heures pour la préparation
du support de cours pour chaque heure de formation donnée13.
La simplicité du modèle et le fait qu'il ne requière pas de développement de logiciel
signifie qu'il est tout à fait facile pour de sociétés de formation existantes d'entrer en
lice pour offrir de tels services. De même, le plus grand projet OSS a également
habituellement des programmes officiels de formation (par exemple JBoss, les
distributeurs Linux RedHat et Novell/Suse).

Contrats de maintenance et de support continus

Pour les systèmes les plus complexes, il existe a un besoin continu de support et de
maintenance, tant pour les bugs et les améliorations des caractéristiques que pour
l'adaptation du système au changement de l'environnement Informatique. Les
contrats de support sont habituellement basés sur la durée (la plus courante est une
période contractuelle d'un an, renouvelable) et sur le niveau. Les niveaux sont
couramment au nombre de trois (correspondant aux services de support « bronze »,
« argent » et « or », avec des degrés variables de services garantis. Par exemple, le

13 La variabilité dépend de la complexité du cours et de la spécificité des connaissances à enseigner.

47
niveau bronze fournit habituellement un support pour le courrier électronique
pendant les heures de service et l'accès à une base de connaissances. L'argent
ajoute un support vocal et la priorité des incidents par rapport aux contrats bronze,
et l'or ajoute un support effectif 24 heures sur 24, 7 jours sur 714. Alors qu'il est
raisonnablement facile pour une PME d'offrir des services standards de support, des
offres 24 heures sur 24, 7 jours sur 7 peuvent exiger une base de personnel
légèrement plus grande pour assurer une couverture en toute circonstance. Un
autre modèle qui gagne du terrain est l'achat de « tokens », qui sont utilisés par la
suite pour l'achat d'activités de support spécifiques (par exemple, une demande de
support peut nécessiter un token, et une demande urgente « prioritaire » peut être
achetée contre trois tokens. Ainsi, les utilisateurs peuvent décider d'une manière
flexible comment améliorer l'offre de support sans restrictions.

En prenant en compte les caractéristiques des questions relatives au support, on

peut observer que l'on peut facilement répondre à la majorité des appels, même
avec du personnel modérément compétent (environ 80% sont des appels « faciles »).
Les 20% restants exigent habituellement un plus grand effort. Il est parfois possible de
créer des « pyramides » de support, quand une société offre le support pour ces 80%
d'appels faciles, et transfère les plus difficiles vers une autre société qui est plus
spécialisée dans un package particulier ou un problème spécifique. Ceci requière
évidemment de la capacité à classifier les appels de façon appropriée, et exige
l'existence de contrats de support spécifiques entre les participants. Ce n'est
habituellement possible que si la base de clientèle est suffisamment grande, et ainsi
plus accommodante pour les entreprises moyennes.

Le modèle de support est utilisé par beaucoup de sociétés ayant modifié un

package commercial (qui n'a pas entièrement connu de succès sur le marché
commercial, ou incapable de remplir complètement son potentiel de marché) en
un package open source. L'idée sous-jacente est que les auteurs du code sont
supposés être les experts les plus qualifiés pour en assurer le support. Le premier
exemple célèbre de ce modèle a été le serveur d'applications Zope, et de
nombreux autres encore actifs (par exemple, la boîte à outils pour la conception
aidée par ordinateur OpenCascade, Compiere, Alfresco et beaucoup d'autres). Il
est intéressant de remarquer que la participation externe est habituellement
obtenue de participants externes même dans le cas de domaines d'application
spécifiques, comme pour OpenCascade15.

Services de migration

Comme pour les services d'intégration, la migration est basée sur la connaissance
approfondie tant du début qu’à la fin de l'environnement Informatique. La majorité
des services de migration se basent sur des packages de logiciels qui sont utiles pour
automatiser la migration (par exemple les configurations de l'utilisateur), ou sur des
« packages » préconfigurés de OSS offrant des substituts complets d'environnements
propriétaires. Des exemples peuvent être trouvés dans les systèmes de courrier ou de

14 Cette subdivision est extraite de contrats de support de plusieurs vendeurs de support ICT, mais une légère
variation peut être rencontrée – par exemple, 4 niveaux au lieu de 3, ou différents genres de matériel de support
autres que la base de connaissances.
15 On rapporte que 20% de la « valeur du package » d’OpenCascade provient de partenaires et de développeurs

externes, à la fois en termes de code et de documentation que de matériel auxiliaire. Un pourcentage identique est
également constaté dans d’autres projets, tels que JBoss.

48
logiciel de groupe, ou dans les remplacements des systèmes d’exploitation. Les
services de migration exigent habituellement une étape d'intégration spécifique en
plus de la migration de base, et pour certains efforts de grande envergure ils doivent
être coordonnés entre les différentes sociétés, en offrant un service coordonné (par
exemple, l'un spécialisé dans le portage du code personnalisé, l'autre dans les
services de migration de courrier, etc.)

Commercial-on-open

L’un des modèles les plus simples pour les sociétés de logiciel est la vente d’un
package de logiciel propriétaire sur un open source. Il peut s'agir simplement de
faire fonctionner la plateforme (comme disposer d'un package commercial
tournant sur Linux) ou d'améliorer un projet open source avec un certain module
commercial. Les exemples sont nombreux et vont des systèmes commerciaux de
données, des applications propriétaires de payroll ou financières, jusqu'au module
conçu pour améliorer la capacité d'utilisation et la gestion d'un projet open source
existant.

Ce second exemple devient l'une des principales options pour financer un projet
OSS, et améliore le développement des composants OSS pour délivrer de la valeur
ajoutée. Cette dernière peut n'intéresser qu'une partie de la communauté, par
exemple en fournissant des interfaces faciles dans un système complexe. Comme
l'exemple dans la section précédente sur les licences dépérissant avec le temps, si le
projet est réussi il existe un risque de concurrence avec un projet open source conçu
pour rencontrer exactement le même besoin.

Toute société qui projette de suivre ce modèle devrait consacrer certains efforts au
suivi de l'évolution de la plateforme OSS, et à la participation (par exemple, avec
l'aide d'un participant actif dans les listes d'abonnés du projet). Ceci a le double
avantage de donner un aperçu de l'évolution des plateformes et des
caractéristiques nouvelles, potentiellement utiles, mais également d'être un « bon
citoyen » du projet OSS.

Services de médiation

Les services de médiation sont relativement nouveaux sur le marché des modèles
OSS, et se basent sur le fait que pour les sociétés il est difficile d'interagir avec les
communautés éparses telles que certains projets OSS. Les services de médiation
fournissent une sorte de point de contact unique, qui rassemble les informations des
développeurs, les listes d'abonnés, les forums et autres, transfère les demandes et
soutient les réparations de bugs. Ces services sont particulièrement utiles quand une
société désire payer pour les modifications ou changements du code, mais n'est pas
capable de trouver une société de services appropriée. Habituellement, ces
sociétés de médiation essaient de contacter directement les développeurs, ou de
trouver des sociétés de support ayant de l'expérience dans le package spécifique.
Après l'avoir développé, elles ajoutent une certaine certification et des efforts
d'intégration pour délivrer un package unique au client.
Il s’agit de services utiles, en particulier pour des efforts de grande envergure, quand
de nombreuses communautés différentes sont impliquées, ou quand il n'existe pas

49
de décision claire pour demander du support ou du développement. Les projets de
grande envergure (comme Apache, JBoss et d'autres) ont habituellement une ou
plusieurs sociétés qui offrent déjà ce genre de médiation.

Custom development

Un modèle n’étant juste qu'une application d’un modèle traditionnel, le custom

development revient simplement à offrir un code personnalisé sur un projet open
source. Ainsi, il existe habituellement une forme de spécialisation sur un projet unique
ou sur une classe de projets (par exemple, le développement de pilotes d’unité ou
de systèmes J2EE orientés open source). Une société qui désire utiliser ce modèle
devrait joindre au modèle traditionnel une activité liée au repérage de l'évolution et
de l'itinéraire du projet sur lequel elle est spécialisée, d'une façon semblable à celle
décrite dans le précédent modèle commercial open.

Evaluation de l'utilisation des modèles commerciaux FLOSS

Pour évaluer les véritables modèles commerciaux adoptés par les sociétés FLOSS,
nous avons préparé une liste initiale de 120 sociétés en utilisant certains sites Internet
populaires d'informations open source16. Cette liste a ensuite été affinée en éliminant
les sociétés qui n'avaient pas réellement adopté le FLOSS, même en utilisant une
définition très large. Plus particulièrement, toute société ayant autorisé l'accès au
code source uniquement à des utilisateurs non commerciaux, ou n’ayant autorisé
qu'une redistribution a été retirée de la liste. De même, les sociétés pour lesquelles
aucune information n'était disponible, ou pour lesquelles aucun produit ou service
n'était clairement identifiable, ont de la même manière été éliminées.

Une des sociétés inclues (Sourceforge, du groupe OSTG) n'est pas open source en
elle-même17, mais elle représente un exemple de modèle « auxiliaire », étant donné
que le site lui-même accueille plus de 100000 projets open source et offre des
services de support comme les listes d'abonnés, les systèmes d'adaptation de code
et la distribution de fichiers. De même, les sociétés qui ont une participation active
importante dans OSS, mais pour lesquelles le FLOSS n'est pas le modèle commercial
central n'ont pas été inclues18.

Une série initiale de variables a été choisie, comprenant : le choix des licences, l'offre
de produits (si une version unique ou multiple d'un système de logiciel est offerte), les
services offerts (divisés entre le support d'installation, l'intégration, la formation, la
consultance, les certifications légales et techniques), le type de contrats offerts
(souscriptions, licences ou par incident) et la forme de mesure. De plus, la
documentation figurant sur le site Internet de chaque société a été récupérée pour

16 Entre autres : FreshMeat, Slashdot.org, OSNews, LinuxToday, NewsForge et certains blogs dédiés au modèles
commerciaux FLOSS comme ceux de Roberto Galoppini, Matt Asay, Fabrizio Capobianco. D’autres informations ont
été obtenues en effectuant des recherches sur Google.
17 Le code original pour l’environnement de développement collaboratif de SourceForge était open source, et à la

suite de son changement de licence, plusieurs forks sont apparus, dont GForge.
18 Cela concerne par exemple IBM, HP et Sun, étant tous d’importants participants au FLOSS, mais pour lesquels le

logiciel open source représente uniquement l’un des flux de revenus généraux (à côté du matériel, des servies IT, et
autres).

50
trouver les références du modèle commercial adopté et la façon dont le modèle
influence la valeur de la proposition de la firme. Des recherches dans des listes
d'abonnés et sur des moteurs de recherche ont été effectuées afin d'obtenir des
références indicatives des relations de la société avec la communauté des
développeurs, et s’il existe une activité de support externe, en-dehors de la société,
sous la forme de sites Internet, de wikis et de bases de connaissance.

Les données récoltées ont alors été cataloguées, en éliminant les variables de peu
d'importance. Par exemple, en couplant ensemble l'installation, la formation, le
support et la consultance qui ont été identifiés comme faisant partie de l'offre de la
plupart des sociétés proposant des services de support (et couplés dans un seul
variable ITSC, Installation, Formation/consultance). Les variables importants restants
sont la production des principaux revenus (le service ou l'offre contractuelle qui
produit le revenu principal de la société) et le modèle de licence. Le premier est
ensuite subdivisé en services de Choix (trouver les packages FLOSS répondant aux
besoins), en ITSC, en souscription (licence récurrente) et en licence unique. Le
modèle de licence est obtenu en regardant le système de licence adopté par la
société et selon que les services de la société couvrent un projet de logiciel unique
ou une série de projets. En effectuant une simple analyse de groupement sur les
résultats, il a été possible d'identifier 6 principaux modèles et un groupe « autres » :

51
52
Les 6 principaux groupes identifiés sont :

Double licence : un même programme de logiciel distribué sous une licence

GPL19 et une licence commerciale. Ce modèle est principalement utilisé par
les fabricants d'outils et de logiciels destinés aux développeurs, et fonctionne
grâce à une clause de couplage solide de la GPL, qui exige des travaux
dérivés ou des logiciels qui lui sont liés directement devant être couverts par la
même licence. Les sociétés qui ne désirent pas lancer leur propre logiciel sous
la GPL peuvent acquérir une licence commerciale qui constitue dans un sens
une exception à la clause reliant les parties. Pour les personnes qui valorisent
l'idée de « liberté» d'un logiciel gratuit/libre, ceci est considéré comme un bon
compromis entre l'assistance à ceux qui supportent la GPL et obtiennent le
logiciel gratuitement (et rendent leurs logiciels disponibles en tant que FLOSS)
et les avantages offerts par la licence commerciale pour ceux qui souhaitent
garder le code propriétaire. L'inconvénient de la double licence est que les
participants externes doivent accepter le même régime de licence, et il a été
démontré que ceci a réduit le volume de participations externes (ce qui se
limite de plus en plus aux réparations de bugs et aux petites extensions).
Séparation des produits OSS/commerciaux : ce modèle fait la distinction entre
un logiciel FLOSS de base et une version commerciale, basée sur la version
libre mais avec une extension de plugins propriétaire. La majorité des sociétés
adoptent comme licence la Licence Publique Mozilla, étant donné qu'elle
autorise explicitement cette forme de mélange, et une plus importante
participation des contributions externes, puisque aucune acceptation de
licence double n'est requise. Le modèle a l'inconvénient intrinsèque que le
produit FLOSS doit être de grande valeur pour être intéressant pour les
utilisateurs, mais il doit également ne pas être suffisamment achevé pour
empêcher la concurrence avec le produit commercial. Cet équilibre est
difficile à atteindre et à garder avec le temps ; de même, si le logiciel
présente un grand intérêt, les développeurs peuvent essayer de compléter la
fonctionnalité manquante d'une manière purement open source, et diminuer
ainsi l'attrait de la version commerciale.
Badgeware : il s’agit d’une réinvention/extension récente, à la suite d’une
ancienne contrainte20 posée par une licence, basée habituellement sur la
Licence Publique Mozilla, avec en plus une « contrainte de visibilité », la non-
extraction de marques de commerce ou d'éléments visibles de l'interface
d'un utilisateur. Ceci permet à la société de bénéficier de la protection de la
marque, et aux développeurs originaux d'obtenir de la reconnaissance même
si le logiciel est revendu par l'intermédiaire de revendeurs indépendants.
Spécialistes de produits : il s’agit des sociétés qui ont créé ou qui maintiennent
un projet de logiciel particulier, et qui utilisent une licence FLOSS pure pour le

19La licence originale BSD a introduit le droit à la publicité, qui exige que la licence soit conservée dans le matériel
publicitaire en mentionnant les caractéristiques ou l'usage du logiciel au moyen du libellé. Ce produit comprend un
logiciel développé par l'Université de Californie, Berkeley, et ses participants.

20MuleSource est une exception qui utilise une licence MPL+Attribution semblable à la licence badgeware. Comme
le mentionne le Directeur Général de MuleSource, « ainsi, si vous utilisez Mule dans votre produit de logiciel et le
vendez commercialement, vous êtes obligé soit de conclure un accord de licence avec nous, soit de garder le
logo fourni par Mule bien visible. La communauté et les experts connaissent encore aujourd’hui des débats pour
savoir les licences « badgeware » sont vraiment open source. Certaines d'entre-elles ont été présentées à l'Initiative
open source pour évaluation, et au moins l'une d'entre-elles a été approuvée par OSI.

53
 distribuer. Les principaux revenus sont produits par les services comme la
formation et la consultance (la catégorie « ITSC ») et appliquent les
approches « le meilleur code, c’est est ici » et « le meilleur savoir, c’est ici »,
issus de la classification originale EUWG [DB 00]. Elle tire profit de l'hypothèse
répandue selon laquelle les experts connaissant le mieux un logiciel sont ceux
qui l'ont développé. De cette manière elle peut offrir des services avec un
effort publicitaire limité, en tirant profit de la libre redistribution du programme.
L'inconvénient du modèle est qu'il existe un léger obstacle à l'entrée de
concurrents potentiels, étant donné que le seul investissement nécessaire est
l'acquisition de compétences spécifiques et les compétences sur le logiciel
lui-même.
Fournisseurs de plateformes: il s’agit des sociétés qui propose du choix, du
support, de l'intégration et des services pour une série de projets, en formant
collectivement une plateforme testée et contrôlée. Dans ce sens, même les
distributions Linux ont été catégorisées comme des plateformes. Il est
intéressant d'observer que ces diffusions possèdent des licences dont bon
nombre d’entre elles sont des licences FLOSS pures. Cela vise à maximaliser
les participations externes et à bénéficier de la protection des droits d'auteur
pour empêcher la copie directe, mais pas le « clonage » (à savoir
l'effacement de matériel protégé par les droits d’auteur, tel que les logos et
les marques de commerce, afin de créer un nouveau produit)21. La principale
proposition de valeur se présente sous la forme d'une garantie de qualité, de
stabilité et de fiabilité, et la certitude d'un support pour les applications
commerciales essentielles.
Sociétés de sélection/consultance: les sociétés de cette classification ne sont
pas de simples développeurs, mais offrent en outre des services de
consultance et de sélection/évaluation dans une grande gamme de projets,
d'une manière proche à celle de la fonction d'analyste. Ces sociétés tendent
à avoir un impact très limité sur les communautés FLOSS, étant donné que les
résultats de l'évaluation et la procédure d'évaluation sont habituellement un
actif de société propriétaire.

Les autres entreprises sont en trop petit nombre pour permettre toute extrapolation,
mais elles indiquent que le modèle commercial non habituel peut être rencontré sur
des marchés auxiliaires. Par exemple, la fondation Mozilla retire une somme d'argent
non habituelle d'un partenariat avec Google (estimée à 72M$ en 2006), tandis que
SourceForge/OSTG obtient la majorité de ses revenus des ventes du commerce
électronique sur le site de sa filiale ThinkGeek; il est possible de les classer comme
« financement public » et du « financement indirect » selon la classification EUWG
[DB 00].

21 Des exemples de clones de RedHat sont CentOS et Oracle Linux.

54
 Bibliographie

[ARC 07] Applied Research and Innovation Fund, InnovationBG 2007 report

[Aug 04] Augustin, L. Living with open source: the new rules for IT vendors and
consumers. OSBC 2004 conference

[Cam 06] Campbell, J. Due Diligence at Eclipse: How it Benefits our Community.
EclipseCon 2006 presentation

[Car 07] Carbone, P. Value Derived from Open Source is a Function of Maturity
Levels, OCRI conference "Alchemy of open source businesses", 2007

[CIO 07] CIOInsight, CIOINSIGHT OSS survey 2007.

[COS 05] EU COSPA project, D6.1 Report evaluating the costs/benefits of a transition
towards ODS/OS.

[Cox 07] Cox, M. Information sources. Blog entry,

http://www.awe.com/mark/blog/200704101400.html page 66

[DB 00] Daffara, C. Barahona, J.B. Free Software/Open Source: Information Society
Opportunities for Europe? working paper, http://eu.conecta.it

[Daf 06] Daffara, C. Sustainability of FLOSS-based business models, II Open Source

World Conference, Malaga 2006

[Daf 06-2] Daffara, C. Introducing open source in industrial environments. 3rd

CALIBRE workshop

[Daf 07] Daffara, C. Business models in OSS-based companies. Accepted paper,

OSSEMP workshop, Third international conference on open source. Limerick 2007

[Dal 05] Dalle, J.-M., et al., Advancing Economic Research on the Free andOpen
Source Software Mode of Production, in Building Our Digital Future: Future Economic,

55
Social & Cultural Scenarios Based On Open Standards, M. Wynants and J. Cornelis,
Editors. 2005, Vrjie Universiteit Brussels (VUB) Press: Brussels

[ED 05] Evans Data, Open Source Vision report, 2005

[EKM 05] Eckert D., Koch S., Mitlohner J. Using the Iterated Prisoner's Dilemma for
Explaining the Evolution of Cooperation in Open Source Communities . Proceedings
of the First International Conference on Open Source Systems , Genova 2005

[Fed 07] Fedora Project Wiki, Licensing. http://fedoraproject.org/wiki/Licensing

[Fog 05] Fogel, K., Producing Open Source Software: How to Run a Successful Free
Software Project. 2005: O’Reilly

[Forr 07] Forrester consulting, Open Source Software’s Expanding Role in the
Enterprise . March 2007

[Gar 06] Gartner Group, Open source going mainstream. Gartner report, 2006

[Gosh 05] Gosh, et al. Free/Libre/Open Source Software Worldwide impact

study: FLOSSWorld. FLOSSWorld project presentation.
http://www.flossproject.org/papers/20051217/flossworld-intro3.pdf

[Gosh 06] Gosh, et al. Economic impact of FLOSS on innovation and competitiveness
of the EU ICT sector. ec.europa.eu/enterprise/ict/policy/doc/2006-11-20- page 67
flossimpact.pdf

[Hahn 02] Hahn, W.R. (editor), Government policy towards open source software.
AEI-Brookings, 2002.

[HSE 02] UK Health and Safety Executive, Preliminary assessment of Linux for safety
related systems. Research report 011/2002

[IBM 06] IBM, Linux Client Migration Cookbook, Version 2: A Practical Planning and
Implementation Guide for Migrating to Desktop Linux. Available online at
http://www.redbooks.ibm.com/abstracts/sg246380.html?Open

[IDC 06] IDC, Open Source in Global Software: Market Impact, Disruption, and
Business Models. IDC report, 2006

[INES 06] INES IST project, Final project report.

http://www.euroines.com/down/INES_final_report.pdf

[Inf 07] Infoworld white paper, OPEN SOURCE MANAGEMENT: Trends, Requirements
and Future Needs for the Open Source Enterprise

[Jaak 06] Jaaksi, A. Building consumer products with open source. LinuxDevices dec.
2006, http://www.linuxdevices.com/articles/AT7621761066.html

[Jul 06] Jullien N. (ed) New economic models, new software industry economy. RNTL
report

56
[KBST 06] Germany KBSt, Migration guide.

[Kli 05] Klincewicz, K. Innovativeness of open source software projects. Technical

report, School of Innovation Management, Tokyo Institute of Technology. 2005

[Mue 07] Mueller, M. Openoffice.org projects by Members,

http://blogs.sun.com/GullFOSS/entry/openoffice_org_projects_by _members

[OECD 02] OECD, "OECD/Eurostat task force on software measurement in the

national accounts", Conference of European Statisticians, Joint ECE/Eurostat/OECD
meeting on national accounts, 2002

[Ost 04] Osterwalder A, The business model ontology - a proposition in a design

science approach , PhD Dissertation, University of Lausanne, Switzerland, 2004 page
68

[Ost 05] Osterwalder A, Pigneur Y., E-business models and disruptive behaviours,
http://www.businessmodeldesign.com/presentations/PACIS05.ppt

[QSOS 06] QSOS project, Method for Qualification and Selection of Open Source
software
(QSOS) version 1.6.

[Raym 00] Raymond, E.S., The Cathedral and the Bazaar, in The Cathedral and the
Bazaar. 2000

[Reas 06a] Reasoning Inc. A Quantitative Analysis of TCP/IP Implementations in

Commercial Software and in the Linux Kernel.

[Reas 06b] Reasoning Inc. How Open Source and Commercial Software Compare:
Database Implementations in Commercial Software and in MySQL.

[Rig 06] Rigby P.C., German D.M. A preliminary examination of code review
processes in open source projects. University of Victoria technical report, 2006,
http://opensource.mit.edu/papers/Rigby2006TR.pdf

[Ros 05] Rosen L., Open source licensing. Prentice Hall, 2005

[Sei 06] Seigo A., The quest for project identity and definition. Keynote
speech, Akademy conference 2006.

[Sch 02] Schiff, A. The Economics of Open Source Software: A Survey of the
Early Literature. Review of Network Economics, 1 (1), March 2002

[Spi 02] Spiller, D. and T. Wichmann, FLOSS 3: Basics of Open Source

Software Markets and Business Models, in FLOSS - Free/Libre Open
Source Software: Survey and Study. Berlecon Research, Berlin 2002

[Stu 07] Stuermer, M. How money influences open source projects and its
contributors. LinuxTag 2007, Berlin.

57
[Suc 04] Succi, Paulson, Eberlein. An Empirical Study of Open-Source and Closed-
Source Software Products, IEEE TRANSACTIONS ONSOFTWARE ENGINEERING, V.30/4,
april 2004

[Sun 06] Sun Microsystems, Free and Open Source licensing. White paper,
www.sun.com/software/opensource/whitepapers/Sun_Microsyste
ms_OpenSource_Licensing.pdf

[UUS 05] Ueda, M., Uzuki T., Suematsu C. A cluster analysis of open source
page 69 licenses. Proceedings of the First International Conference on Open Source
Systems, Genova 2005

[VH 03] Von Hippel, E. and G. von Krogh, Open Source Software and the “Private-
Collective” Innovation Model: Issues for Organizational Science. Organization
Science, 2003. 14(2): p. 209-223

[VH 05] Von Hippel, E. Democratizing innovation. MIT press, 2005

58
Annexe 1: estimation du nombre de projets logiciels
Open Source actifs
L’un des débats récurrents entre les défenseurs du FLOSS et ses détracteurs est lié à
l'estimation du nombre réel de projets FLOSS actifs. Bien qu'il soit facile de jeter un
coup d'œil au site référentiel principal (sourceforge.net) qui s'enorgueillit de plus de
100.000 projets, il est tout aussi facile de procéder à une analyse plus en profonde et
de se rendre compte qu'un nombre important de ces projets sont en réalité
abandonnés ou n'ont pas été développés de manière significative.

Dans le but d'obtenir une estimation impartiale, nous avons effectué une première
recherche parmi les principaux sites référentiels et les portails d'annonces FLOSS.
Nous avons également défini une condition d'activité stricte : un indice d'activité
allant de 80% à 100% et au moins un lancement de fichier au cours des 6 derniers
mois. Sur les 155959 projets, seuls 10656 (6.8%) sont « actifs ». En définissant une
condition quelque peu moins restrictive, à savoir une période de lancement plus
large (un an), on obtient un pourcentage actif de 9.2%, ou 14455 projets.

Toutefois, alors que Sourceforge peut à juste titre être considéré comme le plus
grand site référentiel, il ne constitue pas la seule source potentielle de projets. En
effet, il existe de nombreux sites référentiels verticaux, dont BerliOS, Savannah, Gna!
et bien d'autres, tous dérivés de la version originale du programme Sourceforge, et
bon nombre d’une version réécrite appelée GForge22.

22 Il a été indiqué aux auteurs que nous risquions de cette manière de compter deux fois les projets qui se déplacent
d'un site vers un autre. En réalité, comme « l'ancien » projet devient inactif, il est éliminé du calcul. Ainsi, le risque est
limité à ceux ont été déplacés au cours des 12 derniers mois seulement (comme cela est assez rare, ils ne sont qu'un
très petit pouvant influencer les pourcentages globaux).

59
En résumé, voici le résultat :

Nom du site référentiel Nombre de projets

Ensemble des sites GForge23 16776
BerliOS sourcewell 3340
Savannah 2793
Gna ! 1039

Cela donne un total de 23948 projets, parmi lesquels (en utilisant un panel de 100
projets de chaque) nous avons identifié un nombre semblable de projets actifs
(entre 8% et 10%).

La prochaine étape consiste en l'estimation du nombre de projets dans le paysage

FLOSS global, qui sont accueillis sur ces sites. Pour ce faire, nous avons utilisé la
banque de données d'annonces de FreshMeat24 dans sa totalité, à l’instar du projet
FLOSSmole25. Nous avons constaté que les projets qui disposent d'une page
d'accueil sur les sites référentiels atteignent 23% du total. Ce total est cependant
biaisé du fait que la probabilité pour un projet d'être publié sur FreshMeat n'est pas la
même pour tous les projets. Autrement dit, ceux basés sur l'anglais et destinés à un
large public ont une probabilité beaucoup plus grande d'être référencés. Pour
prendre ce fait en compte, nous avons effectué une recherche sur des créations
non basées sur l'anglais, et sur des logiciels destinés à un domaine très particulier, en
utilisant les données de projets IST antérieurs, comme Spirit et AMOS. Nous avons
constaté que les projets non-anglais sont sous représentés dans FreshMeat de façon
importante, mais étant donné que la « business-readiness » générale de ces projets
n'est pas claire (par exemple, il peut ne pas y avoir de traductions disponibles, ou ils
peuvent être spécifiques à un environnement juridique d'un seul pays), nous les
avons ignorés. Les projets verticaux sont également sous représentés, en particulier
en ce qui concerne les projets dans des domaines scientifiques et techniques, pour
lesquels la probabilité d'être inclus est 10 fois moindre en comparaison avec les
autres genres de logiciel. En utilisant les résultats de Spirit, un panel d'annonces de
projets dans des listes d'abonnés scientifiques, et certains sites référentiels pour les
projets les plus grands ou les plus visibles (comme l'archive CRAN, qui accueille les
bibliothèques et les packages pour le langage R des statistiques, qui accueille 1195
projets) nous avons atteint une estimation générale plus faible d'environ 12000
projets « verticaux », spécifiques à l'industrie.

Nous disposons donc d'une estimation globale plus faible d'environ 195000 projets,
dont nous pouvons estimer que 7% sont actifs, ce qui donne environ 13000 projets
actifs. Parmi ceux-ci, nous pouvons estimer (en utilisant les données des sites
Slashdot, FreshMeat et des plus grands sites GForge) que 36% se trouvent dans la
phase « stable » ou « mature », ce qui donne environ 5000 projets pouvant convenir
aux PME, à savoir avec une communauté active, stables et avec des lancements
récents.

Il convient de considérer que ce nombre est une estimation plus faible, obtenue
avec des hypothèses quelque peu strictes. De même, cette estimation ne tente pas

23 Comme indiqué dans le calcul du site GForge, http://gforge.org/docman /view.php/l/52/gforge-sites.html

24 Un portail prisé d'annonces FLOSS, www.freshmeat.net
25 Un recueil accompli de collaboration et d'analyse de données FLOSS, http://ossmoe.sourceforge.net/

60
d’évaluer le nombre de projets non repris sur les sites d'annonces (y compris les
portails d'application verticaux). Il s’agit d’un acte délibéré, étant donné qu'il serait
difficile d'estimer la fiabilité d'une telle mesure, et parce que la possibilité de
d'identifier un projet et la probabilité qu'il dispose d'une participation soutenue de la
communauté sont plus faibles s’il est difficile de trouver des informations sur le projet
en premier lieu. Ceci signifie que la probabilité de tels projets en dehors des limites
ne serait vraisemblablement pas une bonne occasion d’être adoptés par les PME.

61
 Annexe 2: tableaux de résultats de l’évaluation
QSOS

Les données fournies sont une synthèse de la méthodologie officielle d’évaluation

QSOS dans sa révision 1.6, disponible à l'adresse www.qsos.org, en même temps que
plusieurs outils utiles pour faciliter les étapes d’évaluation et de recueil des résultats.
L'axe d'évaluation comprend les critères pour estimer les risques encourus par
l'utilisateur en adoptant un logiciel libre ou open source. L’évaluation des critères se
fait indépendamment de tout contexte particulier de l'utilisateur (le contexte est pris
en considération plus tard dans l'Etape 3 – « Qualification »); les critères étant divisés
en cinq catégories :

. Durabilité intrinsèque
. Solution industrialisée
. Intégration
. Adaptabilité technique
. Stratégie

Après une partie « générique », il est possible en fonction du domaine d'application

de créer des formulaires QSOS personnalisés ; l'exemple suivant prend pour modèle
une évaluation du « logiciel de groupe ».

Critère Résultat 0 Résultat 1 Résultat 2

Section générique
Exploitabilité
Facilité d’utilisation, Difficulté d’utilisation, Ergonomie austère et La GUI comprend des
ergonomie demande une très technique fonctions d’aide et une
connaissance ergonomie élaborée
approfondie des
fonctions du logiciel
Administration / Aucune fonction Fonctions existantes Fonctions
Contrôle d’administration ou de mais incomplètes ou d’administration et de
contrôle nécessitent des contrôle complètes et
améliorations faciles à utiliser.
Intégration possible
avec des outils externes
(ex : SNMP, syslog, etc.)

62
Adaptabilité technique
Modularité Logiciel monolithique Présence de modules Conception modulaire,
de haut niveau permettant une
permettant un premier adaptation facile du
niveau d’adaptation logiciel en
du logiciel sélectionnant ou en
créant les modules
Modification du code Tout à la main Recompilation possible Recompilation avec
mais complexe sans outils (ex : make, ANT,
outils ou etc.) et documentation
documentation fournie
Extension du code Toute modification Architecture conçue Principe du plugin,
exige une pour une extension architecture créée
recompilation du code statique, mais exige pour une extension
une recompilation dynamique sans
recompilation
Stratégie
Licence
Permissivité Licence très stricte, Licence permissive Très permissive, comme
comme la GPL modérée situé entre les BSD ou les licences
deux licences Apache
opposées (GPL et BSD)
selon le type
d’utilisateur (personne,
société, etc.) ou ses
activités
Protection contre les Très permissive, comme Licence permissive Licence très stricte,
forks propriétaires BSD ou les licences modérée situé entre les comme la GPL
Apache deux licences
opposées (GPL et BSD)
selon le type
d’utilisateur (personne,
société, etc.) ou ses
activités
Droits d’auteur Droits détenus par Droits détenus par Droits détenus par une
quelques personnes ou plusieurs personnes entité légale en
entités, facilitant la détenant le code de laquelle la
modification de la façon homogène, communauté a
licence rendant la modification confiance (ex : FSF ou
de licence très difficile ASF)
Modification du code Aucun moyen pratique Outils pour accéder au Le processus de
source de proposer une code et le modifier modification du code
modification du code fournis (comme CVS ou est bien défini, exposé
SVN) mais pas toujours et respecté, et basé sur
utiliser pour développer la désignation de rôles.
le logiciel
Calendrier de Aucun calendrier de Calendrier de Calendrier de
lancement lancement publié lancement existant lancement avec
mais sans planification planification et
évaluation des délais
Sponsor Le logiciel n’a pas de Le logiciel dispose d’un Le logiciel est
sponsor, l’équipe sponsor unique sponsorisé par
principale n’est pas pouvant déterminer sa l’industrie
rémunérée stratégie
Indépendance Aucune stratégie Vision stratégique Forte indépendance
stratégique détectable ou forte partagée avec de l’équipe du code,
dépendance d’un d’autres projets libres et entité légale détenant
acteur unique open source mais sans les droits, forte
(personne, société, engagement formel implication dans le
sponsor) des détenteurs des processus de
droits d’auteur standardisation

63
Critère Résultat 0 Résultat 1 Résultat 2
Logiciel de groupe
Administration GUI

Interface web Pas d'interface web Une interface web est Tout peut être effectué
fournie mais limitée avec l'interface web

Mode console Rien Certains outils existent, Accès total à la

mais sont limités. Pas de configuration du
fichier de configuration serveur au moyen
texte, ou non lisible par d'outils puissants et bon
l’homme (ex : XML fichier de configuration
complexe) texte
Rien Un outil limité existe et Un outil puissant donne
Outil d'administration permet à l’utilisateur de accès à presque
seul procéder à une l’ensemble des
opération précise principales
caractéristiques du
serveur
Logiciel de groupe supporté
Calendrier Aucun calendrier fourni Un calendrier est fourni, Un calendrier bien
mais il manque intégré est fourni
certaines
caractéristiques
importantes
Gestionnaire de tâches Aucun gestionnaire de Un gestionnaire de Le gestionnaire de
tâches fourni tâches fourni, mais il tâches fourni est
manque certaines totalement supporté
caractéristiques
importantes
Gestionnaire de notes Aucun gestionnaire de Un gestionnaire de Un gestionnaire de
notes fourni notes limité est fourni notes bien intégré est
fourni
Gestionnaire de Impossible d’ajouter un Un gestionnaire de Le gestionnaire de
relations contact dans le serveur relations existe mais est relations est totalement
limité supporté
Support standard
iCalendar sur WebDav iCalendar sur WebDav iCalendar sur WebDav iCalendar sur WebDav
n’est pas supporté est supporté en partie fonctionne
CalDav CalDav n’est pas CalDav est supporté CalDav fonctionne
supporté en partie
GroupDav GroupDav n’est pas GroupDav est supporté GroupDav fonctionne
supporté en partie
SyncML SyncML n’est pas SyncML est supporté en SyncML fonctionne
supporté partie
Client supporté
Client Web L’interface web n’existe L’interface web est L’interface web est
pas fournie mais est limitée, directement fournie
ou exige un certain avec le projet
travail pour son
intégration
Microsoft Outlook Microsoft Outlook n’est Le connecteur de Connecteur de
pas supporté Microsoft Outlook est Microsoft Outlook
fourni mais limité gratuit
Novell Evolution Novell Evolution ne Novell Evolution peut Novell Evolution est
peut être utilisé être utilisé mais est totalement supporté
limité
KDE KDE PIM (Kagenda, KDE peut être utilisé KDE est totalement
kmail, etc.) ne peut mais est limité supporté
être utilisé avec ce
logiciel de groupe

64
Apple iCal Apple iCal ne peut être Apple iCal peut être Apple iCal est
utilisé utilisé mais est limité totalement supporté
Performance
Équilibre de charge Ce logiciel n’est pas un Une partie de L’équilibre de charge
équilibreur de charge l’installation peut être fonctionne
divisée mais goulot
d’étranglement
important
Qualité du code
Accès à distance API Pas d’accès à distance L’accès à distance API Puissant accès à
API existe (SOAP, distance API (SOAP,
XML/RPC,REST) mais est XML/RPC,REST)
limité ou connaît des
bugs

65