Même si un projet est open source, il ne répond pas nécessairement à la communauté, encore moins à un logiciel fiable sur lequel vous pouvez compter. Les projets varient: certains sont gérés par un ou deux développeurs en tant que passe-temps, d'autres rassemblent des développeurs rémunérés par de grandes entreprises, tandis que d'autres sont pilotés par une seule société mère. Chaque situation a ses propres problèmes et drames.
Nous adorons les logiciels open source - ne vous méprenez pas -, mais cela présente un certain nombre de défis. Voyons quelques-uns.
L'open source souffre souvent de retards et d'un rythme de développement glaciaire
Il suffit de regarder les tentatives d’Ubuntu pour le lancement de son ordinateur de bureau Unity 8 et de son serveur d’écran Mir, concrétisant ainsi sa vision de la «convergence». Cette nouvelle version du bureau Linux était supposée être stable il y a de nombreuses années et ne l’est toujours pas. Le projet a évolué à un rythme effréné, à tel point que Canonical a été battu à outrance par Microsoft, qui a annoncé sa propre vision, pilotée par le smartphone avant Windows 10, et qui l'a concrétisée. Canonical n’a toujours pas présenté sa vision promise depuis longtemps. Peut-être que ce sera stable dans quelques années.
Mozilla a également eu du mal à hiérarchiser ses priorités. Ils n’ont toujours pas fourni de fonctionnalités multi-processus et sandbox dans Firefox. Celles-ci sont essentielles pour assurer la sécurité du navigateur, empêcher les accidents de détruire tout le navigateur et mieux utiliser les processeurs multi-processus. Tous les autres principaux navigateurs ont livré ces fonctionnalités, y compris Internet Explorer, une version détestée. Mozilla a créé le projet “Electrolysis” pour ajouter ces fonctionnalités, mais l'a arrêté en 2011 parce que c'était trop difficile. Mozilla a ensuite dû le redémarrer en 2013. Cette fonctionnalité devrait arriver en 2017, ce qui est vraiment très tard. Pendant ce temps, Mozilla a perdu du temps à travailler sur Firefox OS, un système d’exploitation de smartphone défaillant.
Quand un projet fait appel à autant de développeurs bénévoles, il peut avoir du mal à trouver des personnes pour faire le dur travail qui n’est pas amusant à faire.
Le drame interne engendre des fourchettes, des fourchettes et davantage
Par exemple, lorsque GNOME 3 a été lancé et que beaucoup d’utilisateurs de GNOME 2 n’étaient pas satisfaits, il n’y avait pas de chemin évident à trouver immédiatement. Les développeurs devaient intégrer le code GNOME à d’autres projets tels que MATE et Cinnamon. Un environnement de bureau est devenu trois, et les ressources de développement sont plus dispersées entre les projets. En conséquence, il a fallu un certain temps à la communauté pour lancer ces nouveaux projets.
De même, la communauté OpenOffice n'était pas heureuse lorsque Oracle a acquis Sun. Oracle a même brièvement renommé StarOffice, sa suite bureautique propriétaire et non-open-source, en «Oracle Open Office». La communauté devait créer un nouveau fork, LibreOffice, basé sur le code OpenOffice. C’est devenu de fait la suite bureautique open source pour de nombreuses personnes, mais d’autres encore utilisent OpenOffice car ils ne sont pas conscients du meilleur fork et du drame qui l’entoure. OpenOffice a juste beaucoup de reconnaissance de nom construite.
Et, bien sûr, il y a CyanogenMod. Cyanogen Inc vient de fermer le contact sur les services en ligne de CyanogenMod - ce qui signifie qu’ils préféreraient tuer la ROM Android la plus populaire, plutôt que de la remettre à la communauté, au lieu de la forcer à créer un nouveau fork de CyanogenMod nommé LineageOS. Pourquoi Cyanogen ne se contente-t-il pas de confier le projet CyanogenMod à la communauté? La réponse semble être un drame interne (voyez-vous un motif ici?). Cyanogen était la société dont le PDG avait promis de «mettre une balle dans la tête de Google», après tout. Il a fini par mettre une balle dans la tête de CyanogenMod.
Tout cela finit par nuire aux utilisateurs de CyanogenMod, qui ont reçu très peu de préavis avant que les serveurs et les services de CyanogenMod ne soient fermés. Les téléphones continuent de fonctionner, mais des mises à jour pratiques et d’autres services partent en fumée presque du jour au lendemain. Les utilisateurs doivent simplement espérer que le projet LineageOS deviendra rapidement un remplaçant.
Tous les projets à source ouverte ne sont pas gérés par la communauté
CyanogenMod en est un bon exemple. Une fois que Cyanogen Inc. a été créée, ils ne se souciaient pas vraiment de CyanogenMod. Le nouvel objectif de Cyanogen est devenu de commercialiser la plate-forme Cyanogen Modular OS auprès des fabricants, en tirant parti de la reconnaissance du nom de CyanogenMod après avoir tué le projet. C’est peut-être là que se trouve l’argent.
Oracle ne se souciait jamais d'OpenOffice, mais souhaitait au départ utiliser son nom pour stimuler les ventes de sa suite bureautique exclusive StarOffice en lui attribuant le nom «Open Office». Il a ensuite fait don du projet à Apache après le départ de la plupart des développeurs bénévoles.
Google ne s’intéresse pas vraiment à Android en tant que projet open-source complet. C’est pourquoi de plus en plus de parties du «Projet Open Source Android» (ou «AOSP») sont laissées pour compte. Google souhaite garder Android ouvert afin que les fabricants puissent le personnaliser facilement, mais les applications open source telles que le clavier et le numéroteur deviennent de plus en plus obsolètes. Sur un appareil Android grand public, Google associe simplement son propre clavier source, composeur et autres applications. Google semble attaché à un noyau open source Android, mais pas à un système d’exploitation open source complet que les utilisateurs peuvent utiliser sans les logiciels et services de Google. Après tout, l’amélioration du projet Open Source Android ne fait qu’aider le SE Fire OS d’Amazon, concurrent des appareils Android de Google. Quel est le but de cela?
L'open source peut manquer de main-d'œuvre sérieuse, malgré son utilisation par des millions de personnes
Nous avons vu les résultats de cela avec la faille de sécurité de Heartbleed en 2014. Heartbleed a exploité une vulnérabilité dans OpenSSL. OpenSSL est une bibliothèque de chiffrement importante utilisée par de nombreuses entreprises de technologie de pointe et des centaines de milliers de serveurs Web. Mais il n'y avait qu'un employé à temps plein sans emploi extérieur et 2 000 $ par an en dons. Le projet a mobilisé des fonds supplémentaires provenant de contrats de support commercial et de conseil, mais un seul employé à temps plein semble extrêmement bas pour une infrastructure essentielle utilisée par des entreprises de plusieurs milliards de dollars, telles que Google et Facebook.
Heartbleed a attiré l'attention sur le fait que ce logiciel essentiel était sous-financé. Les grandes entreprises de technologie se sont engagées à réduire leurs dépenses chaque année pour financer le développement d'OpenSSL et d'autres projets importants dans le cadre de la «Core Infrastructure Initiative».
Cette histoire a un bon résultat, bien sûr, mais uniquement parce que toute l’attention a été attirée. Lorsque vous utilisez un projet open source pour activer votre infrastructure, il est facile de vous retrouver dépendant de celui-ci et de supposer que quelqu'un d'autre le gère suffisamment. Quel autre projet open source important est sous-financé de manière critique? Nous ne remarquerons peut-être pas qu’il y aura un autre gros problème.
