Simulation en sociologie

Cedric Hartland

Plan :


Retour à la page principale


Présentation du sujet :


Contexte et enjeux :


Les communautés de développement de softwares open sources présentent des comportements assez différents des comportements sociaux étudiés dans le domaine de la sociologie. L’organisation dont découle le processus de création du soft se base sur un modèle qui défie les méthodes classiques de développements mis en application dans les sociétés de softwares. Ces communautés open sources intéressent plusieurs domaines : Aussi bien les domaines industriels avec des enjeux de mises en applications, les domaines économiques mais tout autant de la sociologie. Après tout, ‘Free software is a social movement’ [cf Eliliot et Scacchi 2004]


Ces communautés open sources utilisent comme principal support de communication Internet ; ainsi, des équipes de développement peuvent se repartir sur toute la planète, sans qu’une organisation ne soit clairement précisée. Dans ces conditions, l’expérimentation qui vise à théoriser les comportements sociaux de ces groupes est difficile, cependant, certaines ressources vont nous y aider comme nous le verrons plus loin, et la simulation à l’aide de systèmes multi agents permettent une modélisation assez prometteuse pour créer des modèles de simulations de ces groupes.


Deux études de cas :


Des groupes de recherche commencent à s’intéresser au monde du libre afin de mieux comprendre et appliquer les méthodes sous-jacentes qui en font leur succès. On trouve ainsi des équipes de recherches qui travaillent sur l’étude des communautés open sources, telles que La ‘Free/Open source Research community’ au MIT (http://opensource.mit.edu/), ou encore la ‘Co-ordination Action for Libre Software Engineering for Open Development Platforms for Software and Services’ (CALIBRE: http://www.calibre.ie/). Calibre qui regroupe industriels et chercheurs européen et dont le but est de mieux comprendre la méthodologie de l’open source. « Les logiciels libres sont plus diffusés que les concepts qui les sous-tendent » (Nicolas Julien, Chercheur à l’ENST Bretagne, Coordinateur du projet CALIBRE en France). Nous présenterons en particulier une première étude visant à établir des modèles de simulation portant sur les communautés open sources de développement de softwares réalisé par Walt Scacchi [2004] dans un cadre général non orienté Systèmes Multi agents mais dont les travaux sont tout à fait pertinents. Nous nous intéresserons surtout aux études portant sur la simulation de ces communautés et plus précisément à celles qui utilisent une modélisation basée sur des systèmes multi agents. Pour cela il sera présente le simulateur SimCode réalisé dans le cadre de cette étude par Jean Michel Dalle (umpc) et Paul A. David (stanford). Dans un cas comme dans l'autre, nous ne discuterons pas des resultats à proprement parlé puisque SimCode, s'il en fournit déjà, est toujours en développement mais nous présenterons des resultats au fil de nos discutions.


Présentation du monde libre et ouvert :


Historique et fonctionnement :


C'est le projet GNU, initié par Richard Stallman et développé par des hackers, qui est à l'origine des logiciels libres, dès 1984. De très nombreuses communautés de développeurs, dont des fondations ou forges, se sont ensuite créées dans le monde, composées de bénévoles, d'étudiants, de chercheurs, etc. Certaines de ces communautés ont évolué vers des « ensembles de contributeurs » constitués en sociétés (Red Hat, MandrakeSoft, MySql,..).

En particulier, on décompose le mouvement Free et le mouvement Open. Bien qu’il existe des nuances, nous présenterons ici uniquement le contexte général en présentant les deux sous un même jour, ainsi, nous parlerons de Free/Open Source Software Développement. (F/OSSD)


La définition de Bruce Perens (http://perens.com/Articles/OSD.html) de l’open source inclue des règles morales qui excluent la discrimination entre les personnes ou les groupes. Ceci va à l’encontre de toute forme de hiérarchie même si, comme nous le verrons, une organisation minimale mais flexible est tout de même à l’oeuvre au cours du développement d’un projet (le core team). De plus, on peut constater dans la pratique que les membres de telles communautés expriment une forte motivation et un volontariat pour les projets sur lesquels ils travaillent. Ainsi, le développement d’application open sources s’effectue sur la base d’un travail collaboratif. Chaque membre de la communauté peut contribuer à la création du logiciel. Un core team, composé de contributeurs effectue les contrôles, assure la cohérence ainsi que la qualité des développements. Cette organisation permet la production de logiciels dont le coût est limité et la technicité élevée. De plus, la communauté joue un rôle important dans la phase de déboguage qui est plus rapide (selon l’importance du groupe) car chaque membre y participe, ce qui garanti une bonne qualité du produit. Ainsi des projets tels que mozilla possèdent deux équipes distinctes, l’une pour la programmation (http://www.mozilla.org/developer/) et l’autre pour le deboggage (http://www.bugzilla.org/developers/profiles.html)


Première approche sur ces communautés :


Rentrons un peu plus dans le détail de ce qui se fait dans les communautés open source. On dispose d’une communauté dont des membres sont des équipes de projets. Le processus de construction des softs passe aussi par le téléchargement, l’installation et l’utilisation des softs. En cela, une certaine part de communication et d’échange a son importance pour promouvoir l’utilisation de ces softs. Pour cela, il faut des vecteurs de diffusion, ce que proposent les sites webs tels que SourceForge (http://sourceforge.net/). Il faut noter que ces vecteurs proviennent pour la plupart du monde du libre car ont été réalisé en F/OSS (Free/Open Source Software). Ainsi les serveurs apache hébergent des sites en php ou Jboss avec des bases de données MySql. L’utilisateur lui même va consulter ces sites en utilisant des navigateurs tels que mozilla.

Plus que cela, les membres de la communauté utilisent des outils de développement qui sont des F/OSS tels que CVS (concurrent version system) NetBeans, emacs...)

Ainsi cette communauté s’est créée son support de communication, et celui ci présente un intérêt certain pour la modélisation comme nous le verrons : Le système de communication est asynchrone, et donc persistante, traçable et globalement accessible. Cela fonctionne par mail ou par le mécanisme du tableau noir par lequel tout le monde parle avec tout le monde. Cela permet surtout aux nouveaux venus d’y trouver une mine de renseignements, d’infos pratiques et de s’immerger dans un projet après qu’il ait commence. Cette source fournit de très nombreuses informations sur les études sociologiques qui pourront être effectuées.


Pour quelles raisons participer ?


Nous avons ici vu ce que font ces communautés de développeurs. Ils se réunissent et développent des softwares. Ce qui va intéresser la modélisation consiste à comprendre non seulement le fonctionnement mais bien évidement les motivations des développeurs. Pourquoi est-ce que les développeurs joignent et participent à cet effort, alors même que ce dernier, s’il leur prend du temps, n’est pas rémunère ? Quelques études récentes ont tenté de répondre à cette question. [Ghosh 2000, Lakhani 2002, Hars 2002, Hann 2002, Hertel 2003] Il en ressort trois informations qui sont :


Certain projets deviennent importants et donnent naissance à de grosses équipes. La connexion entre les membres se fait au travers de sites webs et par mail. Pour un contributeur, devenir un membre important, dans le nœud central du projet, apporte un fort capital social et une grande reconnaissance des pairs. Cela est d’autant plus vrai que les gros projets attirent plus de contributeurs.


Rôles et décisions collectives :


Chaque contributeur décide de jouer le rôle qu’il veut au sein du développement. A ce titre, on distingue plusieurs rôles attribuables au sein des communautés :



Autant s’ils choisissent leur rôle et s’ils peuvent décider de changer ce dernier, cela se fait d’une façon quelque peu plus délicate. Le contributeur doit être reconnu de ses pairs comme étant un contributeur accompli et de confiance. Si la réputation joue, l’autre facteur déterminant est le mérite. Ainsi certains décrivent le système comme une ‘méritocratie’ [Fielding 1999]. Cela ajoute une propriété qui consiste en une forme stable de leadership des projets ; en cela il s’agit d’une forme virtuelle de management des projets.


Les décisions à tout niveaux, que ce soit le choix des features ou les décisions de ce qui doit être corrigé ou non et de façon générale toutes les discutions qui se font autour d’un projet, se font de façon démocratique. Il s’agit d’une sorte de discussion à l’issue duquel s’effectue un vote pour lequel tous les membres sont à égalité dans le choix, quel que soit son rôle. On peut constater qu’ici le sens du management du projet est très différent puisque les décisions ne sont pas imposées par un petit nombre et elles sont systématiquement discutées.



Une communauté très liée :


Comme nous l’avons vu, tous les projets qui rassemblent les communautés open source ne sont pas totalement indépendants puisque certains membres participent à plusieurs projets tout en utilisant des outils développés par cette même communauté. Plus encore, des projets peuvent être réutilisés sous forme de modules empruntés ou toute une application qui sera incorporée dans un autre projet. On se retrouve ainsi face à un ensemble de projets qui sont interdépendants, regroupant des réseaux de développeurs qui utilisent des outils communs. Ils partagent les sites webs (tels que sourceforge [7]) ce qui permet de mettre en rapport membres et projets.


Le fait que des modules ou des softs soient réutilisés apporte aussi la possibilité de découvrir des erreurs dans les modules, de modifier le code afin de le rendre plus optimal, de mettre à jour d’éventuelles failles. Ceci fait qu’en réutilisant les anciens projets, ces derniers peuvent aussi bénéficier d’améliorations ou de corrections, même s’ils ne sont plus des projets actifs. Ce phénomène est appelé co-évolution.


Nous nous sommes fait ici une idée plutôt précise du fonctionnement, en général de ces communautés de développeurs. Cela va nous permettre de bien saisir les idées développées pour la modélisation du simulateur visant à les représenter. Nous remarquerons que nous nous sommes ici attachés principalement à l’aspect social et humain de ces communautés de développement mais il ne faut pas négliger les impacts en terme de management de projets et d’économie qui représentent le plus gros des études portant sur le domaine, et les modélisations pourront difficilement s’effectuer sans prendre en compte de tels paramètres. Le lecteur pourra s’en rendre compte très simplement en étudiant les références proposées en fin de cette étude.

Maintenant, nous allons nous intéresser à la modélisation de ces communautés. Le cadre étant bien entendu la simulation par Systèmes multi agents, nous présenterons cependant d’abord une première modélisation qui se veut plutôt générale et pas spécifiquement orientée multi agent mais qui s’avère assez différente de la seconde qui elle sera basée sur la modélisation par agents.


Première étude :


Dans l’étude réalisée par Scacchi [2], il propose une modélisation de communautés de développeurs open source mais pas pour une modélisation multi agent. Cependant, son étude du domaine apparaît très complète et pertinente de plusieurs points de vues, de plus, elle apporte un aspect critique face à l’autre modélisation que nous étudierons.


Pour commencer, il présente le fait que tous les projets ne s’organisent pas nécessairement de la même façon (comme mozilla et son équipe de debuggage bugzilla par exemple). En cela, il faut faire extrêmement attention lors du choix du modèle. On le comprend d’autant plus lorsque l’on réalise qu’il n’y a plus de cent mille projets qui ne disposent pas de plus de deux programmeurs. Beaucoup de projets sont purement inactifs ou sans aucune releases. Nous constaterons que ces facteurs ont une certaine importance dans la valeur que les développeurs vont attribuer aux différents projets à travailler. Il y a maintenant quelques milliers de softs qui sont viables et qui fonctionnent effectivement. En fait, il s’agit finalement d’un univers varie avec de nombreux projets a étudier. Dans de telles conditions, il peut exister de nombreux modèles de simulations. En cela, les modèles existants servent plus de bases à de nouvelles études qu’ont de réels résultats.


Pour bien modéliser, il faut poser quelques questions sur la nature de la problématique. Ainsi, l’idée générale est de comprendre comment cette apparente absence d’organisation, sans planification, sans équipe définie ni de software engineering, permettent d’obtenir un soft fonctionnel.

Afin d’y répondre, il faut se concentrer sur des aspects plus orientes développeur avec des questions du type : pourquoi les développeurs y participent? Comment est-ce que les larges projets sont maintenus ? Comment les larges projets sont coordonnés, contrôlés ou managés alors même qu’il n’y a pas de management team ? Une autre question qui à aussi son importance vient du fait que les réponses a ces questions peuvent varier au long du développement du projet, on peut donc légitimement essayer de comprendre pourquoi on en arrive a celà.


Son étude propose en résultat un tableau représentant des approches de modélisations et de simulations se voulant adaptées selon les buts recherchés tout en étant appuyé sur une représentation fortement centrée sur l’humain. La seconde approche vise à modéliser la même chose mais en axant les résultats selon la composante du développement du logiciel.

Seconde approche avec SimCode :


Présentation :


Nous effectuerons ici une étude plus avancée du sujet. Cette étude s’intéresse aussi aux communautés de développement de softwares open source. Elle propose de proposer une modélisation qui sera celle utilisée dans le simulateur SimCode [1].


Une première question qu’il parait nécessaire de développer est de savoir en quoi les Systèmes Multi Agents sont intéressants pour la modélisation et la simulation de communautés de développement open source. Le noyau de la simulation porte ici sur l’émergence de comportements obtenue a partir d’individus hétérogènes. Le fait est que l’on dispose d’un modèle qui représente l’univers et qui propose des projets informatiques composés de modules. Certains de ces modules vont se voir adjoindre de nouveaux modules au long de la progression des projets. Face a cet environnement, chaque individu choisit selon des critères qui vont dépendre de chacun les modules sur lesquels ils vont passer du temps a coder. Pour se faire, il s’avère que les agents sont un excellent compromis pour représenter ce genre de modèles complexes et qui prennent en compte les interactions. Ici l'agent sera un développeur qui aurra des caractèristiques visant à peu près à coller aux représentations posées par les études réalisées. Son environnement sera tout simplement un espace des softs en cours de réalisation, ou plutôt un espace de modules de softwares. Les agents pourront travailler sur des modules selon leurs envies ou choisir d'en créer de nouveaux.


La modélisation va s’accentuer autours du développement des softwares, ainsi, la représentation portera sur une arborescence dont les noeuds seront les modules d’un soft, et ces modules auront un stade de développement plus ou moins avance. Ces structures sont des ‘software trees’ et représenterons l'environnement pour les développeurs agents. Pour un développeur (que nous représenterons par un agent) l’effort de codage s’accentue selon objectifs :


A cet effort de codage s’ajoute une composante de mesure sociale. (Ceci dans le but de permettre d’évaluer la morphologie des ‘software trees’. Des structures stimulées qui génèrent un plus grand degré de concentration (mesure par le coefficient Gini) ne conduisent pas particulièrement a produire des softwares au code organise qui produisent une grande utilité aux utilisateurs (end-users) qui veulent une choix d’application large et varie.)


A tout ceci s’ajoutent un mécanisme simple de gouvernance qui se traduisent par des règles de maintenances qui permettent une ‘early release’ (perversion ou version de tests). Ce dernier paramètre peut avoir un effet positif sur la valeur de l’utilité sociale du software tree résultant.


Modélisation :


Nous avons maintenant une bonne base de travail pour proposer une modélisation toujours dans le cadre du projet SimCode.



Chaque développeur est différent des autres (hétérogénéité), la question ne se pose pas ici de représenter correctement une population d’individus qui puisse correspondre effectivement avec les communautés a l’oeuvre. Des caractéristiques non observées vont agir comme paramètres qui seront entre autre utilisées par les fonctions qui déterminent le choix stochastique des modules sur lesquels travailler. L’idée est que chaque développeur va choisir une tache al plus gratifiante selon son point de vue, ce qui est garanti d’être non déterministe grâce aux caractéristiques non observées. Cependant, un poids non égal est attribue aux modules et ceux ayant un meilleur intérêt (ou récompense en terme de mérite/réputation) ont une plus grande probabilité d’être choisie.


Nous le constaterons ici, une part important du modèle tient grâce aux caractéristiques non observées. ‘Every good work of software starts by scratching a developer’s personal itch’ [Raymond 1998a].


Si l’on se concentre sur l’arbre des modules. On doit tenir compte que tous les codeurs ne se concentrent pas uniquement sur les modules prévus mais peuvent aussi en créer de nouveaux qui viendront s’associer aux modules existants. Cela se traduit sur l’arbre par des branches et nœuds qui ne sont représentés qu’en partie. Cela peut être d’ajouter simplement un nouveau module ou de séparer des fonctionnalités d’un module.


Etudes complémentaires :


L’étude des communautés apporte ici quelques informations complémentaires qui peuvent avoir de l’influence en termes d’heuristiques à développer par le simulateur. Ici deux propriétés qui influencent les choix des développeurs :


  1. Lancer un nouveau projet est plus gratifiant que de contribuer à un projet deja existant et en cours. En rapport, les contributions apportées aux premiers modules sont plus gratifiantes que celles apportées sur les derniers modules.

  2. contribuer à un projet actif est plus gratifiant que de contribuer à un projet stagnant ou inactif puisque la contribution sera observée par un plus grand nombre de pairs.



Conclusion :


Nous avons vu dans ce travail une étude visant à modeliser les développeurs des communautés open source. Ces dernières présentent des comportement sociaux généralement différents des autres communautés étudiées dans des domaines differents. Nous avons vu qu'il apparaît difficile de généraliser de telles études tant ces communautés peuvent ne pas être organisées de mêmes façons. Cependant elles sont tout de même intimement liées puisqu'elles utilisent les resultats de leurs travaux comme outils afin de developper leurs autres projets, mais aussi les développeurs ne se concentrent pas sur un unique projet à la fois.


Les résultats des simulations ne sont pas évidents dans la mesure où SimCode est encore dans un stade d'évaluation. Cependant, selon la théorie du razoire d'occam, le simulateur, avec un minimum de paramètres permet d'obtenir de bons résultats mais qui restent à affiner. Nous avons discutés des resultats au long de l'étude car un bon nombre d'entre eux sont le fruit des nombreuses études sur la question. Les resultats qui interressent SimCode sont de comprendre le processus de fabrication du soft selon l'organisation open source. Une poursuite du travail consiste selon les autheurs à ajouter des modules au simulateur, peut être en le posant comme un projet open source, cela serait une bonne façon d'évaluer leurs resultats experimentaux.


Un point de critique que l'on peut extraire de cette étude est que l'idée de représenter un simulateur portant sur ces communautés open source est qu'il ne faut pas negliger l'aspect humain puisque l'humain est au centre de ce système qu'il s'est créé. Un grand nombre des études se concentre sur l'aspect economique ou managérial en ne tenant que trop peu ou pas du tout de l'aspect social. Comprendre une organisation sans comprendre les aspects moraux qui lui sont associés ne donnerons pas de resultats probants en la matière. Ainsi, SimCode utilise cet aspect pour représenter une technique de développement de softs mais les autheurs font signaler qu'il faut travailler plus sur cet aspect, en concentrant leurs travaux à rendre les agents-développeurs plus proches de ceux que l'on trouve dans la réalité. Le second aspect qu'ils devraient peut être travailler consiste à revoir leur environnement qui ne consiste pas uniquement en des modules mais aussi des moyens de communications et des façons d'interragir avec ces softs, en considerrant les différents rôles que les agents peuvent endosser.


J'espère que cette étude vous aurra plu, et si c'est le cas vous pourrez étendre vos recherches en suivant les quelques liens et travaux cités en références.



Références :


[1] Jean Michel Dalle, Paul A. David ‘SimCode: Agent Based Simulation Modelling of Open-Source Software Development’ [2004]

[2] Walt Scacchi ‘Opportunities and Challenges for Modelling and Simulating Free/Open Source Software Processes’ [2004]

[3] Free/Open source Research community, http://opensource.mit.edu/

[4] Co-ordination Action for Libre Software Engineering for Open Development Platforms for Software and Services, http://www.calibre.ie/

[5] l'initiative open source http://www.opensource.org/


References pour approfondir:


[6] Journal of Artificial Societies and Social Simulation (JASSS) http://jasss.soc.surrey.ac.uk/JASSS.html

[7] SourceForge : http://sourceforge.net/

[8] Andrea Bonaccorsi, Christina Rossi, ‘Why Open Source software can succeed’ [2003]

[9] Andrea Hemetsberger, Christian Reinhardt, ‘Sharing and Creating Knowledge in Open-Source Communities: The case of KDE’ [2004]

[10] Michael B. Twidale, David M. Nichols, ‘Usability Discussions in Open Source Development’ [Working paper 08/2004]

[11] Paul Guyot, Alexis Drogoul, ‘Designing Multi-agent based participatory simulations’ [2004]

Retour à la page principale