Laurent HAUSERMANN

Wired publie sur le blog MonkeyBits une article fort intéressant sur Asa Dotzler, qui est responsable Marketing au sein de la Mozilla Fundation.

Avant toute chose, il faut rappeler l'historique de ce cher Firefox : les années 90 avaient vu la mort du pionnier des navigateurs web, Netscape Navigator. AOL avait alors acheté les restes de la société Netscape, fondée par Marc Andreessen. L'opérateur voulait étendre son business model orienté valeur ajoutée, en transformant Netscape Communicator (successeur de Navigator) en netscape.com, logiciel hybride mélangeant publicité et fonctionnalité,  transformant un logiciel déjà complexe en une brochure publicitaire.

Asa Dotzler souligne ainsi cette dégénérescence : 

 We had a drop-down menu attached to the print button on the tool bar with one item in it. You'd click on it and see an option called "Print Plus." When you clicked on that, you'd be taken to HP's website where you could buy printer supplies. HP literally bought a button on the toolbar!

 

Une partie de l'équipe de développement a donc décidé de lancer une autre version du logiciel, Mozilla 1.0, proche des standards, fournissant toutes les fonctions qu'attendaient les geeks de l'époque : intégration email / navigateur, logiciel IRC, lecteur de news ; bref une masse de fonctions qui auraient du connaître un fort succès. La deception fut aussi grande que les attentes : 1% de part de marché.

C'est dans ce contexte que Firefox est né : un soft complexe, intégrant des dizaines de fonctions, ne parvenait pas à lutter contre Internet Explorer ; il fallait donc prendre le contrepied de Mozilla et construire un logiciel proche des utilisateurs :

We would ask ourselves, "Do we think 90% of the people need this feature? Is this something everyone I know really needs?" If not, we would leave it out.

 

L'origine de Firefox explique son succès d'aujourd'hui : un logiciel facile d'accès, ergonomique (usable), reposant sur des standards et répondant aux attentes de ses usagers.

Tout cela semble être une évidence, mais il est très délicat de tenir ce cap lorsqu'on travaille en équipe et où chaque membre (développement, QA, formation, marketing, vente) voudrait voir évoluer le soft dans une direction qui lui semble propre.

Ainsi, ce qui est remarquable dans l'article, c'est qu'Asa Dotzler va à l'encontre de la croyance populaire qui voudrait que les projets OpenSource sont gérés de façon démocratique (soixante-huitarde, dirait-on en cette période anniversaire). En effet, on pourrait  croire qu'il suffirait de faire voter les usagers d'un logiciel pour déterminer la liste des évolutions futures. Une roadmap serait alors la synthèse de ses sondages d'opinion. 

C'est oublier que nous avons tous tendance à généraliser nos besoins et penser que nous détenons une certaine vérité.

C'est oublier aussi que les mouvements OpenSource sont pour la plupart gouvernés par la meritocracie, comme le souligne Asa Dotzler: 

But this is not design by democracy. We've never been a democracy at Mozilla. We're a meritocratic hierarchy. You don't get a voice by being a human, you get a voice by establishing a reputation for doing good deeds over time.

Et aussi par des "dictateurs bienveillants" sur le modèle de Linus Torvalds, le créateur du noyau Linux ou de Guido van Rossum, le créateur du langage Python. Citiziendium nous offre une bonne définition : 

Benevolent Dictator for Life (BDFL) is an informal title, sometimes used humorously, given to an individual in an open source development community, who is usually also the founder or originator of the project.

Ces personnes vont permettre qu'une stratégie à long terme soit mise en oeuvre sur le projet et ils vont garantir une cohérence dans la construction du logiciel, dans son cycle de vie et dans ses fonctions. 

Grâce à ce système de gouvernance,  les meilleurs logiciels open source conservent leur intégrité et répondent aux besoins (aux vrais besoins) de leur client.

En entreprise, la méritocracie existe peu et la démocratie encore moins. Néanmoins, il subsite le besoin impératif de garder le contact avec le client, l'usager du logiciel. Les méthodes agiles, comme Scrum, permette de créer la relation privilégiée entre l'équipe de développement et le client. 

Mais cela sera le sujet d'un autre post ! D'ici là, merci pour vos commentaires !