Les fauxpen source sont parmi nous ou l’open source Canada Dry

closeCet article a été publié il y a 14 ans 7 mois 30 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Lors de mon dernier billet sur les solutions de CRM open source je me suis rendu à quel point beaucoup de solutions que je n’ai pas citées d’ailleurs affichaient clairement leur caractère open source sans pour autant disposer d’une licence réellement open source c’est-à-dire reconnue par l’OSI. Autre cas de figure ces éditeurs ne proposant qu’une partie de leur offre sous une licence open source.

Matt Asay, un pro-open source anglo-saxon notoire qui s’est pas mal fait remarquer ces derniers temps avec quelques billets parfois simplistes ou carrément à côté du sujet a quand même un peu repris ses esprits et semble constater que l’open source n’est parfois pas assez ouvert.

Voilà probablement une réflexion qui viendra apporter de l’eau au moulin des tenants de la branche dure des logiciels libres pour lesquels tout compromis est ruineux.

Une tendance à ce que j’appellerais l’attitude open source ou l’open source « Canada Dry » et pour laquelle Matt Asay reprend le terme anglais de fauxpen source.

Mais ce n’est pas tant cette dérive sur l’utilisation du terme open source qui pose réellement question, car elle est simple à identifier et correspond à un inévitable phénomène « d’opensource wahsing ». C’est plus l’apparition d’une dichotomie entre les éditeurs qui vont utiliser une licence open source, et pratiquer un mode de développement fermé par rapport à ceux qui ont une approche communautaire et ouverte. Bien entendu cela n’a aucun rapport avec la qualité du logiciel produit.

Parmi les exemples de fauxpen source Matt Asay désigne java ou encore Android. Concernant ce dernier des changements significatifs sont apparus sur le site du projet. Google a supprimé une section indiquant la liste des pré-requis pour devenir un membre de l’équipe principale de développement. Une attitude manquant d’ouverture,car elle ferme la porte aux développeurs « extérieurs » qui voudraient s’intégrer au coeur des évolutions de l’OS.

Je ne suis pas un spécialiste du développement open source, je ne saurais donc dire si ce genre de comportement sont légions ou spécifique à certains grands éditeurs open source. Ce qui par contre me semble plus sur, c’est qu’en procédant ainsi, l’éditeur va à l’encontre de l’intérêt de l’utilisateur. Or l’utilisateur ne doit-il pas être au centre de l’approche open source ? En fermant l’accès à des développeurs extérieurs, l’éditeur rend plus difficile une éventuelle reprise de son logiciel que ce soit par un fork ou encore en cas de disparition de l’éditeur. Au final, l’utilisateur est perdant.

La définition de l’open source fait clairement apparaître dans son paragraphe 5 :

5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.

En français pas de discriminations à l’encontre de qui que ce soit, personne ou groupe. Seulement, il ne s’agit ici que de la définition d’une licence pas celle de la façon dont on doit gérer un projet open source.

Faire de l’open source en mode « licence » est relativement facile alors que le faire en mode communautaire est une tout autre chose, car il faut être capable d’accepter les « intrus ».

Les éditeurs qui font le choix de l’open source pour la licence cherchent donc avant tout à profiter de l’effet de mode et à monétiser ce qui apparaît aujourd’hui comme un avantage concurrentiel par rapport au modèle propriétaire.

Encore une fois certains penseront que l’open source n’a que ce qu’elle mérite. Je resterais plus mesuré en m’interrogeant d’ailleurs si de telles pratiques n’existent pas aussi dans des projets libres. Mais encore une fois je dois bien avouer que je manque de matière à ce sujet.

Libre à vous de partager en commentaire vos expériences en ce domaine 😉

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

7 réponses

  1. Karl dit :

    > Matt Asay, un pro-open source anglo-saxon notoire qui s’est pas mal fait remarquer ces derniers temps avec quelques billets parfois simplistes ou carrément à côté du sujet a quand même un peu repris ses esprits

    C’est un peu vite dit, KVM fauxpen-source ? bullshit, KVM est un sous-projet du noyau Linux et n’est pas traité différemment du reste, doit-on en déduire que Linux est un fauxpen-source ?
    Quant à Java, la dynamique communautaire va bon train y compris pour les contributeurs non corporate.
    Certes, les sociétés qui sont derrière certains projets open source gardent une influence certaine, mais c’est oublier qu’elle reste souvent le contributeur majeur, Sun derrière Java, OOo, MySQL, etc …

    Reste des projets tels qu’Android qui ont une gouvernance opaque, mais ça n’empêche pas le fork. Une autre plateforme mobile libre LiMo a une gouvernance plus transparente, même LiMo reste peu connu du grand public malgré la sortie de nombreux mobiles.
    Si la gouvernance d’un projet doit entrer en compte dans le caractère open-source d’un projet, alors la GNU libc et son dictateur ultime risque bien de figurer dans la liste des fauxpen-source …

  2. Nick dit :

    Salut, je lis ton blog depuis quelques semaine, je trouve ca vien, continu ! Je me demandais c’est quoi le lien avec « Canada Dry » dans le titre?

  3. idoric dit :

    > « l’utilisateur ne doit-il pas être au centre de l’approche open source ? »

    Ça me fait penser à cette phrase lue sur le framablog : « La différence entre Open source/ Logiciel libre, Open source favorise l’éditeur, le logiciel libre favorise l’utilisateur ».
    Source : http://www.framablog.org/index.php/post/2009/11/03/google-microsoft (voir le commentaire de Vulcain)

    > « En fermant l’accès à des développeurs extérieurs, l’éditeur rend plus difficile une éventuelle reprise de son logiciel que ce soit par un fork ou encore en cas de disparition de l’éditeur »

    Je ne suis pas d’accord, je pense qu’au contraire, dans le cadre d’un logiciel libre, plus on se ferme aux patchs extérieurs, plus on abaisse le seuil de passage à l’acte de forker.

  4. Philippe dit :

    @Nick : Merci. Pour la référence à Canada Dry, c’est (c’était, je ne sais pas si ça se vend encore) une boisson sans alcool. Le slogan était : « Ça ressemble à l’alcool, c’est doré comme l’alcool… mais ce n’est pas de l’alcool ». Tu remplaces alcool par open source et voià 🙂
    @idoric : Pour le fork ,je comprend ce que tu veux dire, plus tu fermes et plus tu donnes envie à ceux qui en ont envie contribuer de forker. Tu as raison. Je voyais la fermeture plus comme un frein à la constitution d’une communauté « extérieure » et donc une diminution du risque de fork.

  5. Nick dit :

    aaah d’accord ! Je ne connaissais pas ce slogan. Je suis du Canada et je confirme que ça se vend encore =)

  1. 12 novembre 2009

    […] Pour un aller plus loin on pourra parcourir ce billet similaire de Philippe Scoffoni que je découvre à l’instant. Il y évoque « l’open source Canada Dry » et […]

  2. 12 novembre 2009

    […] Pour un aller plus loin on pourra parcourir ce billet similaire de Philippe Scoffoni que je découvre à l’instant. Il y évoque « l’open source Canada Dry » et […]