Gratuité, liberté, communauté : l'exemple Movable Type

Movable Type est un excellent système de création de blog, mais c'est aussi - et c'est moins attendu - un excellent exemple de l'évolution du logiciel. C'est aussi un magnifique exemple de ce qu'il ne faut pas faire avec un logiciel.

Au début, Movable Type était un logiciel propriétaire gratuit. Au fil des ans, alors qu'il connaissait un certain succès, il est devenu payant pour les utilisateurs intensifs (multi-auteurs et multi-sites).
Certains utilisateurs ont donc quitté le navire pour éviter de payer ce qui était à leur disposition gratuitement auparavant.

Au bout d'un moment, Movable Type est redevenu gratuit pour les particuliers puis, devant la déferlante de l'open source en général et du concurrent libre et gratuit Wordpress, il est devenu à son tour open source.
Pourtant, il semble bien qu'il soit plus facile de changer de licence que de changer ses habitudes de développement, et certains reprochent à  Six Apart d'avoir gardé le contrôle du produit sans rien déléguer à la communauté, et de se contenter de l'informer a posteriori des décisions prises à huis clos. C'est à la suite du licenciement d'un des principaux développeurs qu'a été annoncé un « fork » de Movable Type par la communauté, appelé Melody. Autrement dit, les principaux membres de la communauté font une copie du code de Movable Type et vont le faire évoluer indépendamment.

L'histoire de Movable Type est probablement exemplaire de la mutation de l'industrie du logiciel qui fait face à la prise de pouvoir des utilisateurs par le logiciel libre. Les atermoiements - très compréhensibles - de Six Apart peuvent démontrer qu'il y a des leçons à tirer de cette histoire.

Le passage de la gratuité au modèle payant a été très mal vécu par les utilisateurs, il est bien évidemment beaucoup plus facile de baisser les prix que de se mettre à faire payer quelque chose qui était jusqu'alors gratuit. C'est pourquoi Six Apart a du faire demi-tour face au l'hémorragie d'utilisateurs.

Lors du passage à l'open source, il ne s'agit pas simplement de changer la licence du code, mais il faut aussi changer d'approche. Il ne faut pas confondre la gratuité avec la liberté et la participation. Si la communauté ne peut pas assez participer, elle a les moyens de prendre le contrôle du logiciel, ou au moins d'une copie du logiciel. Le problème, c'est qu'on divise ainsi les utilisateurs en les forçant à faire un choix. On divise aussi les contributions potentielles entre les deux copies du projet. Bien souvent, le « fork » est coûteux pour le projet.
Il reste à utiliser avec parcimonie, car c'est bien souvent l'arme nucléaire pour un logiciel libre : à terme un des deux projets (soit l'original, soit le fork) risque de disparaître. Pourtant, c'est cette épée de Damoclès qui force les responsables d'un projet open source à servir les utilisateurs, d'où l'importance pour une entreprise qui passe à l'open source d'être « sincère » dans son approche, à tous les niveaux.
La réussite d'un tel passage est à ce prix.