Je viens de rentrer de mes premières vacances de snowboard en huit ans. Après une si longue période hors des pistes, je ne savais vraiment pas si je devais réapprendre complètement - si je trouvais toute cette épreuve trop terrifiante ou si je pouvais simplement sauter sur mon tableau et faire semblant de ces huit ans. années avaient été huit jours. Au final, c'est ce dernier.

Le premier matin, j'ai réussi à m'attacher, à diriger la planche vers le bas de la colline et à atteindre le bas de la pente sans me disloquer le genou gauche ni pousser les skieurs errants dans une crevasse. Il semble que s’il n’ya pas beaucoup de similitudes entre faire du vélo et descendre une pente glacée sur une planche, ni l’autre ne vous laissera oublier comment rouler après avoir appris..

En conséquence, j'ai passé une semaine fantastique à explorer un nouveau territoire et à rétablir mon ancienne confiance. Maintenant, je pense qu’il existe un lien entre les logiciels open source et la façon dont vous apprenez à faire de la planche à neige..

C'est la vieille idée que sans prendre de risques, vous ne développez pas. Et je ne parle pas de gros risques comme sauter d'une falaise ou aller droit au bas de la piste. Je veux dire des petits risques considérés, comme aller un peu plus vite, se resserrer un peu ou passer à une piste inconnue.

Même si vous tombez, ce que vous ferez, vous devrez dépasser vos limites actuelles pour mieux comprendre comment vous améliorer. Ce n'est qu'après avoir monté plus vite, plus raide ou plus difficile que vous pourrez retourner sur ces vieilles pistes avec une confiance, des capacités et une perspicacité renouvelées. C'est ainsi que nous nous améliorons tous, et cela n'arrive pas si vous ne vous poussez pas.

Malgré le manque de montagnes et de raclette, je pense que Linux et les logiciels libres ressemblent un peu au snowboard. C’est le cycle de l’aventure, des échecs et des améliorations qui est au cœur de leur succès. Sortir tôt, sortir est souvent une idée risquée, popularisée par Eric S Raymond dans son essai à lire absolument, La cathédrale et le bazar.

Expérimentation la clé

Il existe de nombreuses façons d’interpréter cela, du lancement rapide des versions du noyau au cycle de déploiement de distributions comme Arch, mais à son niveau le plus bas, c’est une idée qui devrait pousser les milliers de projets qui ont déjà gravi leur première pente - résolution de problèmes un problème spécifique - sur la publication d'au moins une version.

Je peux penser à deux de ces projets. L'un était éditeur d'un synthétiseur difficile à programmer (un Alesis Micron), l'autre était un contrôleur de logiciel. J'ai probablement passé des centaines d'heures dessus, mais comme aucun des deux n'est propre à être utilisé (et ne le sera probablement jamais parce que je suis passé à autre chose), ils ne verront jamais la lumière du jour..

Ils ne seront jamais partagés car ils sont à peine fonctionnels, contiennent des raccourcis de codage terribles et n'ont aucun support. Si j'avais publié le code dès que je pensais que le projet était suffisamment mûr pour pouvoir être compilé facilement, quelle que soit sa qualité, il y aurait plus d'une chance que l'un de ces projets, ou du moins une partie de celui-ci, continue d'exister..

Le décodage des données binaires pour le synthétiseur a pris beaucoup de temps, par exemple, et cette information éviterait à un autre développeur de faire exactement la même chose..

Les désavantages

Mais cette approche présente deux inconvénients majeurs. Le premier, et le plus problématique, est que, faute de contrôle de la qualité, la plupart des projets vont s’ajouter au bruit de fond interminable d’Internet. Vous n'avez qu'à regarder les centaines de milliers de projets qui traînent sur des sites comme SourceForge.net pour voir ce que je veux dire..

Le deuxième problème est que, en publiant une telle publication, vous vous exposez à la critique et au ridicule, car elle ne correspondra jamais à la norme que vous vous fixeriez normalement. Cela signifie qu'il est important que les utilisateurs et les développeurs reconnaissent la différence entre une version finale et une version "en cours". C'est un problème subtil pour les logiciels libres, car il y a tellement de façons différentes de s'attaquer au même problème..

La version en cours du noyau peut être téléchargée à tout moment depuis un référentiel Git, par exemple, tandis que les versions entre les versions 1.0 et 2.6.x utilisaient des versions mineures avec un nombre impair pour indiquer une étape de développement. Cette méthode a été remplacée lorsque Linux a adopté une approche plus «release souvent», annulant ainsi le besoin de versions de développement dans leur ensemble..

Mais cette stratégie de publication ne fonctionne que dans la mesure où beaucoup de personnes travaillent quotidiennement avec le noyau. Cela ne fonctionne pas pour les petits projets, ni même certains grands projets comme Gnome. La version majeure de Gnome 3.0, comme KDE 4 avant elle, a amené la communauté dans une direction à laquelle elle n'était pas préparée, donnant l'impression qu'une mise à jour majeure était une idée en cours de développement très risquée..

Pourtant, malgré ces difficultés et les problèmes qu’ils posent, le logiciel libre a finalement prouvé que la méthodologie permettant de diffuser vos idées en public, de prendre des risques et de sortir des pistes est la meilleure façon d’innover. C'est quelque chose que les entreprises propriétaires ne peuvent pas concurrencer. Après tout, si vous craigniez de vous faire mal, de ressembler à un idiot ou de quitter votre zone de confort, vous ne surferiez jamais non plus..