Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
Cet article est ma traduction en français d’un billet que Mark Shuttleworth à publié en anglais sur son blog le 9 janvier 2007.

J’ai complètement oublié de parler de la version 1.0 de Bzr l’année dernière, mais c’était une excellente mouture et au dire de tous, très bien reçue. Félicitations à la communauté Bazaar pour leur dynamisme ! Je crois que la version 1.1 est maintenant stabilisée, et c’est génial de voir qu’ils vont continuer à sortir régulièrement de nouvelles versions.

J’ai récemment observé une augmentation du nombre de contributeurs à Bazaar, ce qui a généré de nombreuses branches, petites mais utiles, proposant des correctifs à divers bogues complexes, des systèmes d’exploitation et des intégrations à d’autres outils. Un des projets les plus intéressants qui suscite beaucoup d’attention est BzrEclipse, intégrant Bzr de manière naturelle dans l’environnement de développement logiciel Eclipse.

Je pense que les projets open source évoluent à partir d’une phase initiale pendant laquelle ils s’accordent mieux avec un petit groupe soudé de contributeurs qui pose les bases, pour arriver à un point où l’outil ou l’application est utilisable par une plus large audience. Ensuite, ils doivent passer d’un état « bien contrôlé » à une situation ouverte aux contributions de personnes qui souhaitent juste corriger un petit bogue ou ajouter un petite fonctionnalité. C’est une transition assez difficile, car les compétences sociales requisent pour faire avancer le projet sont assez différentes dans les deux cas. Il s’agit non seulement d’être doué pour la communication, mais il faut aussi avoir de bons outils pour gérer la base de code qui reçoit un flot des nouvelles petites contributions provenant de nouveaux contributeurs n’ayant pas fait leurs preuves.

Il semble que l’une des « bonnes pratiques » clé qui ait émergée est l’idée des architectures à greffons, qui permettent à de nouveaux développeurs d’apporter une extension, un greffon ou un complément au code de base sans avoir à apprendre trop de choses sur le fonctionnement interne du projet, ou avoir à participer à de trop nombreux processus lourds. J’aimerais généraliser cela et dire qu’une bonne conception, avec des couches clairement définies et pragmatiques, permet à de nouveaux contributeurs de faire rapidement des contributions utiles au code de base, car les couches offrent des abstractions utiles en amont.

La décision de prendre en charge les compléments mutli plate-forme a vraiment été bénéfique pour Firefox. Je suis ravi d’entendre qu’OpenOffice va dans la même direction.

Bazaar est très bien architecturé. Il dispose non seulement d’un système de greffon bien conçu, mais il a aussi une architecture en couches très utile et pragmatique qui réserve les aspects intrinsèques complexes à ceux qui ont réellement besoin de les connaître. J’ai observé comment différentes équipes de contributeurs, ou des individus, ont introduits des formats on-disk complètement nouveaux avec des nouvelles caractéristiques de performance, de manière complètement orthogonale au reste du code. Donc si vous êtes intéressé par la performance de status et de diff, vous pouvez travailler sur l’implémentation d’un arbre d’états sans avoir à vous soucier du stockage de version à long terme ou des comparaisons d’historique de branche.

L’architecture en couches peut aussi poser des problèmes, lorsque les couches sont définies trop tôt et qu’elles ne reflètent pas la réalité pragmatique du code. Par exemple, on peut citer « l’échange de points de vues » entre les gens de chez ZFS et la communauté travaillant sur le système de fichiers de Linux, qui ont des opinions très différentes sur l’importance et les bénéfices de l’architecture en couches.

Quoi qu’il en soit, bravo aux gars de Bazaar pour l’imminente version 1.1 et pour l’adoption d’une architecture qui facilite l’implication des contributeurs.

Origine : Good architectural layering, and Bzr 1.1