La gestion des connaissances dans les projets open

UNIVERSITÉ DE LAUSANNE
ÉCOLE DES HAUTES ÉTUDES COMMERCIALES
La gestion des connaissances dans les projets open source
Mémoire présenté par Antoine Christen
en vue de l'obtention du
Diplôme postgrade en informatique et organisation
Année académique 2002-2003
devant le jury composé de :
Prof. Estier Thibault, directeur du mémoire
Lathoud Bertrand, expert
Table des Matières
1. INTRODUCTION ..............................................................................................................................................................3
1.1 LES ENJEUX DU KNOWLEDGE M ANAGEMENT ............................................................................................................ 3
Les deux dimensions de la connaissance et du KM..................................................................................................3
Les enjeux et les difficultés du KM en entreprise......................................................................................................4
1.2 LE KM DANS LES PROJETS OP EN SOURCE ................................................................................................................... 4
Définition de l’ « open source »...................................................................................................................................4
L’open source et le KM..................................................................................................................................................5
Problématique.................................................................................................................................................................7
2. ETUDES DE CAS ...............................................................................................................................................................7
2.1 PRESENTATION DE DEUX PROJETS OPEN SOURCE : ZOPE ET CELESTIA .................................................................. 7
Zope (Z Object Publishing Environment)...................................................................................................................7
Celestia.............................................................................................................................................................................8
2.2 STRUCTURE ET ORGANISATION DES DEUX PROJET S .................................................................................................. 9
1) Origine des deux projets...........................................................................................................................................9
2) Enjeux économiques................................................................................................................................................10
3) Communautés...........................................................................................................................................................11
4) Structure hiérarchique............................................................................................................................................11
5) Développeurs............................................................................................................................................................12
6) Degré de modularité du logiciel............................................................................................................................13
6) Stade de développement..........................................................................................................................................13
Synthèse..........................................................................................................................................................................14
2.3 LA GESTION DES CONNAISSANCES DANS LE PROJET ZOPE...................................................................................... 15
Deux tentatives pour expliciter, formaliser et organiser les connaissances :....................................................15
Une capitalisation souple des connaissances grâce au wiki et au système de gestion de contenu ................18
Le Bug Collector : succès du formalisme .................................................................................................................21
L’échange informel sur le canal irc...........................................................................................................................22
L’échange des connaissances « stocké » dans les mailing-lists...........................................................................22
2.4 LA GESTION DES CONNAISSANCES DANS LE PROJET CELESTIA.............................................................................. 26
Les forums : centre de la communauté Celestia......................................................................................................26
Réalisation de la documentation et organisation des ressources.........................................................................28
Pour faciliter l’échange des connaissances et lutter contre le « bruit ».............................................................28
2.5 SYNTHESE DES RESULTAT S ET COMMENTAIRES....................................................................................................... 29
3 CONCLUSION : ................................................................................................................................................................31
Les succès du KM en open source peut-il être étendu à d’autres domaines ?...................................................31
La théorie du KM permet-elle de comprendre ce succès ?....................................................................................32
BIBLIOGRAPHIE................................................................................................................................................................33
Livres et articles............................................................................................................................................................33
Sites internet mentionnés.............................................................................................................................................35
ANNEXES : ............................................................................................................................................................................37
Bref historique de l’open source................................................................................................................................37
L’open-source aujourd’hui.........................................................................................................................................38
8 questions à Chris Laurel, initiateur et "dictateur bénévole pour la vie" du projet Celestia........................40
Etude quantitative de trois listes de distribution de Zope (mois de juillet)........................................................42
Définitions des outils collaboratifs cités dans ce mémoire....................................................................................42
2
1. Introduction
Le sujet de notre étude est la gestion des connaissances dans les projets open source. Nous
donnerons d’abord une définition de la « gestion des connaissance » ou « Knowledge
Management » (KM) pour délimiter et structurer le domaine de notre étude. Après avoir
brièvement mis en évidence les enjeux du KM en entreprise, nous définirons les “projets open
source”. Nous verrons en quoi la gestion des connaissances peut poser problème a priori dans
l’open source, et l’intérêt d’une étude de cas dans ce contexte.
1.1 Les enjeux du Knowledge Management
Les deux dimensions de la connaissance et du KM
Qu’est-ce que le “Knowledge Management” ? Donner une définition de ces termes implique
déjà un certain choix sur la manière de considérer la connaissance et de la gérer 1 . On distingue
généralement deux catégories de connaissances, la connaissance « explicite » et la
connaissance « tacite ». Selon I.Nonaka (2000) :
« Explicit knowledge can be expressed in formal and systematic language and shared in the
form of data, scientific formulae, specifications, manuals and such like […] In contrast, tacit
knowledge is highly personal and hard to formalise. […] Tacit knowledge is deeply rooted in
action, procedures, routines, commitment, ideals, values and emotions. »
Ces deux types de connaissances se retrouvent dans les deux dimensions du KM souvent
relevées par la littérature 2 . Nous distinguerons:
- la capitalisation de connaissances explicites : cette approche implique des efforts pour
isoler et expliciter au maximum les connaissances selon un certain formalisme préétabli, ainsi que leur classement et leur stockage, souvent dans des bases de données.
Le but est de transformer ces connaissances en documents facilement accessibles et
directement utilisables par les collaborateurs.
- l’échange des connaissances tacites dans des interactions interpersonnelles : dans cette
optique, on ne cherche pas à « extraire » des connaissances en les séparant des
personnes qui les possèdent, mais on favorise au contraire les interactions entre les
collaborateurs de l’entreprise, afin que l’échange de connaissances puisse se faire
directement de personne à personne.
On voit que ces deux dimensions sont complémentaires, et que leur réussite dépendra en
grande partie du type de connaissance dont il s’agit. Une connaissance qui peut être explicitée
sous forme de formules, de manuels, etc. pourra être facilement capitalisée et gérée selon la
première approche. Par contre, une connaissance tacite difficile à expliciter, indissociable
d’une manière de faire, sera mieux communiquée dans l’interaction avec autrui. Cette
distinction est utile pour mettre en évidence les difficultés de nature différente auxquelles le
KM est souvent confronté et pour situer le KM dans les projets open source.
1
En d’autres termes, “How you define Knowledge determines how you manage it” (in “12 Principles of
Knowledge Management”, Verna Allee, 2001).
http://www.kmadvantage.com/docs/km_articles/12_Principles_of_Knowledge_Management.pdf.
2 Voir par exemple P.Bouvard (2002) qui parle de « deux versants » distincts, ou Morten T. et al. (1999) qui
présente ces deux dimensions sous forme de stratégies complémentaires du KM. Nous nous inspirons de ces
deux auteurs pour présenter ce qui suit.
3
Les enjeux et les difficultés du KM en entreprise
L’importance du KM est aujourd’hui largement reconnue. On peut citer par exemple les
résultats d’une étude conduite en l’an 2000 par KPMG auprès de 423 entreprises en Europe et
aux Etats-Unis 3 :
- « KM is an accepted part of the business agenda » : en effet, 80% des entreprises
interrogées possèdent ou envisagent un programme de KM
- « The benefits of KM are being realised » : la plupart des entreprises interrogées
pensent ainsi que le KM va jouer désormais un rôle significatif, notamment pour
obtenir un avantage concurrentiel (79%) et comme moteur de l’innovation (64%).
Toutefois, les résultats de l’étude montrent également que le KM n’a pas encore atteint ses
objectifs :
- « There are even greater benefits to be gained »
- « Organisations are failing to tackle KM’s real challenges »
Les auteurs font souvent débuter l’histoire du KM avec l’émergence des nouvelles
technologies de l’information, celles-ci permettant d’une part de codifier, filtrer, classer et
stocker les connaissances explicites, et d’autre part de faciliter les échanges directs entre les
collaborateurs indépendamment de leur lieu de travail. Mais cette courte histoire a déjà
rencontré plusieurs « générations » de KM : chacune ayant montré ses limites, on a tenté de
les dépasser par une nouvelle solution. Parmi les difficultés auxquelles le KM se trouve
confronté dans les entreprises, on peut citer par exemple :
- le manque de temps et de motivation pour partager ses connaissances
- le fait que le partage ne soit pas intégré à l’activité professionnelle
- la difficulté d’isoler les connaissances stratégiques parmi la quantité d’informations
disponibles
- la difficulté à repérer et expliciter les connaissances implicites
En d’autres termes, la technologie, bien que support indispensable à un programme de KM,
n’est pas le seul aspect à considérer. Il faut tenir compte de difficultés liées au facteur humain
et à la nature de la connaissance qui sont souvent à l’origine de l’échec du KM en entreprise.
Les auteurs soulignent ainsi le coût du KM, l’importance de certaines procédures, du rôle de
« directeur de connaissance », etc 4 . Qu’en est- il dans les projets open source ?
1.2 Le KM dans les projets open source
Définition de l’ « open source » 5
L’« open source » se base sur une idée simple : contrairement aux logiciels propriétaires, dont
le code est compilé en langage machine (qui ne peut donc plus être lu par l’utilisateur), il
3
Parlby D. (2000).
Par exemple : “KM is expensive. KM requires knowledge managers. Sharing and using K are often unnatural
acts. KM requires a knowledge contract” (4 principes parmi les « Ten Principles of Knowledge Management »,
Thomas H.Davenport, PhD, tiré de site web: www.mccombs.utexas.edu/kman/kmprin.htm )
5
Pour une introduction plus complète au phénomène open source, on se rapportera aux annexes : « Brève
histoire de l’open source » et « L’open source aujourd’hui ».
4
4
s’agit de fournir le code source du logiciel développé et d'autoriser sa modification. La licence
de type open source est bien une licence au sens propre : les produits open source ne sont
donc pas dans le domaine public et leur distribution doit se faire selon certaines règles. Sans
entrer dans les détails, notons que la définition officielle de l’open source 6 pose
principalement des garanties pour que l’ouverture du code et sa diffusion ne soient pas
contournées. Par exemple, les extraits suivants garantissent l'accès au code source 7 :
- "il doit être clairement indiqué par quel moyen il est possible d'obtenir le code source,
pour une somme qui ne doit pas excéder un coût raisonnable de reproduction"
- "un code source délibérément confus est interdit. Les formes intermédiaires de code
source, telles que celles résultant d'un pré-processeur ou d'un traducteur, sont
interdites."
Et pour garantir la diffusion maximale du code, la définition contient par exemple:
- "la licence ne doit pas être discriminative à l'encontre de personnes ou de groupes de
personnes"
- "la licence ne doit pas restreindre ni interdire l'usage du logiciel à un quelconque
domaine d'activité".
Ce principe d’ouverture a pour conséquence immédiate et recherchée la possibilité de
communiquer et de coopérer dans l’élaboration et le perfectionnement du code source. Dans
les faits, cette possibilité s’est concrétisée sous la forme de projets basés sur des plateformes
internet, regroupant autour du développement d’un logiciel ouvert une équipe de
développeurs et une communauté d’utilisateurs contribuant de près ou de loin à l’amélioration
du logiciel.
L’open source et le KM
Par le fait qu’ils reposent par essence sur la collaboration entre de nombreux participants, les
projets open source constituent un domaine privilégié pour étudier l’échange et la mise en
commun des connaissances. Mais il y a plus : le principe d’ouverture du code se retrouve au
niveau de la gestion de projet en général :
- toutes les communications à l’intérieur d’un projet open source ont lieu dans des
espaces publics. En d’autres termes, à partir d’une simple connexion internet, toute
personne peut accéder librement à l’ensemble des communications internes du projet,
présentées sous la forme de mails, messages dans des forums, pages internet
dynamiques (wiki,blogs), canaux de discussion (irc), etc 8 . (Cet accès facilite
évidemment l’étude du KM.)
- la participation à un projet est entièrement ouverte : toute personne peut rejoindre la
communauté, même sous couvert de l’anonymat, et n’importe quel participant peut
quitter un projet en cours 9 .
En ce qui concerne la gestion des connaissances selon ses deux dimensions, nous faisons
l’hypothèse que ce principe d’ouverture déployé à l’extrême pose a priori les difficultés
suivantes:
6
Cette définition donne les critères qu’une licence devrait respecter pour être qualifiée d’open source.
On trouvera la définition complète à l'adresse suivante: http://www.opensource.org/docs/definition.php Les
citations sont tirées de la version française disponible sur http://www.boson2x.org/article.php3?id_article=39
8
L’ensemble des outils collaboratifs cités dans ce travail sont définis dans les annexes.
9
A l’exception des projets auxquels participent des entreprises puisqu’une partie au moins des développeurs sont
sous contrat.
7
5
Dimension « Capitalisation des connaissances explicites »
Les participants aux projets open source :
- sont principalement motivés par la réalisation de fonctionnalités qui leur sont
directement utiles 10 , non par la réalisation de documentation qui est d’ailleurs souvent
présenté avec humour comme une « punition » dans le monde des hackers.
- ont un profil social, professionnel, linguistique et culturel variable, ce qui ne facilite
pas l’acceptation d’un formalisme commun.
- peuvent quitter un projet n’importe quand (il n’est pas nécessaire d’expliciter ses
connaissances ni de les transmettre à un éventuel successeur avant de partir).
L’effort pour expliciter ses connaissances, les organiser et les mettre à disposition selon un
formalisme préétabli a donc peu de chance d’être fourni. Les connaissances seront
probablement à découvrir sous forme de communications dispersées dans les forums, mailinglists ou autres outils utilisés. Or, l’afflux de participants aux profils divers risque de générer
beaucoup de « bruit » et d’empêcher l’accès à ces connaissances mal explicitées et
dispersées.
Dimension « Echange des connaissances tacites »
Les connaissances tacites peuvent-elles être échangées exclusivement par des moyens
informatiques ? Cette question est souvent posée par les auteurs dans la littérature sur le KM :
il existe en effet un apparent conflit entre le développement des outils informatiques pour
l’échange de connaissance, et l’observation que cet échange est en réalité profondément
dépendant d’une situation de « face-à-face »11 , principalement lorsque ces connaissances ne
peuvent pas être formalisées. L’échange des connaissances tacites et l’élaboration de
nouvelles connaissances semble en effet nécessiter bien plus qu’un simple échange
asynchrone de phrases écrites. Le face-à-face rend possible une communication riche où des
intonations, des gestes, des attitudes et le contexte commun contribuent à donner sens aux
mots échangés, et où la dynamique de la discussion (séquences, interruptions, etc.) joue un
rôle important dans la compréhension réciproque. Ainsi, selon Nonaka et al.(2000) : « Since
tacite knowledge is difficult to formalise and often time- and space- specific, tacit knowledge
can be acquired only through shared experience, such as spending time together or living in
the same environment. ». Citant Nonaka, P.Bouvard en conclut (2002, p.99) « Croire ainsi
que la technologie, quels qu’en soient le degré de sophistication et la puissance, peut
constituer le seul support du Knowledge Management est, selon nous, une utopie » (nous
soulignons).
La technologie est pourtant bel et bien le seul support des projets open source, qui n’existent
que « par » et « dans » les outils collaboratifs sur Internet (cvs, forum, mailing lists, etc.). La
dispersion géographique des participants rend d’ailleurs très souvent des réunions « en
personne » irréalisables. Comment la connaissance tacite peut-elle être échangée entre deux
personnes de culture différente, de langue maternelle différente, de profil socioprofessionnel
différent dans des canaux de communications différés et relativement étroits ? Il faut préciser
encore ici que l’anonymat est largement répandu dans les communautés open source
10
Voir par exemple la première leçon tirée du développement open source par E.S.Raymond (1998): “Every
good work of software starts by scratching a developer's personal itch.”
11
Cette obervation est à l’origine d’un projet de recherche de trois ans financée par le "US National Science
Foundation" dont le titre principal est : « Can Knowledge be Distributed ?»
(http://alexia.lis.uiuc.edu/~haythorn/DK_overview.html).
6
(volontaire ou de fait à cause du nombre de participants). Si l’on ne sait pas à qui l’on
s’adresse, comment éviter les malentendus ? Par exemple, comment répondre à la question de
quelqu’un dont on ne connaît pas le niveau de compétence ? Et dans ces conditions, comment
faire confiance à autrui ?
Problématique
Résumons les résultats obtenus jusqu’ici afin de formuler notre problématique :
-
le Knowledge Management est reconnu comme essentiel par la majorité des
entreprises. Comme moteur de l’innovation, il est également très important pour les
projets open source.
Pourtant :
- la technologie ne suffit pas à faire du KM : il faut tenir compte de facteurs
organisationnels et humains. Dans ce but, les auteurs recommandent la mise en place
de procédures qui garantissent la réussite du programme de KM. L’open source n’a
dans la majorité des cas pas de financement externe et l’afflux de participants aux
profils divers n’est a priori pas compatible avec la mise en place de procédures
strictes.
- certaines connaissances peuvent difficilement se transmettre à l’aide des nouvelles
technologies. L’open source repose exclusivement sur celles-ci.
Comment la gestion des connaissances, essentielle dans le développement en commun d’un
logiciel, peut-elle être menée à bien lorsqu’elle présente a priori de telles difficultés ? Quelles
conditions facilitent la capitalisation et l’échange des connaissances ? Quels outils sont mis à
profit ? Quels mécanismes formels et informels sont mis en œuvre ?
Pour tenter de répondre à ces questions, nous avons choisi d’étudier deux cas concrets de
projets open source de nature différente, mais qui partagent les caractéristiques principales
citées dans cette introduction :
- ce sont des projets open source au sens technique: dans les deux cas la licence du
logiciel est certifiée open source par l’Open source Initiative (OSI)
- chacun des deux logiciels a suscité l’intérêt d’une communauté d’utilisateurs réunie
autour de son développement
2. Etudes de cas
2.1 Présentation de deux projets open source : Zope et Celestia
Les deux projets choisis sont « Zope » (www.zope.org) et « Celestia »
(www.shatters.net/celestia). Commençons par présenter brièvement les logiciels développés et
le succès qu’ils rencontrent.
Zope (Z Object Publishing Environment)
7
Zope est un serveur d’applications permettant la réalisation de systèmes de gestion de contenu
ou CMS (Content Management System), de portails intranet et d’applications accessibles via
un navigateur internet. Zope ne s’adresse donc pas directement aux «end- users », mais se
présente plutôt comme un terrain sur lequel les applications vont être développées. Selon un
interview de Paul Everitt (co- fondateur de Zope Corporation) : «Zope is for developers who
create useful things for other audiences. »12
Le nombre de serveurs Zope visibles sur internet est un indice de son succès - ce nombre a
doublé au cours des 12 derniers mois :
Nombre de serveurs Zope*
23'164
25000
20000
15000
10000
5000
oc
t.0
3
jui
n.0
3
ao
ût.
03
av
r.0
3
fév
r.0
3
dé
c.0
2
oc
t.0
2
0
*selon http://www.netcraft.com/S urvey/Reports/
Notons enfin que dans son rôle de systèmes de gestion de contenu (CMS), Zope est présenté
comme le projet open source le plus mature (par rapport aux autres CMS) par le Gartner
Group (N. Drakos, 2002).
Celestia
Celestia est un simulateur spatial en trois dimensions qui permet de « naviguer » dans l’espace
et d’observer des phénomènes à différentes échelles depuis la position d’une ville sur terre
jusqu’à l’ensemble de notre galaxie. Les qualités graphiques exceptionnelles et des données
détaillées sur les corps célestes permettent au logiciel de s’adapter au niveau et à l’intérêt de
l’utilisateur. L’utilisation de scripts permet également de diriger automatiquement l’utilisateur
vers un phénomène particulier et d’afficher les commentaires adéquats. Celestia se prête donc
bien à un usage éducatif, ce que confirme l’intérêt de la Nasa pour Celestia dans le cadre de
son « Learning Technologies Project » : un mandat ponctuel a été récemment confié à
plusieurs membres du projet pour la réalisation de « leçons » fonctionnant avec Celestia et on
note l’existence d’un site de présentation du système solaire qui implique l’installation de
Celestia en local13 .
12
Interview réalisé par Daniel Chudnov (2001) (voir Bibliographie/références internet).
13 Une fois le logiciel installé, il suffit de cliquer sur les photos du site internet pour retrouver, dans Celestia, la
même vue. (http://learn.arc.nasa.gov/planets/)
8
Le guide de l’utilisateur souligne également le succès du logiciel : celui-ci aurait été
téléchargé plus d’un million de fois. On constate enfin que les commentaires des internautes
sur les sites de téléchargements gratuits, forums, weblogs privés, sites de news (p.ex.
Slashdot) sont souvent élogieux.
2.2 Structure et organisation des deux projets
Avant de nous intéresser aux principes et outils mis en œuvre pour gérer la connaissance dans
les deux projets, il est utile de présenter les principales caractéristiques de leur organisation.
C’est aussi l’occasion de mesurer le cas échéant les différences entre les deux projets et leurs
éventuelles originalités par rapport aux projets open source en général.
1) Origine des deux projets
Celestia :
Initiative d’un développeur de Seattle nommé Chris J. Laurel, le logiciel est proposé sur
internet dans sa version 1.0 en 2001. Le projet rallie rapidement des participants enthousiastes
et il est placé sous licence open source. La plateforme SourceForge 14 est mise à profit.
Comme l’explique C.J.Laurel lui- même 15 : “I did indeed start Celestia myself. I found out
about SourceForge within a month of the first public announcement of Celestia. I
immediately started a SourceForge project for Celestia and checked in all the source code to
the SourceForge CVS servers. Once that was done, allowing other developers to help out was
simply a matter of adding their SourceForge accounts to the developers' list.”
Pour comprendre la manière dont ce projet a pu accueillir de nouveaux développeurs, il est
utile d’expliquer ici brièvement le système « CVS » ou Concurrent Versions System utilisé
par Celestia et par la plupart des logiciels open source. Ce système permet de coordonner le
développement de plusieurs développeurs grâce au fonctionnement suivant : un lieu de
stockage central du code (appelé « repository ») contient sous forme d’arborescence
l’ensemble des fichiers sources du logiciel. En utilisant un logiciel de type CVS, un
développeur peut télécharger l’ensemble de ces fichiers sur son disque local. Le logiciel est
utilisé ensuite pour comparer régulièrement la version locale et la version centrale du code
source pour ne télécharger que les fichiers modifiés. Cet accès en lecture seule se combine
avec un accès en écriture, pour lesquels certains droits sont requis : une fois que le
développeur a modifié un fichier en local, il peut mettre sa modification à jour sur le
repository central (processus appelé « commit »). Un message associé, qui explique les
raisons de la modification, sera visible dans l’historique du code source central et l’ancienne
version du fichier modifié sera archivée.
Le chemin suivi par Celestia est celui que parcourent la plupart des projets open source qui
rencontrent un certain succès: un logiciel est développé en solitaire jusqu’à ce qu’il possède
certaines fonctionnalité de base, puis il est mis à disposition sur internet avec une licence open
source, et les développeurs intéressés commencent à rejoindre le projet grâce au système
14
SourceForge fournit gratuitement une plateforme pour les projets open source, avec des outils (cvs, mailinglist, forum, bug tracker, etc.). Le responsable d’un projet peut choisir parmi les outils mis à disposition ceux qu’il
veut utiliser.
15
Voir annexes: Questions à C.J.Laurel
9
CVS. L’organisation du projet s’adapte ensuite au succès rencontré. Comme nous allons le
voir, le cas du projet Zope est assez différent.
Zope 16 :
En 1998, Digital Creations (DC) réoriente son core-business : jusqu’ici, il s’agissait de vendre
des logiciels – désormais, DC donne à ses produits (regroupés sous le nom de Zope) une
licence open source et s’affirme comme société de consulting. La stratégie est la suivante : il
s’agit de susciter l’intérêt de la communauté open source – non seulement pour améliorer le
logiciel grâce à l’apport de nombreux développeurs, débuggeurs, etc. mais aussi dans le but de
faire de Zope un standard de fait dans le domaine des serveurs d’applications. DC pourra ainsi
se présenter comme le spécialiste de la plateforme et proposer aux futurs clients des solutions
basées sur ce standard.
Aujourd’hui on peut considérer que le pari de Digital Creations – rebaptisé en « Zope
Corporation » (ZC)17 - est réussi. Cette entreprise a pu acquérir de nombreux clients (p.ex. :
l’ « OTAN », la « Navy », la « Bank of America », etc.) et continue à contribuer au
développement de Zope.
2) Enjeux économiques
Comme on le constate avec l’exemple de Zope, l’open source n’est pas (seulement) un
phénomène gouverné par des idéalistes pour lesquels tout doit être « gratuit », mais c’est aussi
une opportunité que de nombreuses entreprises ont déjà tenté de saisir avec plus ou moins de
succès.
Selon la page d’accueil de la communauté Zope.org, des centaines d’entreprises contribuent
au développement de Zope. Ce sont principalement des sociétés de service qui se basent sur
Zope pour du conseil ou le développement de solutions. Au-delà des contributions au
développement de la plateforme, ces entreprises tentent de promouvoir Zope, par exemple en
Europe à travers la « Zope Europe Association » (soutenue financièrement par ZC et plusieurs
entreprises européennes).
Quelles sont les influences de la participation des entreprises à un projet open source ?
Mockus et al. (2001), qui ont étudié le projet Mozilla (créé à la suite de l’ouverture du code de
Netscape) font l’hypothèse suivante: le fait que certains développeurs soient sous contrat
pourrait expliquer l’existence d’un mode plus formel et industriel de développement, par
rapport à un projet open source classique. On peut aussi penser que l’apport financier rend
possible une organisation plus élaborée du projet – notamment pour gérer au mieux l’afflux
des nouveaux participants.
Les enjeux économiques liés au projet Celestia sont au contraire pratiquement inexistants.
Excepté le mandat ponctuel déjà cité, le forum met surtout en évidence le bénévolat des
participants (« we are all in for the fun of it, right ? »). Le projet n’a donc apparemment aucun
soutien financier régulier - ce qui conduit à certaines difficultés discutées de manière
récurrente dans les forums :
16
17
Sources: Interviews conduits par S.Litt (1999) et D.Chudnov (2001) (voir Bibliographie - références internet)
http://www.zope.com/News/PressReleases/DC2ZC
10
-
le serveur principal du projet est hébergé chez le développeur principal et sa connexion
internet est parfois saturée (ce qui rend la navigation dans les forums très lente).
la distribution du logiciel pose problème (limite de bande passante et d’espace de stockage
en ligne, coût pour réaliser un cdrom, etc.)
3) Communautés
Zope :
Selon le site Zope.org, des milliers de développeurs travaillent avec la plateforme Zope, soit
pour développer la plateforme de base (le serveur d’application) soit pour créer des
applications fonctionnant sur cette plateforme. Ces dernières pouvant être des projets open
source (p.ex. le système de gestion de contenu CMF-Plone) ou non (p.ex. Zope4Edu – un CMS
pour les universités ). Comme nous le verrons dans notre étude, le canal de communication le
plus utilisé par la communauté Zope est la mailing- list : des milliers de personnes sont
inscrites aux listes principales et, sur une période d’un mois, des centaines de participants
envoient effectivement un ou plusieurs messages.
La communauté Zope est donc immense, surtout si l’on considère qu’autour du site principal
Zope.org se sont développés d’autres regroupements autour d’intérêts plus spécifique 18 ou de
communauté linguistique différente.
Celestia :
Selon le « guide de l’utilisateur »19 , la communauté regroupe notamment « des artistes
graphiques, des développeurs programmeurs, des astronomes, des astrophysiciens, des
animateurs, des ingénieurs, des professeurs, des élèves […]. ». On peut évaluer la taille de
cette communauté d’après le nombre de personnes actives dans les forums, pour l’instant
unique canal de communication de la communauté (à l’exception d’une mailing- list utilisée
par les quelques développeurs). Sur environ 1000 personnes inscrites 20 , la moitié a
effectivement écrit un message au moins dans un des forums en ligne depuis janvier 2002. 21
Celestia est une communauté nettement plus petite que celle de Zope: si on note également la
présence de sites satellites consacrés à Celestia, ceux-ci ne sont souvent que des sites de
téléchargements.
4) Structure hiérarchique
Il semble que l’initiateur du projet Celestia, C.J.Laurel, puisse être qualifié de « dictateur
bénévole pour la vie ». Cette notion qualifie en open source les leaders reconnus de certains
projets. Par exemple, Linus Torvalds pour le noyau Linux ou Guido van Rossum pour le
langage Python22 . Du « dictateur », C.J.Laurel possède le pouvoir : il est responsable de la
18
p.ex. pour une application particulière, comme le montre l’exemple de l’importante communauté Plone
www.plone.org
19
Rédigé en anglais et traduit en français, celui-ci est disponible sur le site du projet.
20 Bien qu’il ne soit pas possible d’évaluer leur nombre, il faut aussi noter la présence de contributeurs
anonymes – il n’est pas nécessaire d’être inscrit pour poster un message.
21 Date de la migration des forums sur la plateforme actuelle (les anciens forums ne sont plus accessibles).
22 Traduction de « Benevolent Dictator for Life ». Voir par exemple:
http://www.wikipedia.org/wiki/Benevolent_Dictator_for_Life
11
mise sur pied des release officielle 23 , la licence du logiciel est à son nom et il héberge le
serveur principal du projet. Ce pouvoir est en fait relatif, puisque la licence open source du
logiciel autorise n’importe quel internaute à démarrer son propre projet en partant de la
dernière version du logiciel24 . Toutefois, le statut de Chris Laurel est bien reconnu par la
communauté et son avis est rarement discuté dans les forums et sur la liste consacrée au
développement. Il faut dire que Chris Laurel apparaît effectivement comme un dictateur
« bénévole », d’abord au sens propre mais aussi d’une manière plus large : il est dévoué à la
réussite du projet :
- il semble être le développeur le plus productif
- il contribue beaucoup aux forums (en terme de réponses aux questions posées).
- il demande l’avis des autres développeurs voire de la communauté (par exemple, le choix
d’un nouveau langage pour les scripts à été soumis à un vote sur le forum) et prend
souvent en compte les suggestions des membres de la communauté (mêmes s’ils ne sont
que périphériques).
La structure hiérarchique est donc rudimentaire dans le projet Celestia. Comme Chris Laurel
l’explique, la coordination repose sur les simples règles de la politesse 25 . L’accès à la CVS en
écriture et les droits d’administrateur dans les forums font une distinction de fait entre les
développeurs principaux et les participants périphériques.
Zope
Le développement de Zope ne dépend pas seulement des souhaits des membres actifs de la
communauté, mais aussi des demandes des clients de ZC – et celles-ci ne vont pas forcément
dans le même sens. Comme l’expliquait Paul Everitt en mars 2001: “[..]there are times where
the choice has to be made, and this almost always means the consulting customer wins”.
Aujourd’hui, l’accès en écriture au code via le CVS n’est toutefois plus l’apanage de Zope
Corporation : il a été ouvert à certains membres de la communauté dès l’automne 200126.
Malgré cette évolution, il semble que ZC dirige encore en grande partie la direction générale
prise par le projet.
5) Développeurs
Qui sont les développeurs principaux de Celestia ? D’après le guide de l’utilisateur et la page
du projet sur SourceForge, on peut citer Chris Laurel, Christophe Teyssier, Clint Weisbrod,
Bob Ippolito et Fridger Schrempp. Notons que la dispersion géographique des développeurs,
propre aux projets open source, est bien représentée ici : les lieux de domicile cités sont New
York, Seattle, Lyon et Hambourg (les autres ne sont pas précisés). En ce qui concerne la
programmation du logiciel, Mockus et al. (2001) font l’hypothèse que la gestion des
interdépendances a un degré de complexité tel qu’elle nécessite une petite équipe (moins de
15 personnes), surtout si les mécanismes de coordination à l’œuvre dans le projet sont
23 Comme le montre l’extrait suivant : « A new version is long overdue, but I'm not yet prepared to commit to a
date when it will be ready.” http://www.shatters.net/forum/viewtopic.php?t=3151
24
Ce phénomène qui apparaît parfois dans l’open source à la suite d’une divergence d’intérêt entre développeurs
et qui voit ainsi deux projets co-exister s’appelle le « forking ». Celestia représente plutôt le cas inverse : un
autre projet, Open Universe, a été abandonné par ses développeurs pour rejoindre le projet Celestia. Voir à ce
sujet la page d’accueil de http://www.openuniverse.org/
25
voir Questions à Chris Laurel (annexes)
26
Selon le site internet Zope.org: “In autumn 2001, Zope Corporation (ZC) begins the major step of opening the
Zope CVS repository to external contributions by trusted community members”
http://dev.zope.org/CVS/ContributorIntroduction
12
informels. Celestia ne dément pas cette hypothèse : une petite équipe de développeur se
coordonne principalement grâce à des communications informelles. Quant au projet Zope, où
le nombre total de développeurs est beaucoup plus nombreux, on constate effectivement que
le développement s’organise autour de modules, ce qui permet de répartir les développeurs en
petites équipes. Ceci est rendu possible par la modularité du logiciel.
6) Degré de modularité du logiciel
Qu’est-ce que la modularité ? Selon Baldwin et Clark: « [modularity is] a particular design
structure, in which parameters and tasks are interdependent within units (modules) and
independent across them »27 . Par le fait qu’elle diminue les interdépendances entre modules,
la modularité autorise une organisation plus spontanée et moins formelle du travail entre les
groupes chargés d’élaborer ces modules. Il faut noter toutefois qu’une modularité parfaite
n’est qu’un idéal à atteindre, et qu’en pratique on distingue différents degrés de modularité.
La modularité est grande dans les deux projets étudiés :
- Celestia est composé d’un noyau et d’ « add-ons » qui lui ajoutent des fonctionnalités. Il
en existe une centaine, par exemple pour observer d’autres galaxies, des exo planètes, des
engins spatiaux, des systèmes repris d’œuvres de fictions, etc. Dans de nombreux cas, la
réalisation de ces ajouts ne nécessitent pas de compétences en programmation, mais plutôt
des compétences de graphistes, d’astronome, etc. Le développement de Celestia est donc
l’investissement de nombreux contributeurs (et pas seulement des quelques développeurs
cités plus haut)
- Dans Zope, la modularité est garantie par la notion de « produits » qui viennent s’ajouter à
la plateforme Zope en lui ajoutant des fonctionnalités. Il existe au moins une centaine de
produits. Citons en guise d’exemple le Content Management FrameWork pour créer un
système de gestion de contenu – sur lequel vient se greffer « Plone », lui- même un produit
offrant une solution CMS clé en main.
6) Stade de développement
On peut distinguer différentes phases d’un projet open source en fonction de l’état du
délivrable. Zope et Celestia ont passé avec succès ce qu’on peut appeler la « phase initiale »,
celle qui s’achève avec une première version officielle du logiciel (en principe la 1.0), qui
offre peu de fonctionnalités mais représente un potentiel intéressant.
Nous faisons l’hypothèse que la maturité d’un projet peut être ensuite évaluée notamment à
l’aide des deux critères suivants:
- la facilité d’accès facilité pour le nouveau participant et l’utilisateur, notamment grâce à la
disponibilité des ressources nécessaires (téléchargement du logiciel, instructions et facilité
d’installation, manuel utilisateur, etc.)
- le déplacement de l’innovation au niveau des modules. Ce critère est mis en évidence par
Tuomi (2001) dans son étude du kernel linux : une fois que le kernel est entré dans sa
phase de maturité, l’innovation a été reportée au niveau des modules pour que l’interface
avec leur ressource commune reste stable.
27
Cité par Narduzzo et al. (2003)
13
Selon ces deux critères, Celestia peut être vu considéré comme au début de la phase de
maturité, avec l’apparition d’une documentation utilisateur et le développement de nombreux
modules (add-ons, scripts, textures, etc.). L’innovation n’est toutefois pas limitée au niveau du
noyau et les nouvelles versions nécessitent des légers remaniements dans l’installation des
modules.
Zope se trouve dans une phase de maturité avec sa version 2.x. Toutefois, une phase de
restructuration du noyau est prévue pour la version 3.x. Selon le site Zope.org, la première
étape est de créer « Zope 3 expérimental (Zope X3) » qui ne supporte pas les produits de Zope
2.x. Ensuite, il est prévu de réaliser Zope 3.0 qui permettra, à travers certains mécanismes de
conversion, d’utiliser le contenu et les produits développés avec Zope 2.x. Une telle
restructuration n’est pas exceptionnelle dans les projets open source matures - citons par
exemple le cas du projet Apache: les modules créés pour Apache 1.x ne fonctionnent en effet
pas sans autre avec la nouvelle version Apache 2.x.
Synthèse
Si les deux projets ont pour point commun une licence open source 28 et la présence d’une
communauté réunie autour du développement du logiciel, on voit qu’ils sont par ailleurs fort
différents (voir tableau ci-dessous). Il sera intéressant de voir si cette différence est sensible
dans la manière de gérer la connaissance dans les deux projets. Cela nous donne également
une idée de la diversité qui se cache derrière les termes de « projet open source ».
Zope
Produit à l’origine
propriétaire placé ensuite sous
licence open source
Enjeux économiques
De nombreuses entreprises
offrent des services de conseil
et de développement basé sur
Zope
Phase dans laquelle se Version 2.6.2 (phase de
trouve le projet (oct. 03)
maturité) et Version 3.x.y
(restructuration)
Communauté principale
Des milliers de développeurs
- une minorité contribuant au
développement de la
plateforme Zope et de ses
produits (les utilisateurs de
Zope sont aussi des
développeurs).
Sites et communautés De nombreux sites satellites,
satellites
noyaux parfois de
Origine du projet
Celestia
Développement individuel mis
sous licence open source dès la
version 1.0.
Peu d’enjeux économiques,
développeurs bénévoles.
Version 1.3.0 (début de la phase
de maturité)
Quelques développeurs, des
dizaines de personnes contribuant
sous forme d’add-ons (textures,
modèles, données, scripts, etc.) et
une communauté d’environ 500
personnes inscrites et actives dans
un forum.
Quelques sites satellites peu actifs
28
Sans entrer dans les détails, notons que Celestia possède une licence « GPL » (Gnu Public Licence) et Zope
une licence propre appelée Zope Public License (reconnue compatible avec la GPL selon
http://www.gnu.org/philosophy/license-list.html) qui contient certaines références à Zope Corporation. Toutes
deux sont en accord avec la définition de l’open source.
14
communautés Zope avec un
intérêt spécifique.
2.3 La gestion des connaissances dans le projet Zope29
Deux tentatives
connaissances :
pour
expliciter,
formaliser
et
organiser
les
La volonté de capitaliser des connaissances explicites est sensible sur le site Zope.org à
travers deux initiatives: le « Zope Documentation Project » et le « Fishbowl Process ».
Voyons- les en détail.
Le « Zope Documentation Project »
Le projet « Zope Documentation Project » (ZDP) est décrit de la manière suivante :
« a volunteer effort (RAH RAH!) to improve the documentation and other information
resources, at least initially a FAQ and howto's, for the Zope community” 30 .
La description de la liste de distribution consacrée à ce projet 31 exprime clairement ses
objectifs:
- diminuer la redondance des questions dans la liste de distribution principale (zope-user)
en créant et en organisant une FAQ
- améliorer l’accessibilité de Zope grâce à la documentation et des howtos
- développer des logiciels permettant de gérer la documentation générée par le projet.
En d’autres termes, le but est d’expliciter des connaissances (des réponses de base, des
manières de procéder) et de gérer leur organisation afin de les rendre facilement accessibles et
compréhensibles indépendamment des personnes qui les ont produites. Cette volonté se situe
bien dans la dimension du Knowledge Management que nous avons appelée la « capitalisation
des connaissances explicites ».
Si l’on s’intéresse maintenant à l’activité effectivement générée par ce projet, on note les
points suivants:
- la liste de distribution consacrée au projet ZDP est pour ainsi dire inactive : bien que 270
personnes soient inscrites, 7 messages seulement ont été envoyé s sur le mois de juillet (par
comparaison, sur la même période les autres listes ont souvent plusieurs centaines de
messages).
- le site dédié à ce projet 32 met aussi en évidence le manque d’intérêt manifesté par la
communauté pour sa mise en œuvre. On constate en effet que les documents les plus
récemment modifiés datent de plus d’une année - l’internaute est d’ailleurs averti dès la
29
Nous avons vu que le site principal de Zope était entouré de sites satellites parfois importants. Pour ne pas se
perdre dans cette diversité, nous limiterons le champ de cette étude au site principal du projet (Zope.org) et aux
outils qui y sont directement rattachés.
30
on perçoit dans l’humour du propos l’idée très répandue en open source selon laquelle la réalisation de la
documentation est une tâche peu motivante.
31
http://mail.zope.org/mailman/listinfo/zdp
32
http://zdp.zope.org/
15
page d’accueil: « This site has information about […] Zope. There is mostly outdated
information, which may still be of some value to some people. While this is not a
satisfying situation, nothing stops you from changing that. So, if someone feels like taking
over one of these projects, send a mail to the ZDP mailing list [email protected]. ».
Cette tentative pour formaliser, organiser et capitaliser certaines connaissances de base a donc
rencontré à première vue très peu de succès. Avant de nous intéresser à la documentation
effectivement disponible, étudions une seconde initiative présentée sur le site Zope.org et
visant à capitaliser des connaissances explicites.
Le « Fishbowl Process »
Qu’est-ce que le “Fishbowl Process” ? Expliquons d’abord le terme de « fishbowl ». Selon le
site Zope.org :
“The name "fishbowl" comes from the idea brought to prominence by Mozilla.org that there
are no internal conversations; rather, all communication, decisions, arguments, and progress is
visible as if everyone were working "in a fishbowl".”33
Ce terme explicite donc le principe fondamental selon lequel les communications doivent être
ouvertes, accessibles à tous. Nous avons vu dans l’introduction que ce principe est valable
pour la plupart des projets open source. Mais les détails du “Fishbowl Process” vont bien plus
loin que le simple respect de ce principe puisqu’il s’agit bel et bien d’un processus de
développement que les manager du projet tentent d’imposer : “The Fishbowl Process is the
way the community, including Digital Creations, will design and develop Zope.”
Ce processus exige que les projets de développements passent par certaines phases, chacune
d’entre elles étant découpées en étapes et impliquant un certain formalisme et des délivrables
- le Fishbowl Process facilite ainsi une certaine capitalisatio n des connaissances. Considérons
la première phase à titre d’exemple. Cette phase nommée « Inception » concerne la création
des propositions. Ses étapes ont été représentées par un membre de la communauté Zope dans
le schéma suivant:
33
Cette citation et la suivante sont tirées de http://dev.zope.org/DevHome/Projects/Fishbowl/Introduction.html .
Notons que lorsque le code source de Netscape a été ouvert et repris par la communauté open source sous le
projet Mozilla, celui-ci a eu des débuts difficiles. Parmi les raisons citées, un problème de culture de
développement. En effet, les développeurs de Netscape ne communiquaient pas uniquement dans le «
fishbowl ».
16
Fishbowl proposal state machine 34
Lors de l’étape de « Construction », une proposition doit inclure une description :
- du problème à résoudre
- de la solution proposée
- des risques encourus
- de l’étendue du projet
- des délivrable s envisagés.
Ensuite, l’initiateur du nouveau projet doit soumettre sa proposition à une double évaluation :
- un « editorial review » vérifie que le processus a bien été suivi lors de la formulation de la
proposition
- un « technical review » vérifie que la proposition est – d’un point de vue technique effectivement réalisable et cohérente avec la plateforme Zope.
Si la proposition est acceptée, le projet peut passer à la phase suivante (phase d’élaboration).
Dans le cas contraire, l’initiateur doit reprendre la « construction » de sa proposition.
Plusieurs états sont encore définis pour classer les propositions inactives :
- l’état « Defered » est celui d’une proposition qui a passé plus d’un mois dans le stade de
« Construction ». Après trois mois, il est éliminé de la liste des propositions.
- l’état «Awaiting resources » est celui d’une proposition acceptée mais que personne ne
développe actuellement (après trois mois, elle est considérée comme « Orphaned »).
34
tiré de http://dev.zope.org/Wikis/DevSite/Proposals/ProposalStates
17
Quel succès rencontre cette initiative ? En étudiant la page du site consacrée aux
propositions 35 , on constate qu’il est possible de ne pas respecter les stades décrits dans le
Fishbowl Process. En effet, l’édition de la page en question est autorisée pour n’importe quel
utilisateur enregistré sur le site Zope (de manière anonyme ou non), et cette édition ne se fait
pas dans un canevas prédéfinis 36 . Ainsi, sur la centaine de propositions listées sur la page, un
tiers de celles-ci ne correspondent à aucun état du Fishbowl Process (par exemple 16
propositions sont seulement marquées « New », certaines depuis plus de deux ans). Parmi, les
deux autres tiers qui portent effectivement un label appartenant au Fishbowl Process, on
constate la répartition suivante:
Etat
Nombre de propositions
Construction
18
Editorial review
15
Technical review
26
AwaitingResourcesState
14
(chiffres relevés début octobre 2003)
On constate qu’une majorité de propositions sont en cours de révision. D’où vient ce goulot
d’étranglement ? D’un manque d’intérêt de la part des réviseurs ? Les propositions ont-elles
été abandonnées ? On note en effet que certaines propositions attendent une révision depuis
plus de deux ans… Pourquoi ne sont-elles pas alors qualifiées de « Awaiting resources », ou
« Defered »?
Comme pour le projet de documentation, on voit qu’il est a priori difficile d’imposer à une
communauté open source l’explicitation et l’organisation des connaissances selon un certain
formalisme préétabli. Un des membres de la communauté Zope remarque ainsi:
"There are a lot of dead fish floating in the fishbowl"37
Toutefois, il ne faut pas s’arrêter à l’apparent échec des deux initiatives présentées jusqu’ici.
En effet, en parcourant le site Zope.org on remarque que :
- le développement de produits Zope est un véritable succès: des centaines de produits
ajoutant des fonctio nnalités à Zope sont disponibles.
- La documentation de Zope existe bel et bien : sous forme de manuels, de howtos, etc.
Nous avons constaté également qu’elle était à jour et de qualité.
Comment la documentation et les produits Zope ont-il pu se développer avec succès malgré
les difficultés d’organisation rencontrées ? Pour le comprendre, il semble que nous devions
nous intéresser de plus près à deux concepts mis en œuvre: le « wiki » et le «système de
gestion de contenu ».
Une capitalisation souple des connaissances grâce au wiki et au
système de gestion de contenu
Qu’est-ce qu’un « wiki » ? Il s’agit d’un concept pour la réalisation commune de documents
qui consiste à donner le droit à tout lecteur de modifier la page qu’il est en train de lire. Par
35
http://dev.zope.org/Wikis/DevSite/Proposals/FrontPage
L’édition de la page est rendu possible par le fa it qu’il s’agit d’un wiki. Nous en décrivons les principes plus
loin.
36
37
http://dev.zope.org/Wikis/DevSite/Proposals/ProposalStates
18
extension, on qualifie de wiki l’outil qui met en œuvre ce concept sur un site internet. Celuici possède souvent des fonctionnalités telles que :
- l’utilisation d’un code facilitant la mise en forme du contenu d’une page
- la création en partie automatisée de liens hypertextes entre les pages 38
- La possibilité de voir l’historique des modifications d’une page
On retrouve comme caractéristique principale des wikis le principe d’ouverture au fondement
de l’open source: les pages peuvent être éditées par l’interna ute, non seulement pour ajouter
des commentaires mais aussi pour modifier un texte préexistant afin de l’améliorer. Ainsi, au
lieu d’avoir un cumul de connaissances individuelles dont les plus anciennes sont obsolètes,
on a toujours un seul document mis à jour en commun 39 . Le wiki a d’ailleurs déjà montré son
utilité dans le domaine de la capitalisation des connaissances explicites, puisqu’une
encyclopédie basée sur l’utilisation de cet outil (http://www.wikipedia.org/) a regroupé en
moins de trois ans 160'000 articles en version anglaises (17'000 pour la version française).
Le concept de wiki est mis en œuvre sur une grande partie du site Zope.org de manière
combinée avec son système de gestion de contenu (CMS). Cela en fait un outil collaboratif
puissant, qui permet de donner différents droits à un utilisateur (celui-ci doit seulement
enregistrer un nom d’utilisateur et un mot de passe):
- le droit de modifier le texte d’autrui (voir figure 1) ou d’ajouter seulement des
commentaires
- le droit de créer du contenu dans son répertoire personnel
- le droit de publier directement ce contenu ou seulement de le soumettre à révision40
De nombreuses fonctionnalités sont également disponibles, outre celles propres au wiki déjà
citées ci-dessus, comme par exemple la possibilité de « défaire » une modification, d’afficher
ou non les commentaires des internautes (bouton on/off), etc.. Notons enfin qu’un projet en
cours a pour objectif de permettre l’envoi de mails pour signaler d’éventuels changements aux
personnes intéressées à la mise à jour d’une page particulière 41 .
38
Si deux mots sont accolés, avec une majuscule à chacun d’eux, le système crée automatiquement un lien vers
une page du même nom, en reprenant l’adresse relative de la page actuelle . Par exemple, si dans une page
http://www.serveur.com/wiki/FrontPage on écrit « NouvellePage », ces mots s’afficheront en tant que lien vers
http://www.serveur.com/wiki/NouvellePage. Si la page n’existe pas, un point d’interrogation apparaît à côté du
nom : en le cliquant on peut créer la page en question.
39
Comment prévenir des usages malveillants ? Les wikis reposent sur la bonne volonté de la plus grande partie
des utilisateurs, et sur le fait qu’il ne sert à rien de détruire une page, car celle -ci peut être facilement remise en
place grâce à l’archivage des anciennes versions d’une page.
40
Par exemple, n’importe quel internaute inscrit sur le site de Zope pourra créer une page de type « howto » pour
partager ses connaissances, mais celui-ci devra être validé (révisé et publié) avant d’apparaître dans la liste des
howto’s.
41
http://dev.zope.org/DevHome/Projects/Wikis/DevSite/Projects/FishbowlNotificationsForNo
w/FrontPage
19
Figure 1 : Exemple d’une page du site Zope de type wiki en mode normal (à gauche) et en
mode édition (à droite)
Ce système wiki-CMS est sans doute un élément clé dans l’émergence d’une documentation
de qualité et d’une explicitation des connaissances sur le site Zope.org. On trouve par
exemple :
- le « Zope Book », véritable bible de l’utilisateur de Zope, est régulièrement mis à jour. Il
est intéressant de noter que la cvs et le « bug tracker » de SourceForge, des outils prévus
pour le développement de logiciel, sont aussi utilisés pour la rédaction du « Zope Book »,
le suivi des modifications et le report de « bugs » - en l’occurrence des problèmes de sens
ou des fautes de syntaxes.
- les howtos : 200 « recettes » créées en partie par des internautes dans leur « répertoire
personnel » sur Zope.org sont regroupées automatiquement une fois validées par des
responsables du site et ainsi facilement accessibles.
- Les informations relatives aux projets en cours et les délivrables demandés dans le
Fishbowl Process se font également dans des pages de type wiki.
Les wikis peuvent donc être considérés comme la face souple du développement de Zope
(formalisé dans le « Fishbowl Process») et du Zope Documentation Project. Nous faisons
l’hypothèse qu’ils jouent un rôle important dans leur réussite : ils permettent en effet d’isoler
et d’organiser des connaissances explicites sans imposer de canevas précis et en facilitant la
participation de tous.
Le site Zope.org offre encore d’autres outils facilitant la gestion des connaissances au sein de
la communauté Zope. Nous allons en voir trois : le « bug collector », les listes de distribution
et le canal irc.
20
Le Bug Collector : succès du formalisme
Le Bug Collector concerne principalement le report de bugs rencontrés avec le logiciel et la
mise à disposition de patches pour résoudre ces problèmes. Pourquoi avoir isolé ce type
particulier de communications ? Ce n’est pas une originalité du projet Zope, un système
analogue souvent utilisé étant « Bugzilla », développé dans le cadre du projet Mozilla mais
utilisé dans d’autres projets open source. Le succès de ce genre d’outils complémentaires aux
mailing- lists s’explique sans doute par le fait :
- qu’il est possible de résumer les informations liées à un bug particulier sans perdre de
connaissances essentielles.
- qu’il est nécessaire d’être clair et précis pour parvenir à cerner l’origine d’un bug
Ainsi, un effort d’explicitation et de filtrage des informations est demandé à l’utilisateur du
Bug Collector :
« For those of you submitting collector issues, you're helping all Zope users - thank you.
When formulating your issue, please keep in mind the challenge facing the supporters. The
more you can do to include essential details and leave out irrelevant ones, the better the
supporter's chances for detecting the problem or understanding the desired feature.”
Et le report de bug se fait dans un canevas précis:
Par contre, on remarque que le système normalement prévu également pour la demande de
nouvelles fonctionnalités ou “features” est peu utilisé dans ce sens – peut-être parce que
celles-ci se discutent mieux dans des canaux de communication moins formels ?
21
L’échange informel sur le canal irc
Contrairement aux canevas imposés par le Bug Collector, le canal de discussion, basé sur le
protocole « Internet Relay Chat » (IRC), est un outil laissant la communication totalement
libre.
Il existe plusieurs canaux de discussion consacrés à Zope sur irc.zope.org (ou
irc.freenode.org). Dans le canal principal nommé simplement « zope », entre 50 et 100
personnes sont connectées simultanément, la plupart du temps silencieuses. Parmi celles-ci on
trouve apparemment tous les types d’utilisateurs, des principaux développeurs jusqu’aux
nouveaux venus ou « newbies ». Le fait que les personnes soient connectées en permanence
rend possible des réactions rapides et des conversations en temps réel ont lieu. Selon nos
observations et un développeur interrogé directement par ce biais, les discussions dans le
canal irc sont principalement de deux types :
- des conversations assez libres entre habitués qui développent sous Zope, par exemple pour
se coordonner dans certaines tâches en cours (voir figure 2), exprimer des opinions, etc.
- de l’aide aux débutants : la communication presque synchrone permet de guider
l’utilisateur pas à pas, celui-ci pouvant directement essayer les solutions proposées,
rapporter les messages d’erreurs, etc. 42
Notons aussi une utilisation du canal irc lors des « Bugdays », ces journées consacrées à la
résolution « intensive » de bugs relevés dans le Bug Collector. L’irc permet alors une
coordination rapide et précise entre les participants.
Figure 2 : un exemple d’échange informel dans le canal irc (octobre 03)
Comme le canal irc est en dehors du « Fishbowl » (puisque ce qui est échangé n’est pas
archivé et n’est donc pas accessible par l’ensemble de la communauté), ce n’est pas un lieu de
décision : celles-ci sont prises dans les mailing- lists.
L’échange des connaissances « stocké » dans les mailing-lists
Les mailing- lists sont le lieu privilégié de la communauté Zope. Il en existe une vingtaine
hébergées sur Zope.org. On peut les classer en quatre grandes catégories:
- les listes générales consacrées à l’utilisation et au développement de Zope
- les listes qui touchent à un domaine particulier de Zope ou à un produit particulier (p.ex. :
les ZPT, les liens aux bases de données relationnelles, l’internationalisation de zope, etc.)
42
A ce sujet, Il est intéressant de constater qu’un message permanent signale l’existence d’un wiki nommé «
Unofficial channel FAQ », mis en place par un habitué de canal irc pour y réduire la redondance des questions de
base. La FAQ donne aussi quelques principes pour poser les bonnes questions au bon endroit et dirige les
utilisateurs sur la documentation existante.
22
-
les listes qui concernent une communauté linguistique particulière (italienne, allemande,
russe)
les listes qui concernent des cas d’utilisation particuliers (Zcommerce)
Les communications dans les listes de diffusion accompagnent toutes les activités liées au
développement du projet Zope. Chaque jour, des centaines de messages s’échangent sur les
sujets les plus variés. Afin de ne pas nous perdre dans cette diversité, nous avons choisi
d’étudier trois des principales listes consacrées à zope :
- Zope-User qui s’adresse aux utilisateurs de Zope en général, y compris les débutants.
- Zope-Dev qui concernent les développeurs de Zope au sens large et les personnes
intéressées à son évolution
- Zope-Coders : une liste en principe réservée aux développeurs ayant des droits d’écriture
sur le code source central.
Nous avons étudié ces trois listes sur le mois de juillet 2003 43 en regroupant les mails par
« threads » (un thread est un ensemble de mails ayant un sujet commun – par exemple une
question et ses réponses) et par auteurs (toute personne ayant écrit un mail au moins durant le
mois). Nous commentons ici les principaux résultats44 .
Zope-user
Cette liste est le lieu d’échange de connaissances à propos de l’installation, la configuration et
l’utilisation de Zope (programmation de base). Sur plus de 300 personnes ayant écrit un
message en juillet, on constate la répartition suivante:
- en moyenne, chaque auteur a envoyé 4,4 mails
- un peu moins de la moitié des auteurs n’ont envoyé qu’un seul mail.
- une minorité (24 auteurs) ont envoyé plus de 10 mails.
Un grand nombre de personnes participent donc activement à la mailing- list, que ce soit pour
une utilisation ponctuelle ou régulière
Toujours sur le mois de juillet, la liste a reçu une quarantaine de mail par jour. Les messages
sont regroupés en plus de 500 threads, qui contienne en moyenne 2.4 messages, avec un
maximum de 17 messages pour un seul thread.
Nous avons porté une attention particulière aux messages isolés (les threads orphelins), car ils
pourraient mettre en évidence une faille des mailing- lists : étant donné la quantité de
messages qui s’échange nt, certains peuvent passer inaperçus. Dans la liste des utilisateurs de
Zope, environ 40% des threads n’ont qu’un seul message. Cela peut paraître important, mais il
faut tenir compte de plusieurs facteurs :
- certains mails ne reçoivent pas de réponse parce qu’il s’agit de messages système (un mail
n’a pas pu être délivré, un virus a été envoyé à la liste..).
- un nombre important de messages en rapport l'un avec l'autre ne sont pas organisés en
thread 45 . La création automatique de thread a donc ses limites et ce défaut peut rendre plus
difficile une recherche ultérieure.
43
Le nombre de messages échangés sur le mois de juillet est proche de la moyenne des douze mois précédents.
Les données détaillées sont résumées dans un tableau en annexes
45
si le sujet du message a été modifié par un des correspondant, le système ne parvient plus à le classer
correctement (par exemple lors de l’ajout du mot « solved » au début ou à la fin du sujet pour montrer qu’une
solution a été trouvée).
44
23
-
Enfin, même si la pratique est en principe déconseillée en open source, il faut tenir compte
du fait que certaines réponses n’ont peut-être pas été faites à la liste mais directement à
l’adresse privée du participant 46 .
Contrairement à ce que laissait penser notre étude quantitative, il n’y a donc finalement
qu’une petite minorité de questions qui ne trouvent pas de réponse. De plus, on constate que
la plupart des réponses sont envoyées le jour même ou dans les jours qui suivent une question.
Intéressons-nous maintenant aux autres threads. La grande majorité de ceux-ci commencent
par une question ou un problème précis. On peut distinguer deux grandes catégories.
- question sur un problème technique très spécifique, avec éventuellement la présence de
lignes de code ou d’un message d’erreur.
- question plus large sur les choix à faire face à une situation afin d’atteindre un certain
objectif.
Les réponses sont très variées, on observe la présence:
- de références (à un site web, à un autre thread, à un livre, à un terme à rechercher sur
internet)
- de connaissances explicitées en relation ou non avec une expérience personnelle racontée
- d’arguments pour justifier tel ou tel choix (d’après la situation du demandeur ou l’histoire
du projet)
- le cas échéant, d’une interprétation du message d’erreur fourni, ou d’explications à propos
de lignes de codes présentées
Le thread peut alors continuer par une demande supplémentaire, une description de la solution
finalement adoptée (envoyée parfois à la liste par le demandeur lui- même afin que sa solution
soit utile aux personnes qui rencontrent le même problème), un feed-back positif (souvent
sous la forme d’un remerciement) ou au contraire un constat d’échec, etc. Ce dernier mail
peut être précieux pour la suite, puisqu’il indique si la solution proposée à permis la résolution
du problème. Malheureusement il n’est pas systématique et souvent le doute persiste quant à
la réussite ou non d’une solution proposée.
Zope-Dev
Cette liste est mise en place pour les utilisateurs directement impliqués dans le développement
de Zope. On constate que la nature des communications est sensibleme nt différentes de celles
de la liste zope-user : l’asymétrie entre celui qui pose une question et celui qui connaît la
réponse est moins prononcée ici : les threads sont plus proches de conversations entre experts
qui se coordonnent, argumentent ou commentent différentes possibilités pour contourner un
problème que le développement rencontre en général. Cela explique peut-être en partie le fait
que les threads soient en moyenne légèrement plus long que dans la première liste.
Au-delà de la simple volonté de contourner une difficulté présente, le souci de cohérence par
rapport à la direction générale du développement et l’intérêt pour une solution “simple” et
“belle” semble prendre de l’importance. Par exemple, dans le plus long thread, le premier
message présent e une solution utilisée qui semble “Kinda yucky“ c’est-à-dire “un peu
dégoûtant” à son auteur. Ce dernier propose une amélioration du langage lui- même pour
46
“ It's the respondent's choice whether to reply privately — and if he does, it's usually because he thinks the
question is too ill-formed or obvious to be interesting to others.” (E.S.Raymond
http://www.catb.org/~esr/faqs/smart-questions.html#noprivate)
24
permettre une meilleure solution et demande des commentaires. La discussion qui s’en suit
implique le rappel de certains principes guidant le développement de ce langage et pas
seulement des réflexions sur la manière de résoudre le problème en question.
Cette liste, nettement moins active (cinq fois moins de messages que dans la liste zope-user)
permet aux développeurs d’échanger des opinions sans être submergés par les demandes
d’aide des utilisateurs. On note toutefois toujours la même proportion de threads orphelins,
dont la plupart sont du « bruit » (messages systèmes) ou des messages mal classés par le
système (réponses à un autre message)
Zope-Coders
La liste consacrée à l’accès au code via le CVS est utilisée par les développeurs qui possèdent
des droits en écriture sur le code source central. Ils s’en servent principalement pour se
coordonner, discuter de détails techniques du CVS, de batteries de test, etc. Le nombre de
personnes inscrites est ainsi beaucoup moins important (seulement 80 inscrits contre 1000 à
zope-dev et 3000 à zope-user). On constate par contre une plus grande activité des membres
inscrits (puisque 40% sont actifs dans le mois contre 6-10% dans les deux autres listes). De
plus, la plupart des inscrits reçoivent les messages un à un47 , ce qui permet une réaction plus
rapide. Enfin, la plupart des threads orphelin sont des message s qui ne demandent pas de
réponses.
Synthèse : le succès de deux principes simples : séparation des listes et
archivage
La séparation des listes semble avoir l’effet recherché : le nombre de personnes varie
fortement et les conversations sont de nature différente selon la liste utilisée.
Il faut noter aussi qu’un très grand nombre de participants reçoivent les mails sans participer
activement sur une période d’un mois – mais leur présence silencieuse n’interfère pas dans la
communication – celle-ci peut donc rester ouverte même lorsque la communauté est grande.
Les listes de distribution sont donc un moyen efficace pour partage des connaissances dans
des relations interpersonnelles. Mais grâce au simple stockage automatique de ces messages et
à la possibilité d’y accéder en les triant par date, par sujet, par thread et par une recherche par
mot-clé, une forme de capitalisation de connaissances (certes peu explicitées) joue également
un rôle important (voir figure 3). En effet, bien que l’effort de capitalisation soit pour ainsi
dire nul, les archives ont deux intérêts majeurs:
- elles permettent à un nouveau venu de se familiariser avec l’histoire du projet, l’origine de
ses choix, les difficultés fréquentes, le style de communication, en un mot la culture du
projet. Ce qui leur permet sans doute de s’intégrer et de contribuer plus rapidement.
- une personne confrontée à un problème peut retrouver (par une recherche par mot-clé) une
solution à son problème et l’appliquer à son propre cas 48
47
Les listes de disttibution proposent un autre mode qualifié de « digeste », qui consiste à n’envoyer qu’un mail
contenant tous les messages du jour.
48
Cette démarche peut être comparée à la technique du Case Base Reasoning.
25
Il est difficile de mesurer cette dimension silencieuse de l’échange des connaissances.
K.Lakhani et al.(2002) ont interrogé des participants au projet open source Apache et sont
parvenus à la conclusion suivante: « 98% on average, of the time spent at the help website by
an information provider is devoted to reading posted questions, and only 2% to provinding
answers »49 . Pourquoi passer autant de temps à lire les messages? Simplement dans le but
d’apprendre les problèmes rencontrés par les autres utilisateurs, afin de mieux maîtriser le
logiciel.
Figure 3 : la double utilité des listes de distribution: à gauche, les messages reçu
quotidiennement, à droite les messages stockés dans les archives sous forme de threads
(extraits de la liste zope-user, 21.10.03)
2.4 La gestion des connaissances dans le projet Celestia
Les forums : centre de la communauté Celestia
En visitant le site principal du projet Celestia www.shatters.net/celestia, on s’aperçoit
rapidement que l’organisation du projet est plus rudimentaire que celle de Zope. Comme
l’explique Chris Laurel, l’échange entre les développeurs se fait de manière informelle :
“There's not a lot of process in place for Celestia development. The number of active
developers is small enough that we've been able to get by without a lot of protocol, and basic
rules of politeness have sufficed.“50
Pour découvrir l’existence de la communauté réunie autour de Celestia, il faut s’intéresser au
contenu des forums. Ceux-ci reposent sur le logiciel open source « phpBB »
(http://www.phpbb.com/) dont nous verrons certaines fonctionnalité utile pour la gestion des
49
Si seulement 2% du temps est consacré à répondre, c’est que les réponses sont données seulement si elles sont
déjà connues et qu’elles n’impliquent donc pas des recherches.
50 Cette citation de Chris Laurel et les suivantes sont tirées des réponses à des questions envoyées par email. On
trouvera le questionnaire complet en annexe.
26
connaissances. La page d’accueil des forums donne quelques indications de leur succès :
23'000 messages ont été postés par des centaines d’internautes51 . On a donc en moyenne
depuis le début de ce forum (le premier message est daté du 30 janvier 2002) une quarantaine
de nouveaux messages chaque jour. C’est un trafic équivalent à la liste de distribution
principale de Zope (zope-user). A noter que sur les 1’000 utilisateurs enregistrés, seulement la
moitié ont effectivement posté des messages dans les forums, et 150 ont postés 10 messages
ou plus 52 . Notons aussi qu’il n’est pas nécessaire d’être enregistré pour poster des messages.
Figure 4 : la page d’accueil des forums de Celestia (29.10.03)
Contrairement à Zope, Celestia n’a pas de communautés satellites. La grande majorité des
communications sont échangées dans ces forums, qu’il s’agisse de l’utilisation ou du
développement du logiciel, de questions d’astronomie, de report de bugs ou encore de la
gestion du projet lui- même. C’est donc dans ceux-ci qu’on apprend les principes de
fonctionnement de la communauté et notamment les règles plus ou moins explicites pour
gérer les connaissances. Nous les avons regroupées en deux thèmes :
51
Chiffres relevés en septembre 2003 et ne concernant que le forum mis en place à partir de janvier 2002
(l’ancien forum, apparemment remplacé pour des raisons pratiques, n’est plus accessible)
52
Ces chiffres ont été arrondis pour faciliter leur lisibilité
27
Réalisation de la documentation et organisation des ressources
-
-
-
-
la documentation utilisateur est réalisée par les utilisateurs : cette règle a été
récemment explicitée dans une « FAQ » (postée dans le forum principal) : “The
authors of Celestia spend their time improving the software. Documentation is
provided by users »53 . (cette règle est explicitée par un non développeur). On constate
en effet que le guide de l’utilisateur a été réalisé par un enseignant qui utilise Celestia
dans ses cours et partage avec la communauté des leçons d’astronomie réalisées avec
Celestia.
la documentation du code source est réalisée par les nouveaux développeurs : en effet,
non seulement le manuel de l’utilisateur est laissé au soin de membres périphériques,
mais encore la documentation du code source lui- même, comme l’exprime ce
contributeur (un non développeur) : « I personally would rather have Chris (in
particular) working on implementation instead of documentation. [...] I think it might
be more efficient if some prospective new developer were to write up the
documentation as a way to learn the code, and then let the experienced developers
review it. Just my opinion. - Hank »54
la documentation pour le développement de modules est rythmée par les «release »
officielles : en effet, mise à part la question des « bugs », il existe une différence entre
des versions stables et bêta (nommées pre.x.) comme l’explique un des participants de
Celestia: « When a new official version is released, the official website is updated,
some examples and data for the new features are included in the distribution package,
some help for the development of new add-on is written etc. So development is
partially stopped and a new check of the situation is done.”55 Du point de vue de la
gestion des connaissances, la sortie d’une nouvelle version officielle permet donc une
mise à jour des connaissances capitalisées.
l’organisation et la mise à disposition des ressources, documents, etc. est faite en
grande partie par des participants périphériques, l’internaute ne trouvera pas sur la
page d’accueil l’ensemble des liens utiles et doit s’intéresser à des sites satellites. Les
« Celestia Coding Standards », c’est-à-dire les règles pour respecter le style de
programmation de Celestia sont ainsi mises en évidence sur le site d’un membre du
projet, non sur le site principal56 .
Pour faciliter l’échange des connaissances et lutter contre le « bruit »
-
-
enregistrement des utilisateurs : l’internaute peut s’enregistrer sur le forum si il veut
être reconnu par les autres – implicitement, c’est donc un moyen de jouer sur le
paramètre de « confiance »
séparation simple en divers forum selon certains thèmes : comme pour les listes de
distribution de Zope, cela permet d’isoler certains types de conversations. Notons que
trois nouveaux forums ont été créés au cours des derniers mois, et notamment un
forum « purgatoire » pour stocker les threads qui sont hors sujet. Un moyen pour
limiter le bruit suggéré par un utilisateur anonyme 57
53
http://www.shatters.net/forum/viewtopic.php?t=2291
http://www.shatters.net/forum/viewtopic.php?t=3174&start=15
55
Extrait de http://www.shatters.net/forum/viewtopic.php?t=3151
56
Voir par exemple http://www.lepp.cornell.edu/~seb/celestia/#1.0
57
“To Chris. I think that when the forums enlarges in terms of number of visitors a more strict control over the
forum themeselves is required. So because Y know that you have better things to do, please give the moderator
or administrator rights on the forums on Shatters.net to other contributor of celestia developing team, to garrison,
54
28
-
-
mise en place d’une FAQ visant à limiter la redondance des questions de base. Celle-ci
a été créée par « selden », un participant très actif dans le forum mais qui ne fait pas
partie des développeurs de Celestia.
mise a profit d’une fonctionnalité du forum: l’usage de «Sticky Posts » permet de
conserver des messages en haut de la page sans tenir compte du tri par date.
utilisation d’une liste hors du forum pour l’échange entre développeurs: la mailing- list
« developers » ne reçoit qu’un ou deux messages pour des questions techniques. C’est
peut-être une manière de se préserver du « bruit » qui rend cette discussion plus
difficile dans le forum très fréquenté. Selon Chris Laurel : “The discussion in the
mailing list is typically more technical than the forum discussion, and we tend to
spend a lot more time talking about implementation details there. Often times a new
feature idea will be suggested in the development forum, then discusson of how to
actually code it will occur on the mailing list”.
2.5 Synthèse des résultats et commentaires
Au moment de commenter les résultats de notre étude, un premier constat s’impose: c’est la
difficulté de maintenir en open source la distinction entre les deux dimensions de la gestion
des connaissances. En effet:
- toute communication est stockée et accessible ultérieurement sous forme de document (à
l’exception du canal irc)
- les connaissances capitalisées - même sous forme de manuels - facilitent la
communication entre personnes, par le fait que cette documentation est réalisée
conjointement, ou parce qu’elle autorise l’insertion de commentaires par l’internaute
anonyme (par exemple grâce au wiki) 58 .
L’échange interpersonnel est donc toujours possible, au même titre que l’accès direct aux
documents. L’open source semble ainsi garder le meilleur des deux grandes stratégies pour
gérer la connaissance. Mais comment les projets étudiés font- ils face aux difficultés
mentionnées dans l’introduction ? Rappelons que la capitalisation des connaissances
explicites d’une part, et la possibilité de communiquer des connaissances tacites d’autre part
semblaient compromises a priori par les principes de l’open source. Nous reprenons ici les
difficultés évoquées sous la forme synthétique de ces deux questions :
- l’échange de connaissances tacites peut- il se baser uniquement sur des outils
technologiques ?
- l’accessibilité des connaissances est-elle rendue difficile par la multiplicité des
communications non formalisées et le « bruit » générés par la communauté ?
Pour répondre à la première question notons tout d’abord que le plus souvent les
communications étudiées accompagnent une pratique (programmation, installation,
configuration ou utilisation du logiciel) qui donne finalement un contexte commun aux
participants et facilite la compréhension réciproque. Ensuite, nous avons constaté au cours de
notre étude que la plupart des discussions ont lieu de manière tout à fait informelle : aucune
structure n’est imposée. L’intérêt de privilégier la diversité sur le formalisme devient évident
lorsque l’on constate la richesse des échanges. Même si cette dimension dépasse le champ de
censor, lock or move the threads that goes out of control like this. [..] Best regards.Guest“
http://www.shatters.net/forum/viewtopic.php?t=2734&postdays=0&postorder=asc&start=15
58
L’évolution rapide des connaissances dans le domaine informatique explique sans doute en partie le choix de
cette approche.
29
notre étude, notons à titre d’hypothèse l’observation suivante: bien que la communication
perde une dimension personnelle (on ne sait pas toujours à qui on s’adresse), relationnelle (les
échanges sont souvent asynchrones) et comportementale (pas de langage non verbal), la
richesse des interactions humaines demeure. Même si l’on ne peut nier l’existence de
difficultés liées à la perte de ces dimensions, (d’autant plus lorsque des différences
socioculturelles ou linguistiques entrent en jeux), l’anglais peut jouer le rôle d’ultime
métalangage, permettant toujours de s’élever au-dessus d’une communication pour
communiquer à son sujet, pour préciser le sens d’une phrase, pour clarifier un point de vue,
etc.
Faut- il en conclure que la technologie suffit à gérer l’échange des connaissances? Ce serait
oublier le principe d’ouverture sur lequel se fonde l’open source et la culture du partage qui
l’accompagne 59 . Encore faut- il pouvoir canaliser cette volonté de communiquer. Et nous
revenons à notre seconde question : comment les projets open source étudiés parviennent- ils à
introduire un certain formalisme dans ces échanges pour permettre la capitalisation de
connaissances? Il est intéressant de constater que les deux projets étudiés sont à ce point de
vue dans deux phases différentes:
- dans Celestia, on constate une mise en place progressive de fonctionnalités et de
procédures de base pour exclure les messages hors sujet, les questions redondantes (par
une mise en évidence des réponses aux questions fréquentes, la création d’une première
documentation utilisateur, etc.), ainsi qu’un nombre croissant de forums séparant les
discussions selon des thèmes bien définis. Seule une liste de diffusion consacrée aux
questions techniques du développement a été mise à profit comme canal isolé de
communication.
- dans Zope, qui possède une communauté et une activité beaucoup plus importante, on
constate la mise en place d’outils différenciés selon le type de communications : du canal
irc au Bug Collector, l’échange se fait dans un medium dont le formalisme est plus ou
moins important. D’autre part des tentatives pour formaliser les connaissances existent, et
si elles ne sont pas toujours respectées à la lettre, on observe tout de même la réalisation
d’une documentation de qualité et le succès du développement des produits (le rôle joué
par les outils collaboratifs sophistiqués a déjà été souligné).
Grâce à la culture de l’open source, le KM semble donc se réduire à la mise en place
progressive d’outils et de fonctionnalités adéquats pour canaliser les communications d’une
communauté grandissante. Les procédures semblent ainsi garanties par les outils utilisés.
Comme l’explique G.F.Lanzara et al. (2003, p.7) : “Most of the organizational gear is
invisible in open-source software projects, being draped in the technical gear. In open-source
software projects a large quota of 'organization' and organizing is embodied in the technology.
Therefore, if one wants to search for organization, he/she’d better look inside the technology.”
L’existence de plateformes telle que SourceForge permettent aux intiateurs de projets open
source de mettre facilement et gratuitement en place certains de ces outils qui ont fait leur
preuve (cvs, forum, mailing- list, etc.).
59
Il faut signaler ici que l’importance du projet Zope lui a permis de s’étendre au-delà d’internet : l’organisation
de conférences et de groupes de rencontre, a rendu possible un certain partage de connaissances « en personne ».
P.ex. des rencontres sont organisées en Allemagne,
http://www.dzug.org/Members/jok/DZUGStuttgart_20031021, à Washington http://www.zpug.org/ , au
Minnesota http://www.zope.org/Members/tczpug/ , en Suisse http://zope.ch/index_html/News_Item.2003-0924.1155 etc.
30
3 Conclusion :
Les succès du KM en open source peut-il être étendu à d’autres
domaines ?
D’après notre étude, on peut considérer que le succès du Knowledge Management des projets
open source repose finalement sur deux principaux aspects :
- le principe d’ouverture - non seulement du code source ma is de toutes les communications
auxquelles tout le monde peut accéder et participer (notion de « Fishbowl » dans Zope)
- l’utilisation d’outils informatiques collaboratifs sur internet.
Cette manière de gérer la connaissance en open source peut-elle être étendue à d’autres
domaines ? Avant tout, il faut préciser une spécificité liée au domaine du développement de
logiciels : l’existence d’un code source auto documenté. Il semble d’ailleurs qu’il y ait dans
les deux projets une volonté de rendre ce code et son design le plus lisible possible : il existe
par exemple des standards pour écrire le code source de Celestia. D’autre part, un participant
exprime l’idée suivante dans le canal irc consacré à Zope : « I try to share what I learn […]
through source code ». Pour cela, des techniques d’évaluation de la complexité du code et des
principes pour le réécrire en simplifiant son design 60 sont connus des développeurs. On est
proche ici d’une idée de l’Extreme Programming (XP): si un code source a besoin de
beaucoup de documentation, c’est qu’il est trop complexe. Plutôt que de produire cette
documentation, il vaut donc mieux simplifier le code. De cette manière, le départ d’un
développeur 61 ne représentera pas une grande perte d’un point de vue de la gestion des
connaissances, le code source qu’il a développé représentant une connaissance explicitée à
l’extrême.
Ceci étant posé, l’échange des connaissances dans les projets open source ne concernent pas
seulement le code source, ce qui semble indiquer la possibilité de transposer effectivement les
principes de l’open source à d’autres domaines. On peut citer par exemple ces deux tentatives
du Massachusetts Institute of Technology (MIT) :
- le site http://opensource.mit.edu propose de reprendre l’esprit de l’open source pour
créer une communauté consacrée à l’étude de ce phénomène 62 . Nous avons pu la tester
dans le cadre de cette étude, en utilisant les articles mis à disposition et en participant
notamment à la liste de diffusion. Celle-ci est toutefois assez peu utilisée.
- le programme appelé « MIT Open Courseware »63 lancé en septembre 2002 consiste à
mettre à disposition sur internet le matériel de plus de 500 cours (exercices, notes de
cours, lectures, examens blancs, etc.). Celui-ci est accessible librement (il n’est même
pas nécessaire de s’enregistrer) afin que les facultés des autres universités et les
autodidactes puissent s’en inspirer ou les utiliser. Le matériel est placé sous différents
types de licence dont une reprend le principe du “copyleft” des licences open source :
60
Voir par exemple les principes défendus par Martin Fowler www.refactoring.com
En ce qui concerne Celestia, il faut noter à ce sujet que l’équipe de développeur est très stable. Comme
l’explique Chris Laurel: « Early in the life of Celestia, one developer left due to an apparent personality conflict.
[..] Other than that, no developers have left permanently. » (questionnaire en annexe).
62
Comme la page principale le précise: “In the spirit of free and open source software (F/OSS), we are
attempting to establish a community in which information will be freely exchanged, so that we may further the
understanding of open source and its implications outside the realm of software development. »
63
http://ocw.mit.edu/index.html
61
31
“The licensor permits others to distribute original or derivative works, but only under
a license identical to the one that governs the licensor's work.”64
La théorie du KM permet-elle de comprendre ce succès ?
Au-delà de ces deux initiatives, on constate d’une manière plus générale l’existence de
certaines approches du Knowledge Management compatibles avec la pratique de l’open
source. C’est le cas par exemple de la « distributed approach to Knowledge Management
(DKM) » présentée par M.Bonifacio et A.Molani65 . Selon cette perspective, il faut cesser de
considérer la connaissance comme une information explicitée, codifiée, pouvant être
transmise à une personne sous la forme d’un document. . La standardisation n’est dès lors plus
un but en soi. La connaissance doit être considérée sous l’angle de la diversité, et cette
diversité devient la base d’un programme de ge stion des connaissances : « DKM assumes a
perspective that views knowledge as a distributed matter that should be organized
accordingly : heterogeneity is an opportunity instead of a limit ». C’est bien ce que nous
avons constaté tout au long de notre étude : les moyens principaux de communication de Zope
et Celestia sont respectivement des listes de distribution et des forums dans lesquels des
milliers de messages s’échangent sans respecter aucun formalisme fixé a priori.
La notion de « community of practice » (CoP) a également été introduite par Etienne Wenger
pour exprimer l’idée selon laquelle la connaissance se partage au mieux dans des milieux
informels et liés à une pratique sociale. Pour cet auteur, gérer la connaissance revient à donner
à cette manière spontanée de partager la connaissance une place centrale. En parlant de ces
CoP, il écrit ainsi : “Organizations are already full of them. So what is new here? Why even
pay attention? Well, what is new is the need for organizations to become more intentional and
systematic about "managing" knowledge, and therefore the need to give these age-old
structures a new, central role in running a business.”66
En permettant à cette culture du partage informel de s’exprimer pleinement grâce à la mise en
place des outils adéquats, l’open source a su faire face à des conditions extrêmes qui sont de
plus en plus souvent celles des entreprises 67 .
64
http://ocw.mit.edu/OcwWeb/Global/terms -of-use.htm#ocw-cc
Voir p.ex. Bonifacio et al., 2003 d’où est tirée la citation suivante.
66
http://www.ewenger.com/ewthemes.html
67
En effet, comme l’exprime Diane Morello (2002): « The 21st-century enterprise is starting to take shape. The
enterprise will be agile, it will be virtual, it will be resilient. [...] Being virtual, it will have people working
seamlessly across time zones, distances, organizations and business boundaries. ».
65
32
Bibliographie
Livres et articles68
Bonifacio Matteo et al., The Richness of Diversity in Knowledge Creation: An
Interdisciplinary Overview, University of Trento, Italy, J.UCS - The Journal of Universal
Computer Science vol.9, 2003
http://www.jucs.org/jucs_9_6/the_richness_of_diversity/paper.pdf
Bouvard, P. et al., Le Knowledge Management Vade mecum, éditions ems management et
société, Collection Pratiques d’Entreprises, Colombelles, 2002
Drakos N., Is Open-Source Content Management a Viable Option?, Research Note, Gartner
Group, 2002.
*Edwards, Kasper, Epistemic Communities, Situated Learning and Open Source Software,
Technical University of Denmark, juillet 2001
*Faraj S. et al., The Web of Knowledge: An Investigation of Knowledge Exchange in
Networks of Practice, University of Maryland, Florida State University, 2001
Godfrey, Michael W. & Tu, Quiang, Evolution in Open Source Software: A Case Study,
Department
of
Computer
Science,
University
of
Waterloo,
2000
(http://plg.uwaterloo.ca/~migod/papers/icsm00.pdf)
**Kuwabara, Ko, Linux: A Bazaar at the Edge of Chaos, First Monday, volume 5, number 3
(March 2000)
*Krishnamurthy, Sandeep, Cave or Community? An Empirical Examination of 100 Mature
Open Source Projects, University of Washington, mai 2002
*Lakhani, Karim & von Hippel, Eric, How Open Source Software Works: Free User to
User Assistance, MIT Sloan School of Management, juin 2002
*Lanzara G.F. et al., The Knowledge Ecology of Open-Source Software Projects, Université
de Bologne, Preliminary Draft presented at the 19th EGOS Colloquium, Juillet 2003
*Madanmohan, T.R. & Siddhesh Navelkar, Roles and Knowledge Management in Online
Technology Communities: An Ethnography Study, Indian Institute of ManagementBangalore, juin 2002
Markus, M. Lynne et al., What Makes a Virtual Organization Work ?, Sloan Management
Review, Fall 2000, Vol.42 Issue 1, p.13
68 Les articles signalés par * et ** peuvent être téléchargés respectivement sur les sites :
http://opensource.mit.edu/online_papers.php et http://www.firstmonday.dk
33
Mockus, Audris & Roy T. Fielding & James Herbsleb, Two Case Studies of Open Source
Software
Development:
Apache
and
Mozilla,
Bell
Labs,
2001
(http://www.research.avayalabs.com/techreport/ALR-2002-003-paper.pdf)
Morello Diane , The Blueprint for the Resilient Virtual Organization, site du Gartner Group,
31 January 2002
Morten T. et al., What’s your strategy for managing knowledge? , Harvard Business Review,
March-April 1999
*Narduzzo, Alessandro & Alessandro Rossi, Modularity in Action: GNU/Linux and
Free/Open Source Software Development Model Unleashed, University of Bologna,
University of Trento, Mai 2003
Nonaka I. et al., SECI, Ba and Leadership: a Unified Model of Dynamic Knowledge
Creation, LRP long range planning vol.33, Elsevier Science Ltd 2000
*Nuvolari, Alessandro, Open Source Software Development: Some Historical Perspectives,
Eindhoven
University
of
Technology,
Janvier
2003
*Orlikowski, Wanda, Knowing in Practice: Enacting a Collective Capability in Distributed
Organizing, MIT Sloan School of Management, mai 2002
Parlby D., Knowledge Management Research Report 2000, KPMG Consulting, 2000.
**Raymond, Eric S., The Cathedral and the Bazaar, First Monday, Vol.3 No.3, March 1998
*Rothfuss, Gregor J, A Framework for Open Source Projects, University of Zurich,
novembre 2002
Schütt Peter, The post-Nonaka Knowledge Management, IBM Deutschland GmbH,
Stuttgart, Germany, J.UCS - The Journal of Universal Computer Science vol9, 2003
http://www.jucs.org/jucs_9_6/the_post_nonaka_knowledge/paper.pdf
**Tuomi, Ilkka, Internet, Innovation, and Open Source: Actors in the Network, First
Monday, volume 6, number 1 (January 2001)
*Zwang W. et al., Peripheral Members in Online Communities, Boston University, 2001
Meissonier R., Organisation virtuelle : conceptualisation, ingénierie et pratiques, Thèse de
Doctorat, IAE Aix-en-Provence, 2000.
(http://tel.ccsd.cnrs.fr/documents/archives0/00/00/25/16/tel-00002516-00/tel-00002516.pdf)
34
Sites internet mentionnés
Gestion des connaissances :
« Can Knowledge be Distributed ?», projet de recherche financé par le "US National Science
Foundation"
voir http://alexia.lis.uiuc.edu/~haythorn/DK_overview.html et
http://www3.isrl.uiuc.edu/~dlinderm/cilbuilder/out.php?cilid=78
« Ten Principles of Knowledge Management », Thomas H.Davenport, PhD,
www.mccombs.utexas.edu/kman/kmprin.htm
Open source en général :
Open source: Rebels at the gate By Mike Ricciuti Staff Writer, CNET News.com October 14,
2002 http://news.com.com/2009-1001-961354.html
Définition officielle de l’open source: the Open Source Definition, Version 1.9
http://www.opensource.org/docs/definition.php
en français: http://www.boson2x.org/article.php3?id_article=39
Licences compatibles avec la GNU General Public Licence (GPL)
http://www.gnu.org/philosophy/license- list.html
McKinlay, Extreme Programming and Open Source Software, 2000
www.advogato.org/article/202.html
The Rules and Practices of Extreme Programming
http://www.extremeprogramming.org/rules.html
Site de type "blog" consacté aux actualités relatives aux nouvelles technologies et à l'open
source
http://slashdot.org
Plateformes pour le développement de projets open-source
http://sourceforge.net
http://freshmeat.net
Projet Zope :
Homepage du projet
http://www.zope.org pour la communauté et http://dev.zope.org pour le développement
Site de la communauté francophone
www.zopera.org
Introduction to the Fishbowl Process
http://dev.zope.org/DevHome/Fishbowl/index.html/Introduction.html
35
Sur les étapes voir aussi:
http://dev.zope.org/Wikis/DevSite/Proposals/ProposalStates
An Interview with Paul Everitt and Ken Manheimer of Digital Creations, publishers of Zope,
March 2001, Daniel Chudnov, oss4lib
(http://www.serverwatch.com/news/article.php/10824_1123551_2)
Digital Creations, Steve Litt, June 1999 Troubleshooting Professional Magazine: More
Heroes, and a Trip to Linux Expo
http://www.troubleshooters.com/tpromag/199906/_digcreate.htm
Zope: sur la décision de devenir open-source:
http://www.zope.org/Members/paul/BusinessDecision
Zope : nombre de serveurs Zope visibles sur internet
http://www.netcraft.com/Survey/Reports/
Projet Celestia :
Homepage du projet
http://www.shatters.net/celestia
L'utilisation de Celestia par la nasa pour un site éducatif:
http://learn.arc.nasa.gov/planets/
Site du projet “Open Universe” abandonné au profit du projet Celestia:
http://www.openuniverse.org/
L'open-source appliqué à d'autres domaines :
Plateforme pour faciliter la création d'entreprises virtuelles
http://www.openadaptor.org/
Massachusetts Institute of Technology (MIT) :
Open Courseware http://ocw.mit.edu/index.html
Free/Open Source Research Community http://opensource.mit.edu
Une encyclopédie basée sur la philosophie et les outils de l'open-source
http://www.wikipedia.org/
36
Annexes :
Bref historique de l’open source
Avant 1980 : Dans les universités, les chercheurs qui développent des programmes
informatiques échangent librement leur code source. Cette manière de procéder facilite
l’apprentissage, l’amélioration du code et l’intégration de systèmes hétérogènes (Tuomi
2001).
Début des années 80 : AT&T commence à vendre des licences pour le système d’exploitation
Unix. Son code source ne peut plus être vu et modifié librement. De plus, l’industrie du
logiciel grandit aux Etats-Unis, s’accompagnant d’un durcissement de la protection légale sur
les programmes informatiques dont le coût de copie est pratiquement nul. Le copyright est
ambigu : d’un côté, en donnant des garanties à l’auteur d’un programme, il tend à faciliter
l’innovation et le développement. De l’autre, il dresse une nouvelle barrière entre les
développeurs.
1984 : En réaction à ces mesures qui rendent le code source inaccessible et afin de retrouver
les conditions de développement qu’il a connu auparavant, Richard M. Stallman, alors
programmeur au MIT, fonde la Free Software Foundation (FSF). Le but premier est de
construire un système d’exploitation (OS) libre qui servira de base au développement
d’autres logiciels libres. Par opposition à Unix, dont le code est désormais fermé, cet OS est
appelé GNU, acronyme récursif de « GNU is Not Unix ».
1989 : la FSF crée la GNU General Public Licence (GNU GPL ou plus simplement GPL) qui
retourne les armes du copyright contre lui en inventant un « copyleft » : le code d’un
programme protégé par ce type de licence sera toujours librement disponible et modifiable.
1991 : Alors qu’en sept ans beaucoup de programmes ont été développés pour le système
d’exploitation GNU, la FSF ne parvient toujours pas à obtenir une version fonctionnelle de
l’élément de base indispensable, le noyau (kernel). C’est dans ce contexte que Linus Torvald,
étudiant à l’Université d’Helsinki, va ouvrir de nouvelles perspectives en mettant à disposition
(sous licence GPL) son travail indépendant sur un OS libre. Sur cette base, un grand nombre
de développeurs participent au développement d’un nouveau noyau, baptisé « Linux »
(contraction de Linus et Unix). Le système d’exploitation dans son ensemble est renommé
GNU/Linux, bien qu’il soit plus souvent connu aujourd’hui sous le simple nom de Linux.
1994 : Sortie de (GNU/)Linux 1.0. Dans le développement open-source, la version 1.0 indique
la première version relativement stable et fonctionnelle (bien que très limitée) d’un logiciel.
La popularité de ce système d’exploitation libre continue à s’accroître.
1997-1998 : Le succès du mouvement open-source et son potentiel prometteur sont de mieux
en mieux reconnus :
- (mai 1997-fév 1998) Eric Raymond, programmeur engagé dans des projets open-source,
donne une conférence intitulée « The Cathedral and the Bazaar », dans laquelle il met en
opposition le modèle de développement traditionnel et celui, innovant et prometteur, de
l’open-source. Souvent vu comme le point de départ de l’étude du « phénomène » opensource, ce texte est beaucoup cité par les auteurs, souvent d’ailleurs pour nuancer ou
37
contredire les thèses avancées par E.Raymond. (P.ex. sur l’aspect novateur du mo uvement
open-source, sur la pertinence du modèle du « bazaar », etc.)
- (31 mars 1998) La mise à disposition du code source de Netscape Navigator (en réaction à
sa perte de parts de marché) est vue à la fois comme une opportunité et une mise à l’épreuve
de grande échelle pour le modèle de développement open-source par E.Raymond (1998).
C’est le début du projet Mozilla, basé sur ce code source.
- Les acteurs principaux du monde de l’informatique (IBM, HP, Sun Microsystems, Oracle,
…), tiennent compte de l’existence des logiciels libres dans leurs stratégies. Certains produits
open-source sont inclus et/ou supportés, le code de certains produits est ouvert et des
développeurs sont engagés pour participer à des projets open-source ciblés. En novembre
1998, deux mémos « confidentiels » (connus sous le nom de « Halloween documents »)
présentant la stratégie de Microsoft face aux logiciels libres sont diffusés sur internet et dans
la presse. Pour la communauté open-source, cela représente une certaine reconnaissance de la
part de l’ « ennemi » Microsoft: en effet, le logiciel libre y est vu comme un concurrent
sérieux.
L’open-source aujourd’hui
On peut illustrer le succès que rencontre le mouvement open-source aujourd’hui, à partir de
quelques exemples:
• Qualité des produits open-source :
La qualité des produits open-source est aujourd’hui largement reconnue et, même sans
véritable promotion, certains logiciels libres sont devenus des concurrents sérieux des
logiciels propriétaires. Apache a par exemple rapidement dominé le marché des serveurs web.
Il possède depuis quelques années plus de 50% des parts de marché 69 :
Parts de marché
69
Statistique sur plus de 40 millions de sites accessibles sur internet, tiré de
http://news.netcraft.com/archives/web_server_survey.html
38
•
Quantité de projets open-source
Le site SourceForge.net, dont le but est de fournir une plate-forme centralisée et un cadre
commun pour la gestion de projets open-source héberge plus de 60’000 projets open-source,
dont 9000 sont qualifiés de « stable » ou « mature ». Plus de 600'000 utilisateurs se sont
inscrits sur SourceForge.
•
Importance de la communauté open-source
Créé en 1997, le site Slashdot.org présente des informations liées à la technologie en général
et laisse une large place aux actualités de l’open-source. Comme les internautes sont autorisés
à publier des informations sur ce site (pour autant que l’article soit accepté), Slashdot est
utilisé par les manager de projets open-source qui désirent attirer de nouveaux participants.
Une large audience est en effet garantie : chaque « news » postée reçoit des centaines, voire
des milliers de commentaires de la part des interna utes. Lorsqu’un site est mis en évidence,
l’afflux de visiteur est parfois tellement important qu’il provoque un déni de service sur le site
en question (on dit alors d’un tel site qu’il est « slashdotted »).
•
Influence sur les entreprises
Les entreprises continuent à voir dans l’open-source un phénomène avec lequel il faut
désormais compter, parfois comme une menace, parfois comme une opportunité. Parmi de
nombreux autres, citons l’exemple de Novell, qui a annoncé cette année que Netware 7.0
fonctionnera sous Linux, et que les produits open-source Apache, MySql et Perl seront
intégrés.
•
Etude de l’open-source
Ce domaine semble également connaître un succès grandissant : par exemple, le site
opensource.mit.edu s’inspire de l’esprit open-source en proposant un espace pour mettre à
disposition des articles à propos du développement open-source et pour en discuter (dans des
listes de distribution). Ces trois dernières années, une centaines d’articles ont été mis sur le
site et des centaines de personnes se sont inscrites aux listes de distribution.
Malgré tous ces signes de succès, il faut noter toutefois que le grand public n’est souvent pas
conscient de l’existence même du mouvement open-source. Pour l’instant, les produits libres
ne rivalisent vraiment avec les logiciels propriétaires que dans les entreprises.
39
8 questions à Chris Laurel, initiateur et "dictateur bénévole pour la vie"
du projet Celestia
1) Je crois que vous avez commencé Celestia seul. Puis d’autres développeurs vous ont
rejoints et la communauté s’est agrandie. Comment avez-vous géré cette évolution ? Etait-ce
facile de permettre à d’autres personnes de contribuer au développement de Celestia ? Avezvous consacrer des efforts à organiser le projet en conséquence ?
I did indeed start Celestia myself. I found out about SourceForge within
a month of the first public announcement of Celestia. I immediately started a SourceForge
project for Celestia and checked in all the source code to the SourceForge CVS
servers. Once that was done, allowing other developers to help out was
simply a matter of adding their SourceForge accounts to the developers'
list. I can't say enough good things about SourceForge; in addition to
CVS for source code management, the developers also interact through a
SourceForge hosted mailing list.
The Celestia user community is centered around the phpBB-based forum on
shatters.net, a server I run from my house.
2) Maintenant que Celestia est un succès et que beaucoup de personnes contribuent au projet,
est-ce difficile de gérer la connaissance autour de celui-ci ? L’amélioration de la
communication dans le projet vous demande-t-elle par exemple beaucoup d’efforts? Avezvous mis en place des processus ou des outils dans ce but ?
There's not a lot of process in place for Celestia development. The
number of active developers is small enough that we've been able to get by
without a lot of protocol, and basic rules of politeness have sufficed.
In general, the developers make a point of posting to the developers list
about any changes. If it's a simple change, a posting is made after a
checkin to notify everyone of the change. If a change is more
substantial, there's usually some discussion on the developers list before
any code is committed to CVS.
3) Avez-vous ressenti des difficultés à partager vos connaissances avec les autres
développeurs, notamment par le fait que vous ne les connaissiez pas, ou que vous ne pouviez
pas communiquer en personne ?
The fact that I haven't gotten to actually meet the other developers has
not been a barrier to collaboration. Also, since I've exchanged a fair
amount of personal email with some of the other developers; getting to
know them--even if it's just via email--actually makes collaboration on
the development of Celestia easier.
4) La mailing-list est utilisée pour des sujets techniques, mais seuls quelques mails sont
envoyés chaque semaine. Quelle différence voyez-vous entre ce moyen de communication et le
forum “development” (qui reçoit environ 8 messages par jour)?
40
The discussion in the mailing list is typically more technical than the
forum discussion, and we tend to spend a lot more time talking about
implementation details there. Often times a new feature idea will be
suggested in the development forum, then discusson of how to actually code
it will occur on the mailing list.
5) Que pensez-vous du canal irc de Celestia, qui vient juste d’être ouvert mais qui ne reçoit
pour l’instant que de rare visites? Ce nouveau moyen de communication est-ce selon vous
utile?
Yes, I think there's a place for the IRC channel. I want to promote the
IRC channel on the main Celestia page--perhaps then we'll get a critical
mass of users there.
6) Avez-vous déjà fait face au départ d’un “core” développeur, et le cas échéant cela a-t-il
représenté une perte de connaissances au sujet de Celestia ?
Early in the life of Celestia, one developer left due to an apparent
personality conflict. He hadn't been working on Celestia too long,
however, so there was no great knowledge lost. Other than that, no
developers have left permanently.
7) La documentation du projet semble s’étoffer depuis peu. Pensez-vous que votre projet est
entre en ce moment dans une nouvelle phase plus mature ?
I think that it's maturing gradually; I haven't noticed any sort of phase
shift however.
8) A votre avis, que se passerait-il si vous n’aviez plus le temps de contribuer au projet vousmême (à cause d’un changement professionnel par exemple) ?
Well, I'd be very upset :) And, I think that the project would suffer a
great deal. But, I have no illusions that I'm irreplaceable--there's
enough interest in Celestia that someone (likely Christophe) would take
over leadership of the project.
41
Etude quantitative de trois listes de distribution de Zope (mois de juillet)
Point de vue : les threads (chiffres arrondis)
Nom de la
Nombre de Nombre de
liste
messages
threads
Zope(-User)
Zope-Dev
ZopeCoders70
1300
230
140
500
70
30
% de threads
orphelins
Moyenne de
msg par thread
Nb maximum
de msg pour
un thread
40%
40%
30%
2,4
3,5
4,4
17
49
21
Point de vue : les auteurs (chiffres arrondis)
Nom de la Nombre
Nombre
% de
liste
total
d’inscrits qui
membres
d’inscrits à reçoivent les
actifs
la liste
messages
durant le
individuellement mois
Zope3000
User
Zope-Dev 1000
Zope80
Coders
Nombre
d’auteurs
(actifs
durant le
mois)
% d’auteurs
actifs
n’ayant
envoyé
qu’un
message
% d’auteurs
actifs ayant
envoyé plus
de 10 mails
60%
10%
300
40%
10%
70%
90%
6%
40%
60
30
50%
40%
10%
Moins de
1%
Définitions des outils collaboratifs cités dans ce mémoire
Ces définitions proviennent de Wikipédia, l' « encyclopédie libre ». (http://fr.wikipedia.org/)
Blog
Abréviation de weblog, un blog est un site web qui constitue un journal en ligne tenu
généralement par une seule personne.
À l'origine il s'agissait de mettre des liens vers des pages web que l'auteur a jugé
intéressantes, accompagnés de commentaires concernant ces pages.
Par la suite on a aussi employé ce mot pour désigner un journal intime (pas vraiment
intime) ou à un journal de bord.
70
On a pas tenu compte des messages envoyés par « zope-tests » (les « CVS checkin messages ») dans ces
statistiques .
42
On retrouve donc à intervalles irréguliers les impressions et sentiments de l'auteur du
blog sur des sujets variés.
Un exemple de célèbre weblog, tenu par plusieurs personnes, est Slashdot, où chaque
article renvoie vers un article publié sur le web présentant une innovation
informatique.
Bugzilla
Bugzilla is a general-purpose computer bug-tracking tool developed by, and used by,
the Mozilla team.
Being web based and open source has made it the bug tracking tool of choice for many
open source projects, and quite a few commercial ones.
Bugzilla relies on an installed HTTP server (such as Apache ) and a database (usually
MySQL) to perform its work. Bugs can be submitted by anybody, and will be assigned
to a particular developer. Various status updates for each bug are allowed, together
with user notes and bug examples.
The notion of a bug in bugzilla is very general; for instance, it can be used to track
feature requests as well.
Concurrent Versions System (CVS)
The Concurrent Versions System (CVS) is a version control system: it keeps track of
all changes to a (software) project and allows several distant developers to collaborate.
It is popular in the free software world and is itself released under the GNU General
Public License.
Forum
Site internet d'échange de messages. Publication message par message, instantanée ou
différée, durable, par plusieurs auteurs. Dans certains forums à inscription, les
messages sont modifiables par leurs auteurs.
Internet Relay Chat (IRC)
L'Internet Relay Chat ou IRC est un protocole de communication sur Internet.
Il a été décrit initialement dans le RFC 1459 par J. Oikarinen et D. Reed, puis révisé
dans les RFC 2810 à 2813.
Le protocole de communication décrit un réseau réparti sur plusieurs serveurs qui,
connectés, forment un réseau. Ce protocole étant public, des clients existent sur toutes
les plates- formes.
Il existe différents réseaux, dont les plus connus sont IrcNET, EfNET, DalNET,
Undernet, FreeNode. Ces réseaux sont le plus souvent libres d'utilisation et gratuits.
Mailing lists
Les listes de diffusion (Mailing lists en Anglais) sont une utilisation spécifique du
courrier électronique qui permet la diffusion d'information à un grand nombre
d'utilisateurs possédant une adresse mèl. Un logiciel est installé sur un ordinateur qui
traite les courriels entrants (qu'il reçoit), et, selon leur contenu, soit effectue des
43
actions spécifiques, soit (cas général) distribue le message à toutes les personnes
abonnées à cette liste de diffusion.
Content Management System (CMS)
Le terme système de gestion de contenu est la traduction de l'anglais CMS (sigle de
Content Management System).
Les CMS ont les propriétés suivantes :
•
permettre à plusieurs individus de travailler sur un même
document,
•
fournir une chaîne de publication,
•
séparer les opérations de gestion de la forme et du
contenu,
•
permettre de publier (mettre en ligne le contenu),
•
structurer le contenu.
Le dernier point le distingue des logiciels de weblogs (blogues en jargeek) où les
nouvelles sont publiées sous formes de fils de discussions, souvent de manière
chronologique et avec un classement par thèmes. Le plus connu des sites sous ce
modèle est http://www.slashdot.org, ainsi ce type de systèmes est appelé parfois site à
la Slashdot.
Wiki
Un Wiki est un site web dynamique dont tout visiteur peut modifier les pages à
volonté .
Il s'agit d'un concept assez récent, bien que la technologie nécessaire existe depuis
plusieurs années. Le nom Wiki provient de l'hawaïen "WikiWiki" qui signifie vite.
Ward Cunningham, le créateur de Wiki, choisit ce nom pour former un diminutif à
partir de "WikiWikiWeb".
Le principe est simple : il s'agit d'un modèle coopératif de rédaction de documents.
Concrètement, n'importe quel visiteur a le droit de modifier la page qu'il est en train de
lire. Les modifications sont ensuite enregistrées et toutes les versions historiques
pourront être accessibles (comme dans un logiciel de gestion de versions). Ainsi, un
premier auteur va rédiger un article, un second va le compléter, puis un visiteur va
corriger une erreur qu'il aura remarquée en navigant sur le site.
Si Wiki est un concept, il existe de nombreux programmes le mettant en œuvre. Ces
programmes sont appelés des moteurs de Wiki. Chaque moteur pouvant être
personnalisé et installé sur un site web précis afin d'offrir les services d'un site Wiki.
44