Pendant l’année scolaire 2006/2007, le projet CartoReso avait été lancé par Jean-Sébastien Hächler, Pierre Pattard et Jérémy Fain - sur l’idée de ce dernier.
Ces trois élèves de l’option Technologies de l’Information de l’Ecole Centrale Paris avaient ainsi créé un logiciel de cartographie de réseau identifiant les ordinateurs et autres machines sous TCP/IP, en particulier celles qui ne sont pas entièrement sécurisées. L’outil permettant notamment de réaliser des audits de sécurité d’un réseau local d’entreprise. J’avais à l’époque recommandé à l’équipe de mettre le logiciel en open source et sur SourceForge. Histoire de permettre son évolution au delà du projet de l’année scolaire et sa prise en main par d’autres.
Pendant cette année scolaire, une équipe d’étudiants du même sérail a pris le relai du projet initial : Julien Elie et Nicolas Nordmann (ci-dessous à gauche et à droite). C’est une expérience intéressante qui n’est pas si fréquente que cela pour des logiciels réalisés dans des projets d’élèves. On la retrouve plus souvent avec les étudiants qui travaillent sur de l’expérimentation ou de l’algorithmie, comme dans la robotique.
Je vais ici faire le point sur le projet et en profiter pour faire quelques digressions sur la praticité du modèle open source employé sur ce projet.
Un projet pluriannuel
L’intérêt d’avoir un projet pluriannuel pour les étudiants est multiple :
- On dispose de plus de ressources. En effet, l’emploi du temps alloué au projet est d’environ une vingtaine de journées. C’est court pour livrer du logiciel bien fignolé, même à plusieurs !
- Il permet l’apprentissage des étapes d’industrialisation du logiciel. En effet, le chemin est long entre le code qui semble fonctionner sur une machine et le véritable produit logiciel. Il faut une procédure d’installation, supporter plusieurs systèmes d’exploitation, débugger le code et prévoir l’extensibilité du logiciel.
- Il facilite l’apprentissage du travail en équipe dans le temps et dans l’espace. Il pousse notamment les élèves à bien penser l’architecture de leur logiciel.
- Il garantit une certaine pérennité aux travaux réalisés, ce qui est rarement le cas pour un projet logiciel réalisé “one shot” et sans suite. D’autant plus que ce genre de logiciel n’a pas forcément de business model qui tienne la route pour une startup, particulièrement pour des utilitaires. Comme il est difficile de créer une entreprise avec, la structure pérénnisant le projet est le projet pluriannuel. C’est aussi la raison du choix d’un modèle open source, très courant dans l’enseignement supérieur. Pour des raisons pratiques plus qu’idéologiques.
- Il permet au projet d’avoir un réel impact. Ne constate-t-on pas régulièrement ce gâchis avec tous ces projets d’étudiants qui n’aboutissent à rien, à aucun produit, à aucun usage, à aucune création de valeur pour les autres !
Dans le cas de CartoReso, le code source - développé sous Linux - avait été publié sur SourceForge en 2007. Il faisait lui-même appel à une grosse demi-douzaine de bibliothèques open-source.
L’équipe projet 2007/2008 a réalisé un gros travail de documentation du code, qui n’avait pas été réalisé par la première équipe (à éviter…). Elle a de plus enrichi le site web du projet qui documente à la fois le code, l’installation et l’usage du logiciel.
Ensuite, l’équipe s’est consacrée à la création d’une architecture d’extensibilité de CartoReso, basée sur l’accès aux données générées dans un premier temps, et puis sur des extensions Java dans un second temps.
Au final, elle a adapté le logiciel à Windows, ce qui ne fut pas sans peine (et n’est pas véritablement achevé) car les bibliothèques tierces-parties ne s’y comportent pas de la même manière que sous Linux. L’ancienne équipe - toujours joignable, a même contribué à l’adaptation du code et à la compilation.
Enfin, l’équipe a rédigé un rapport de projet en anglais. Autre manière de déclencher à terme, au même titre que le site du projet, de générer un effet communautaire à l’échelle de l’Internet.
Cartoreso n’est évidemment pas seul dans son domaine. Les élèves de l’Ecole Centrale sont à l’origine du projet pluriannuel open source ayant probablement eu l’un des impacts utilisateurs les plus forts : le player multimédia Videolan (VLC media player), téléchargé plus de 70 millions de fois depuis sa création. Il était géré par des élèves de seconde année au départ. Il continue de vivre sa vie depuis maintenant et attire environ une centaine de contributeurs, au delà de Centrale. Cela donne envie de reproduire ce succès sur d’autres catégories de logiciels !
Impact de l’open source
Voyons un peu l’impact de la mise en open source du projet. A ce stade de la vie du projet, l’open source n’a servi à rien. C’est plutôt un freeware, téléchargé grâce à SourceForge où il a été placé.
Il y a eu 1614 téléchargements depuis le placement du projet dans SourceForge. Cela s’est accéléré récemment, comme pour de nombreux projets open source, avec l’arrivée récente de la version Windows (ci-dessous).
Le projet est au rang 1884 en termes d’activité sachant qu’il y a 173000 projets open source sur SourceForge. Cinq personnes sont enregistrées dans le projet : ce sont les deux équipes projets qui se sont succédé l’une à l’autre. Cela montre, comme pour les projets commerciaux, qu’il y a une grande fragmentation des logiciels, avec une activité - commerciale ou non - concentrée sur le 1% des projets les plus populaires.
L’expérience de Cartoreso montre que le déclenchement du fameux phénomène communautaire de l’open source ne se décrète pas. La grande majorité des projets open source (sur SourceForge) n’ont ainsi pas du tout de communauté. Juste des utilisateurs qui testent de temps en temps. Le modèle “communautaire open source” (pour les contributions et les corrections apportées au code) est souvent utilisé comme argument marketing d’éditeurs de logiciels libre, mais sans réalité derrière. Pour ce faire, il faut d’abord que le logiciel intéresse un grand nombre d’utilisateurs. Cela passe par un peu de communication, souvent virale (sites spécialisés, blogs). Ensuite, il faut que parmi ces utilisateurs, il y ait une masse critique de développeurs qui pourraient être motivés à contribuer, et en auraient le temps et disposeraient des compétences. Cela fait un sacré filtrage au bout du compte. Ce filtrage est encore plus fin si le projet est complexe. Il ne faut ainsi pas s’étonner que largement plus de la moitié des contributeurs à la suite bureautique OpenOffice soient toujours des développeurs de Sun.
Dans Cartoreso, le défi provient aussi du caractère mouvant du leadership du projet. Dans l’open source comme ailleurs, la stabilité du leadership est fort utile. Linus Torvalds n’est-il toujours pas en charge des évolutions du kernel de Linux ? Nous avons donc ici un handicap à relever. Les projets open source fonctionnent rarement en autogestion. Il y a toujours une équipe au coeur du projet qui le fait vivre, et des contributeurs qui gravitent autour.
La suite de Cartoreso
L’aventure de ce projet doit continuer. De nombreuses extensions au logiciels sont prévues, et attendues par les utilisateurs, notamment la société Ercom qui a suivi de près le projet.
A la rentrée 2008, si tout va bien, une troisième équipe de Centraliens devrait prendre le relai. Les étudiants sont en effet libres de choisir leur projet. La nouvelle équipe aura au moins trois missions clés :
- Peaufiner l’architecture de plug-ins
- Créer quelques extensions clés (comme l’analyse des évolutions temporelles et spatiales des machines détectées)
- Faire naitre une communauté autour du logiciel. Un exercice de style qui mélange développement logiciel, marketing, communication et gestion de projet.
En parallèle, j’ai lancé le même schéma avec un autre projet initialisé cette année scolaire par une équipe de quatre élèves : un lecteur RSS nouvelle génération, synthèse de ce qui se fait de mieux aujourd’hui, avec quelques plus “inédits”. J’aurai l’occasion d’en reparler à la rentrée scolaire.
Et vous, avez-vous eu vent de projets pluriannuels comme Cartoreso dans des universités ou grandes écoles en France ? Quelle en a été l’expérience retirée ?
Bravo à Nicolas et Julien pour le travail de longue haleine réalisé sur CartoReso cette année! Ce qu’ils ont fait est fantastique. Documenter un code existant est notamment un travail on ne peut plus ingrat, mais qui est nécessaire dans l’optique de dépasser le simple stade artisanal.
A regarder les courbes de téléchargement, on constate à quel point le portage et le packaging de l’installation sous Windows a permis au logiciel de bénéficier d’un “effet de base installée”. Si Ubuntu avait été choisi comme plateforme de référence pour des raisons de compatibilité, passer sur un OS qui représente 85% du parc a démultiplié la zone de chalandise, ie les utilisateurs potentiels, de l’application. Evidemment, la logique ne s’applique que sur des logiciels clients (sinon il s’agirait des browsers).
Plusieurs administrateurs réseaux-sécurité de grands groupes et ministères utilisent aujourd’hui CartoReso, ce qui est une satisfaction énorme: cela veut dire que loin d’être un projet de labo, le logiciel rencontre petit à petit son marché.
Une remarque Olivier sur l’absence de business model qui tienne la route avec CartoReso: en tout état de cause, il y aurait largement la place de monter une société d’audit sécurité et réseaux s’appuyant sur CartoReso (eg détection d’ordinateurs dormants dans le réseau de l’entreprise qui seraient des failles; comptage des machines; inventaire du parc d’OS; attributions d’IP; etc.). Mais la rentabilité de ce modèle économique de service outillé s’apparente à une société de conseil classique. Or, les modèles industriels sont tellement plus difficiles à réaliser, mais tellement plus beaux également…
Pour ce qui est du business model, je faisais évidemment allusion à celui d’un éditeur de logiciel, pas à une SSII / SSLL.
Je suis d’accord avec vous pour dire que les petits projets n’ont souvent pas de communautés derrière, mais parler de pure argument marketing de la part des editeurs de logiciels libres est a mon avis un peu éxagéré. Il ne faut pas partir du principe que la communauté, c’est forcément des développeurs bénévoles qui participent sur leur temps libres. Les sociétés peuvent faire partie d’une communauté : par exemple, OpenOffice est pas mal développé par Sun, mais Novell et IBM y participent grandement aussi. Pour d’autres projets, comme KDE, Eclipse ou le noyau linux, ce n’est même presque qu’un grand rassemblement d’entreprises : les développeurs sont dispatchés un peu partout. Alors certes, ça ne profites souvent qu’au gros projets, mais c’est aussi les plus gros projets qui demandent le plus de boulots.
Concernant CartoRezo, je ne le connais pas particulièrement, mais a mon avis si quelqu’un le maintient sur le long terme c’est typiquement le genre de projets qui peut avoir sa petite communauté : les admins l’utilisant sont plus que suscèptibles d’avoir les compétences pour l’améliorer, et peuvent avoir besoin de fonctionnalités suplémentaires.
Une dernière chose : c’est vrai qu’un leader stable et tout puissant c’est un gros avantage, et que Linus en est un belle example. Il conviendra toutefois de noter que Linus reste le leader uniquement parce que la communauté(ie aussi bien d’entreprises que de développeurs indépendants, et dans une moindre mesure d’utilisateur) y trouve son compte. Et le fait que celle-ci garde la possibilité de forker, et donc pourquoi pas changer de leader, est a mon avis l’un des ingrédient du succès de Linux. Sans cela, sans doute que beaucoup d’industrielles n’auraient pas investit dedans : c’est un gage de pérénité quelque part, si le leader commence à tourner au vinaigre les années d’investissements ne seront pas à jetter pour autant. Donc un leader tout puissant, pourquoi pas, mais pas trop quand même
Steph, vous prenez comme exemples les logiciels libres les plus connus et sur lesquels la communauté (d’entreprises, effectivement) est très active.
Mais il y a 173000 projets open source dans SourceForge et la grande majorité ne bénéficient pas de cet effet. Cela comprend certes des outils mineurs peu utilisés, mais probablement des projets issus de petites SSLL ou petits éditeurs de logiciels libres. L’indicateur pertinent, c’est le % des développements qui ne proviennent pas de l’équipe d’origine du logiciel. Avez-vous cet indicateur pour toutes les SSLL françaises par exemple ?
Argument marketing ? Ca l’est au moins pour des raisons pratiques quand les avantages de l’open source sont mis en avant mais pas forcément opérationnels si le logiciel ne bénéficie pas d’une véritable communauté active.
Les raisons de l’investissement d’industriels comme IBM dans Linux sont à mettre sur le compte de plein de raisons stratégiques qui pour certaines n’ont rien à voir avec les beautés de Linux :
- Coût de maintenance des Unix propriétaires
- Tendances du marché
- Positionnement marché “communautaire“
- Possibilité de vendre du service grâce à l’open source
- Résistance à la part de marché croissante de Microsoft dans les logiciels serveurs
Ce qui n’a pas empêché IBM de rester le second éditeur de logiciels propriétaires du marché professionnel derrière MS et proche d’Oracle. IBM est open source quand ça l’arrange (pour les OS, pour vendre du matériel et des services), mais pas au point de saborder son business logiciel classique : les softs mainframes, les Lotus, Tivoli, Rational, DB2 et autres Websphere. Si ils croyaient tant à l’open source comme modèle universel, n’auraient-ils pas adopté le modèle pour leurs logiciels propriétaires ?…
Pour Microsoft, c’est pareil. Certains ont vu les récentes annonces de l’éditeur comme une “adoption de l’open source” (leurs licences open source validées par l’OSI, etc). Loin de là ! C’est surtout un moyen de se faire bien voir de la communauté open source (et il y a encore du chemin!), et de l’enseignement supérieur et de la recherche. Mais pas question de mettre leurs logiciels propriétaires classiques et rémunérateurs en open source ! Même quand leurs codes sources sont par ailleurs disponibles pour consultation (comme c’est le cas de Windows depuis des années).
Sinon, le fork que vous décrivez est effectivement une sorte d’assurance vie, mais en même temps, c’est un talon d’Achille. La grande diversité des distributions Linux est probablement l’un des facteurs qui ralentit l’adoption de Linux, au moins sur le poste de travail. Ce qui explique la sélection naturelle du moment, qui voit Ubuntu surpasser les autres distributions. Pour devenir un marché de masse, Linux a besoin d’être unifié et moins “divers”. C’est un paradoxe difficile à admettre pour la communauté Linux.
C’est un fait bien établi qu’une grande majorité des projets sous Sourceforge n’ont comme seuls contributeurs que leur petite équipe initiale. Mais cela n’en fait pas de simples freeware pour autant, car les sources sont effectivement consultées régulièrement. Il y a dans l’open source une dimension importante à mes yeux, celle de patrimoine, “patrimoine de l’humanité” si on veut y mettre un peu d’emphase. Or l’informatique progresse bien plus par l’élargissement du patrimoine de code source que par de la connaissance fondamentale.
Tous ces projets, le fruit de l’ingéniosité et du labeur de cette génération, sont à la disposition des générations futures. Peu importe que certains soient de médiocre qualité, les lecteurs feront leur marché. A ce titre, sourceforge est une bibliothèque plus qu’un gestionnaire de sources, mais c’est déjà énorme.
Cela dit, le but de tout projet open source est effectivement d’attirer quelques développeurs tiers. Outre le ‘marketing communautaire’, c’est surtout l’utilisation effective du produit qui finira par amener des contributeurs.
Patrimoine… pourquoi pas. Mais dans pas mal de cas, cela fait plus penser aux oeuvres non exposées des sous-sols du Louvre qu’autre chose! En tout cas, comme dans la culture, il y a un processus de sélection qui s’opère par l’audimat.
Je souscris entièrement à ton dernier point. En général, développement logiciel ou pas, il y a environ un contributeur pour 25 à 50 consommateurs d’un produit ou service immatériel. Donc, pour avoir des contributeurs, il faut d’abord attirer un grand nombre de consommateurs. Parmi eux, on aura alors quelques développeurs ayant le pédigrée souhaité: intéressés, compétents, ayant du temps, et quelque peu altruistes.
Pour reprendre certains éléments de la discussion, l’Open Source me semble procurer deux avantages majeurs :
- Le “Try & Buy” : la possibilité d’utiliser des logiciels ou des sources sans paiement initial pour les premiers développements. Un modèle très bien adapté aux startups à la différence des logiciels classiques, qui, malgré quelques aménagements, nécessitent rapidement de payer des coûts fixes de licences en regard d’un business dont la rentabilité peut se faire attendre.
- La capitalisation des développements réalisés : il est beaucoup plus facile de partager des développements réalisés, notamment par des entreprises clientes sur des fonctions périphériques et non coeur de business, avec un modèle open source. Et ces développements peuvent représenter des volumes importants couplés à une imprécision de l’expression des besoins fonctionnels. J’ai ainsi été frappé par la richesse des modules complémentaires offerts par les CMS Open Source. Il y en a des centaines pour les CMS les plus utilisés qui couvrent la plus grande diversité des besoins et qui ont été capitalisés au fur et à mesure des développements clients.
A contrario, les arguments habituellement avancés sur l’Open Source me semblent beaucoup moins pertinents :
- Coût de licence inférieur (mais le coût total de possession est souvent supérieur du fait de la maintenance)
- Développement communautaire (mais l’essentiel des développeurs sont fournis par IBM, Sun et Novell)
- Et je ne parle pas de l’indépendance par rapport aux fournisseurs traditionnels, sujet plus souvent abordés sous l’ange ideologique plutôt que sous l’angle du “sourcing”.
Et dernière remarque les aspects “Try & Buy” et “Capitalisation des développements réalisés” pourraient tout aussi bien être intégrés par les éditeurs traditionnels.
Le débat tourne aux “pros & cons” de l’open source, mais ce qui est dit ici est inexact à mon sens, même si très classique de a réthorique des éditeurs traditionnels. Je me permets d’y répondre.
Le coût total de possession est le plus souvent très inférieur, c’est un fait, et c’est ce qui explique la percée de ces produits. Chez Smile nous déployons régulièrement de l’open source chez des grands comptes, et nos interlocuteurs nous le disent eux-mêmes, presque ingénuement: ça leur coûte énormément moins. Lorsqu’ils déploient par exemple eZ publish, un CMS open source, au lieu de Vignette, il y a un facteur 10 dans le coût total de possession. Certes le facteur n’est pas toujours 10, mais toujours important.
Le développement des projets open source n’est sûrement pas limité à IBM, Sun et Novell, c’est une étrange idée. Il faut bien sûr distinguer en la matière l’open source communautaire et l’open source d’éditeurs. Sur le second, qui est particulièrement dynamique ces dernières années, c’est l’éditeur - et non pas Novell - qui réalise le coeur du produit. Mais la tendance est à des produits qui ont un système d’extensions, de sorte qu’il y a une vraie cohabitation entre un noyau d’éditeur, entre les mains d’une équipe réduite, et des extensions - parfois par centaines - qui relèvent d’un développement réellement communautaire, à grande échelle.
Enfin, la moindre dépendance vis à vis d’un fournisseur, est également une évidence. Dans le cas du communautaire, ça va de soi. Dans le cas de l’open source d’éditeur, c’est vrai également car il est toujours sous la menace d’un fork. Pour un projet open source, le fork est à la fois une calamité et un garde-fous, qui protège le client: si l’éditeur tentait d’abuser de la captivité supposée du client, il s’exposerait à un fork (cf. Compiere ou Mambo). C’est très pragmatique tout cela, il n’y a rien d’idéologique.
Il y a un autre argument, employé parfois par les éditeurs, c’est le “buy vs. build”, qui voudrait que l’open source représente l’option “build”: on aurait du sur-mesure, mais à condition d’allouer beaucoup de jours.hommes et d’expertise. C’est un peu ridicule: il n’y a pas un utilisateur de MySql sur 10 000 qui a téléchargé les sources, sans parler d’y faire des modifications. Remplacer Oracle par MySql n’implique aucune expertise supplémentaire, ni aucune charge supplémentaire.