Temps de lecture 5 min
Et si le plus grand danger qui guettait désormais le logiciel libre n’était pas exogène mais endogène ?
Si, comme le pensent certains, ce n’était plus le logiciel propriétaire qui menace, mais une dilution des valeurs et de la culture du logiciel libre dans une soupe open source de… confusion et d’opacité, au grand dam de l’utilisateur qui ne serait plus alors acteur potentiel d’une communauté ?
On aurait même inventé une expression pour caractériser ces logiciels aux processus de développement privés et fermés qui, et je caricature à dessein[1], finissent par n’avoir d’open source que la licence : les « fauxpen source ».
Personnellement j’aime beaucoup ce néologisme. Il a été inventé par Phil Marsosudiro le 2 mai 2009 au cours d’une soirée (arrosée ?) quelque part en Caroline du Nord. Comment le sais-je ? Parce que je me suis rendu sur le site, ou plutôt la page, fauxpensource.org pardi !
Et il est repris ici par Matt Asay[2] dont je ne partage pas forcément l’optimisme (et les contradictions) mais qui évoque une problématique dont nous n’avons pas fini d’entendre parler.
Quand l’open source ne l’est pas assez (open)
When open source isn’t (open enough)
Matt Asay – 10 novembre 2009 – CNET News (The Open Road)
(Traduction Framalang : Yonnel et Cheval boiteux)
Certains logiciels open source ne sont peut-être pas assez ouverts. Alors que « open source » fait référence à la licence sous-jacente au logiciel et à son adhésion à la définition de l’open source, on trouve de nombreux exemples de projets open source qui offrent une licence ouverte mais un processus de développement relativement fermé.
On a appelé cela « fauxpen source », ou pire encore, mais nous devons peut-être nous y habituer. Cela semble être la nouvelle norme du développement open source. Seules les fondations open source comme Eclipse, Apache Software Foundation et Mozilla semblent en mesure d’y échapper totalement.
Java est souvent cité comme exemple emblématique de « fauxpen source ». Lundi, le directeur technique de SAP, Vishal Sikka, a appelé de ses vœux un processus plus ouvert pour le développement de Java, mettant en avant que Sun exerce un contrôle trop strict sur le développement de Java. C’est un reproche qui mine la communauté Java depuis des années.
Et Java n’est pas le seul. Si Google s’attire les compliments pour ses investissements dans l’open source, certains n’hésitent pas à prétendre que Google garde une communauté Android fermée. Le même genre de plaintes a vu le jour à propos de la gestion de Chrome et de Chrome OS.
Même Red Hat, la quintessence des entreprises open source, est d’abord connue pour ce qu’elle distribue, pas pour ce qu’elle développe. Red Hat, bien sûr, travaille aux côtés d’IBM et d’autres développeurs salariés ou indépendants à l’écriture du noyau Linux, et publie scrupuleusement ses logciels sous licences open source. Mais lorsqu’il s’agit du développement de sa distribution Red Hat Enterprise Linux, de son middleware JBoss ou d’autres technologies (par ex. KVM), bonne chance si vous voulez trouver des contributions externes significatives.
MySQL ? C’est grosso modo la même chose. L’entreprise (maintenant Sun Microsystems) fait virtuellement tous ses développements en interne, ce qui est vrai pour chaque entreprise privée open source qui me vient en tête. C’est une des raisons pour lesquelles Richard Stallman n’a pas à rougir de s’inquiéter de l’avenir de MySQL, même si c’est sa licence GPL préférée qui est utilisée.
La source est peut-être open, mais le processus pas nécessairement.
Il y a de très bonnes raisons pour que Google, Red Hat, MySQL et d’autres agissent de la sorte sur leurs efforts de développement open source. Ils sont responsables, fiscalement et légalement, devant leurs clients, et doivent être en capacité de garantir qualité et sécurité. On peut comprendre qu’ils exercent un certain contrôle pour s’assurer que les produits qu’ils distribuent protègent l’intégrité de leur marque.
Toutefois ceci témoigne d’un réel fossé entre « l’open source » en tant que licence et « l’open source » en tant que mode de développement et de distribution de logiciels complètement transparent. Le premier modèle est simple à mettre en place, le second beaucoup moins et demande une réelle volonté de la part de l’éditeur.
Les entreprises qui semblent mieux réussir sont celles qui ne comptent pas sur un retour sur investissement direct avec les logiciels libres. En d’autres termes, si vous ne vendez pas de l’open source, il est plus facile d’être ouvert. Doc Searls exprime cela de manière tout à fait pertinente quand il dit que « vous gagnez de l’argent grâce à (l’open source), pas de l’open source ».
Les exemples ne manquent pas. IBM en est un, Google également, bien que je sois d’accord avec ceux qui le critiquent car il peut assurément mieux faire. On peut également citer Facebook, Oracle et quelques autres.
À l’avenir, je pense que nous allons voir cette « fauxpen source » décliner, les entreprises séparant clairement leurs efforts dans l’open source et leurs modèles de ventes. L’open source peut offrir une plate-forme directe de gains, mais ce n’est pas le meilleur moyen pour véritablement générer de l’argent. Pas pour la plupart des entreprises en tout cas.
Eric Lafarge
Excellent ça "Fauxpen Source" !!! A mon avis c’est un terme qui est là pour durer ! Un fake open source en quelque sorte.
@aKa : J’en vois une grosse de contradiction dans l’article, c’est que Google est cité des deux côtés de la barrière. Quand Google OS va sortir, tout ce qui est évoqué là va exploser au grand jour. Et la "communauté du libre" se coupera en deux, entre les pros et les antis Google OS.
Winael
Si la distribution RedHat semble ne pas respecter l’esprit OpenSource dans son développement, ce n’est pas le cas par exemple d’Ubuntu. En utilisant Launchpad (qui a été récemment libéré) tous les développeurs du monde entier peuvent aider au développement d’Ubuntu et ce de manière totalement transparente. C’est aussi ce que j’aime dans cette distribution et qui explique pourquoi elle est de plus en plus populaire. De la transparence on vous dit
mlk
Mysql, RedHat, respectent beaucoup mieux "l’esprit" libre que certaines sociétés se proclamant open source mais qui ne livrent jamais de versions stables de leur binaires et qui ont des repositorys de sources fermés sans TAGS, branches accessibles. Je pense a ExtJS, Alfresco et autres…
Ce modèle à la Alfresco semble de développer fortement.
Sylvain
Les exemple sont nombreux.
Je pense particulièrement aux outils ‘libres’ mis en avant par les SSII comme Bull ou Cap Gemini avec leur forges de développement ou les outils comme Bonita et même Salome TMF.
Tous ces outils sont effectivement en source ouvert, mais tellement sponsorisés par les sociétés qui les vendent qu’il est difficile de s’impliquer dans leur développement.
Par exemple, depuis le départ du principal architecte de Bonita (pour lancer Bonita Soft), Bull facture de façon indépendante ses prestations sur ce moteur de workflow. Résultat, les clients doivent passer au bassinet, changer de prestataire ou, opter pour une solution alternative… propriétaire dans notre cas précis.
J’ai souvent l’impression que le terme ‘logiciel libre’ ou ‘en source libre’ est trop souvent utilisé pour mettre sur la table des solutions maison qui ne sont en fait pas de "vrais" projets communautaires. Car c’est bien l’aspect communautaire qui donne à un projet sa nature "open source".
Valentin Villenave
Je ne suis pas sûr que M. Asay soit la plus indiquée des références pour aborder ce sujet. Sa position est fréquemment sujette à débat (comme en témoigne sa participation à la récente et très controversée opération "Fake Linus Torvalds" de la Linux Foundation).
Pour un autre son de cloche, on peut par exemple se référer à ce récent billet de Bradley M. Kuhn, de la FSF, qui démonte très soigneusement la dernière idéologie à la mode, j’ai nommé l’"open core" : http://www.ebb.org/bkuhn/blog/2009/…
pessimiste combatif
C’est un grand classique historique de l’apparition d’un mouvement novateur tellement novateur qu’il demeure incompris du reste de la population. Alors on l’adapte pour qu’il puisse faire son trou à partir des structures existantes, au risque de perdre quelque chose en route (ici c’est la liberté).
Si les choses sont bien menées alors il n’y a pas opposition mais complémentarité. Dans le cas contraire l’histoire retiendra que le fauxopen source aura catalysé puis détruit le logiciel libre.
Un peu comme le marketing qui aura tué l’esprit de mai 68.
dagon
@mlk
svn co svn://svn.alfresco.com/alfresco/HEAD
ceci étant dit je je pense que l’open source a toujours été une méritocratie et pour avoir le droit au "comit" il faut faire ses preuves.
ce problème est inhérent au gestionnaire de source utilisé(SVN,CVS) ce problème a été en partie résolu avec l’apparition des gestionnaires de sources distribuée(GIT,Mercurial)
qui démocratise un peu plus la démarche de la contribution.
je pense que le réel danger plus que fauxpensource c’est la perte de la liberté sur le chemin de l’open source.
philippe
En gros, cet article résume la différence entre « logiciel Libre » et « Open Source ».
Il illustre en quoi dire « libre » est important
joan
@philippe: Pas vraiment d’accord. L’article met d’un côté le libre et l’open source développé de façon entièrement ouverte, et de l’autre le libre et l’open source développé de façon protectrice.
C’est aussi là que le libre a une dimension sociale et politique. Les projets les plus ouverts sont ceux qui sont développés sur un mode autogestionnaire, où tout le monde à son mot à dire et peut peser dans la balance autant que les autres.
Le mode de décision n’est plus le diktat du patron, ni même la démocratie mais le consensus à chaque fois que c’est possible.
On retrouve les modes d’organisations suggérés par les libertaires. Même le mode d’organisation dit du "Benevolent Dictator" correspond à ça car son autorité est légitimée par les contributeurs et elle peut être remise en question à tout moment (forkabilité).
Il faut absolument voir la vidéo "Open Source – What’s in it for me"¹, qui va plus loin que la dichotomie vrai / faux et qui détaille les divers degrés d’ouverture possibles pour un projet qui serait à l’initiative d’une entreprise privée.
Que ce soit au niveau des prise de décision, au niveau de la façon dont le code est accessible (archives zip ou repository public), de la façon dont les nouveaux arrivants doivent faire leurs preuves, (les nouveaux salariés de la boîte qui chapeauterait le développement n’ayant pas a priori a être privilégiés par rapport aux bénévoles à l’autre bout du monde.), etc.
¹ http://www.youtube.com/watch?v=ZtYJ…
(J’espère que ça fonctionne on m’a coupé Youtube à la boîte…)
mlk
@dagon
oui le HEAD de alfresco est dispo mais pas les TAGS des releases ni les branches, ceci est reservé aux versions entreprises. l’effet pervers est que on ne sait jamais si le HEAD est stable et buildable et surtout a quelle revision pourrait correspondre une release de maintenances !
Pour ExtJS, le SVN et les relaeses de maintenance sont accessible a ceux qui payent, Une version est publique (avec le source) de temps en temps mais toujours buggée. il faut donc attendre la release publique suivante qui integrera l’ensemble des corrections (mais aussi de nouveaux bugs qui eux seront corrigés dans des releases de maintenance payantes)….
J’ai toujours du mal avec ce genre de produits qui profitent d’une communauté le temps de croitre et qui changent de modèle en cours de route…
lawl
Il y a plein de projet libre qui n’ont pas d’entreprise derrière elle et qui on un développement fermé. Je pense par exemple à Nagios (cela un peu évolué mais reste fermé)
Cela n’a rien à voir avec l’esprit "libre" cela n’enlève rien au liberté que la GPL donne.
Faire du libre ce n’est pas accepter tout le monde (ou n’importe qui c’est selon) comme contributeur…
C’est bien plus compliquer que cela et tous ceux qui ont déjà essayer de soumettre un patch ou tout simplement de s’intéressé à la structure d’un projet libre le savent….
Quand à Ubuntu qui ouvre son développement, c’est la porte ouverte au Troll…combien de contrib de redhat upstream et combien Ubuntu ?
Le poilu est laché !
Grunt
mh.. Et c’est quoi, le problème?
Le "fauxpen source" respecte-t-il l’utilisateur et ses quatre libertés?
Olivier
@Grunt : Légalement oui si le fauxpen source adopte une licence libre. Mais il y a la loi et l’esprit de la loi. Le logiciel libre et sa culture sont quelque chose de trop sérieux pour être confiés aux seuls juristes.
Grunt
@Olivier: je ne vois pas ce que les juristes font là dedans.
L’esprit du libre c’est "je veux pouvoir faire ce que je veux du logiciel, l’étudier et le modifier, en distribuer des copies et distribuer mes versions modifiées."
Le fait que beaucoup de logiciels libres se développent de façon coopérative n’est qu’une des conséquences positives de ces libertés.
Mais je ne vois pas en quoi on porte atteinte à la liberté d’un utilisateur en lui disant "Non, ton truc on n’en veut pas dans notre logiciel." Ça ne l’empêche pas de le distribuer de son côté.
Shnoulle
Comme quelqu’un à cité ubu… , rappelons que le processus de développement chez redhat s’appuie aussi sur une communauté via Fedora.
Alors bien sur , RedHat contrôle totalement les RH, par contre il partcipe énormément à d’autres p^rojet libre, rien que sur http://www.packagekit.org/pk-author… on trouve des contributeurs de chez Redhat, Fedora , mais aussi Mandriva ou opensuse. Tiens , aucun de chez ubuntu ?
Perso, je suis dècus quand une appli arrive chez LaunchPad, elle n’est orientée Ubuntu et pas multi distrib.
Non mais 😉
Pierre Carrier
Bonjour,
Avertissement : je travaille chez Red Hat, Inc.
1) « On aurait même inventé une expression pour caractériser ces logiciels aux processus de développement privés et fermés qui, et je caricature à dessein[1], finissent par n’avoir d’open source que la licence : les « fauxpen source ». ». Non. Suivez le lien que vous nous fournissez, et vous verrez la définition « A description of software that claims to be open source, but lacks the full freedoms required by the Open Source Definition. ».
Fauxpen source désigne des logiciels sous une licence/des conditions d’utilisation qui NE sont PAS open source mais clament l’être. Il n’y a pas de procès d’intention ou d’analyse de la communauté en jeu, il s’agit bien purement d’une question de licence.
2) « Red Hat, bien sûr, […] publie scrupuleusement ses logciels sous licences open source. Mais lorsqu’il s’agit du développement de sa distribution Red Hat Enterprise Linux, […] KVM), bonne chance si vous voulez trouver des contributions externes significatives. »
Red Hat Enterprise Linux est une distribution. L’immense majorité des logiciels en faisant partie sont communs avec la majorité des autres grandes distributions, et sort de projets « upstream » indépendant de Red Hat ; le reste sort également de projets upstream, rattachés directement ou non à Fedora. Le développement est ouvert aux contributeurs extérieurs.