Actualités

[18/05/2017] OpenShift, le nouveau livre blanc Smile

Smile publie aujourd'hui un livre blanc dédié à OpenShift, le PaaS open source orienté DevOps. A télécharger dès maintenant !

[15/05/2017] Smile décroche le label HappyAtWork 2017

Pour la 2ème année consécutive, Smile obtient le label HappyAtWork for Starters qui récompense les entreprises où il fait bon débuter sa carrière !

[28/04/2017] Smile annonce son plan strategique Open Arrow 2021 et accueille a son capital EURAZEO PME, nouvel actionnaire de reference qui succede a Keensight Capital

Smile, leader de l’intégration et l’infogérance de solutions open source, choisit son nouvel actionnaire majoritaire et s’offre de nouveaux moyens lui permettant le déploiement de son plan stratégique OPEN ARROW 2021 visant à créer un nouveau champion européen de l’IT de plus de 200M€ de chiff...

Toutes les actualités picto
       

Top consultation

Logo Smile : Open Source Solutions

Guillemet ouvrant introduction
à l'open source Guillemet fermant

Modèle de développement

Modèle de développement

Introduction


Halloween document

En 1998, un mémo interne a filtré de chez Microsoft. Mis sur la place publique, il est connu depuis sous le nom de Halloween Document I1.

Dans ce document, que Bill Gates en personne transmet à son board, un analyste étudie le mouvement open source et les dangers qu’il présente pour l’entreprise. Mais surtout, il reconnaît que :

  • Les projets open source ont atteint ou dépassé la qualité des offres propriétaires.
  • Les projets open source sont maintenant des projets de grande échelle et de grande complexité.
  • Les projets open source ont des atouts spécifiques impossibles à reproduire en termes de motivation et de nombre de participants.
  • Au delà des considérations éthiques, au delà de la guerre commerciale, c’est un choc pour Microsoft que de réaliser qu’un mode de développement radicalement différent peut marcher aussi bien, et parfois mieux.

C’est ainsi que le modèle de développement des grandes applications est l’un des aspects les plus intéressant du mouvement open source.

Cathedral and the Bazaar

Ce que Microsoft découvre en 1998 a déjà été analysé, et théorisé par Eric S. Raymond dans un essai qui reste une référence : The Cathedral and the Bazaar.

Il y oppose le modèle de développement traditionnel, le modèle cathédrale, et le modèle de développement initié avec Linux, le modèle bazar.

Dans son analyse, le modèle cathédrale n’est pas uniquement celui des logiciels propriétaires, il est également celui de grands projets open source, tels que GCC. Ce modèle s’appuie sur une équipe de développeurs compacte, travaillant sur des cycles de développement relativement longs, et diffusant les sources à l’issue de chaque phase.

Le modèle bazar, au contraire, fonctionne dans un apparent désordre, où interviennent un très grand nombre de développeurs dans un cycle de production et tests en continu.

C’est ce modèle bazar, si représentatif de l’open source, que nous explorons plus avant.

Les grands projets communautaires

Quand on parle de modèle de développement open source, on parle uniquement des projets communautaires, et généralement des plus grands d’entre eux, tels que Gnome, Mozilla, Apache Httpd, Eclipse, Linux. Les éditeurs qui diffusent leurs produits sous licence open source ont en général des modèles de développements traditionnels, et n’ont pas une volonté particulière d’étendre leur communauté de développeurs.

Les études montrent que le plus souvent un petit nombre de programmeurs réalisent la plus grosse part des développements. Sur un projet où 200 programmeurs auront participé, on trouvera typiquement que 10 d’entre eux ont écrit 50% du code.

Comme tous les projets informatiques, les projets open source ont besoin de quelques leaders visionnaires et architectes de haut vol, pour à la fois montrer le chemin et définir le découpage en modules.

Sur les plus grands projets, on constate souvent que les principaux développeurs ne sont pas des bénévoles, mais sont salariés d’entreprises IT. Leurs employeurs ont différentes raisons pour les laisser travailler sur ces projets, des raisons qui peuvent être :

  • De marketing : pouvoir faire état dans sa communication d’avoir un développeur « commiter », sur un projet phare équivaut à un important budget publicitaires.
  • De gouvernance : c’est le moyen d’avoir son mot à dire sur les orientations stratégiques du produit.
  • De socle technologique : ils font avancer plus dynamiquement un socle de produits dont ils sont directement utilisateurs, et dont dépend tout ou partie de leur business.
  • De maîtrise : la société sera compétente et légitime pour proposer du support sur le produit.
  • Voire également de motivation des collaborateurs, tant ceux qui participent que ceux qui pourraient le faire.

Une année de développement Linux

Le site LWN.net a publié une analyse très intéressante2 des contributions au noyau Linux, d’où il ressort que sur une année de développement (2.6.16 vers 2.6.20) :

  • 28 000 changements ajoutés,
  • par 1 961 développeurs différents,
  • remplaçant 1,26 millions de lignes par 2,01 millions de lignes de code nouveau,
  • le noyau a augmenté de 754 000 lignes

Au total :

  • Le développement est effectivement parallélisé à très large échelle.
  • Linus Torvalds n’est plus que l’auteur d’une très petite partie du code.
  • Une majorité des développeurs sont payés par leur employeur (Red Hat, IBM, Qlogic, Novell, Intel, …), qui fournissent environ les 2/3 du code.

Organisations, instances

Développeurs, commiters

Même si toute méthodologie cherche à rendre la qualité moins dépendante de la valeur individuelle des développeurs, il n’en demeure pas moins que l’expérience et le talent de chacun, mais aussi la motivation sont des paramètres fondamentaux.

Les projets open source, du moins les plus prestigieux d’entre eux, ont en général un avantage à cet égard. Ils attirent les meilleurs et les plus motivés des programmeurs, parce que faire partie des commiters Linux est la consécration suprême pour un développeur.

Les commiters sont les personnes autorisées à soumettre directement leurs contributions dans le référentiel des sources. Pour accéder au statut de commiter, il faut avoir proposé des contributions de qualité, et avoir gagné le respect de ses pairs. On est donc dans une logique de récompense du mérite et d’évaluation par ses pairs.

Gouvernance

Sur un projet, des choix sont à faire, des décisions sont à prendre. Qui décide et selon quel processus ?

D’une manière générale, les projets open source ont un fonctionnement relativement démocratique, dans le périmètre des commiters, avec tout de même une instance d’arbitrage, qui se réduit parfois au ‘gourou’ du projet.

Les fondations ont des institutions plus formalisées avec un board of director d’une dizaine de membres, élus annuellement par les commiters. Le board se réunit périodiquement (virtuellement), de l’ordre d’une fois par mois, et prend ses décisions, qui sont publiées dans un compte rendu public.

Certains projets, Gnome par exemple, ont formalisé les règles de cette démocratie. Dans d’autres, un noyau plus réduit, voire une personne unique, rend les arbitrages ultimes. Pour le noyau Linux, typiquement, c’est encore le rôle qui revient à Linus Torvalds. Mais dans tous les cas, la hiérarchie au sein du projet n’est fondée que sur la valeur et la reconnaissance des pairs.

Modèle de développement

Modèle de développement en cascade

Les modèles de développement traditionnels, que ce soit en cascade ou « cycle en V » ne conviennent pas aux projets communautaires.

modele_developpement_cascade

L’enchaînement linéaire de phases distinctes suppose une planification globale et une affectation des tâches centralisée. Par ailleurs, indépendamment même du contexte communautaire, ces modèles se prêtent mal aux très grands projets : ils ne permettent pas de bien gérer des besoins qui évoluent, et ils n’apportent pas suffisamment de retours d’expérience, de feedback, d’une étape vers la précédente.

Modularité impérative

Pour que quelques centaines de développeurs puissent travailler sans se marcher sur les pieds, il faut tracer des frontières propres et identifier des modules de dimension gérable par un développeur.

Si la bonne modularité, c’est à dire le découpage d’un grand projet en petites entités élémentaires, est un des principes élémentaires du génie logiciel, dans les grands projets open source cela devient une exigence vitale. La logique du « diviser pour régner » est incontournable.

modele_developpement-modularite_imperative

Le principe est donc de découper le système dans son ensemble en sous-systèmes dont les interfaces sont parfaitement définies, de sorte que chaque sous-système peut évoluer dans son développement indépendamment des autres, du moment qu’il respecte les interfaces convenues.

A l’intérieur d’un même sous-système, le découpage se poursuit, au niveau des classes, objets, fonctions.

Développement itératif

Le modèle de développement communautaire prédominant est appelé itératif, ou encore « en spirale ». Ses principes fondamentaux sont :

  • d’une part un découpage en modules qui suivent chacun leur propre cycle de développement,
  • d’autre part l’itération de cycles courts répétés (spécifications, développement, intégration) de manière indépendante sur chacun des modules.

modele_developpement-developpement_iteratif_1.

Et le tout dans le contexte général de l’intégration continue, qui permet de mesurer l’avancement, et de maîtriser les régressions, tout particulièrement dans les incompatibilités qui pourraient apparaître entre les modules.

Le modèle en spirale a également des aspects qu’on pourrait appeler « darwiniens », c’est à dire qu’à tout instant un développeur peut donner naissance à une version nouvelle d’un module, qui pourra ou non remplacer la précédente selon qu’elle est considérée supérieure.

modele_developpement-developpement_iteratif_2

On obtient donc le fonctionnement général représenté sur la figure suivante, où chaque module suit son propre cycle en spirale.

Il faut souligner que ces modèles de développement ne sont pas propres à l’open source communautaire. Ils peuvent convenir à une variété de grands projets. Mais ils doivent beaucoup à l’expérience des projets open source.

Test et accès au code

La phase finale d’un cycle de développement est la stabilisation et les tests. On parle de version béta lorsque le programme est entre les mains d’un sous-ensemble d’utilisateurs finaux volontaires.

Les projets open source ont une claire supériorité dans la phase de tests, à deux égards. Tout d’abord par le nombre plus important de personnes intervenant dans cette phase, et leur plus grande motivation. Et deuxièmement par le libre accès aux sources, qui permettra une meilleure qualification des anomalies.

Les outils

Les grands projets open source ont fait progressé la méthodologie, mais ils ont aussi apporté énormément aux outils qui l’accompagnent.

Environnement intégré

Pendant longtemps, les outils de développement de l’open source étaient un peu rustiques. Sophistiqués au plan technique, mais peu travaillés au plan ergonomique.

Les choses ont changé toutefois, et comme on l’a vu plus haut, la plateforme Eclipse en est la meilleure illustration. Initialement plutôt orientée vers le développement Java, elle se prête aujourd’hui à tous les environnements, et son exceptionnelle modularité lui permet d’accueillir un nombre extraordinaire d’extensions. Même les équipes de développement qui ne sont pas spécifiquement orientées vers l’open source ont aujourd’hui adopté cette plateforme.

Gestion des sources

Les outils de gestion des sources tels que CVS ou SVN sont le fondement de tout développement communautaire. Ils permettent de gérer les ajouts simultanés de centaines de développeurs, en identifiant précisément chaque modification, son auteur, sa date et sa finalité, et permettent de revenir sur une modification.

L’usage de ces outils s’est aujourd’hui généralisé, mais les grands projets open source ne seraient tout simplement pas possibles autrement.

Outils de génération

Une autre famille d’outils, où excelle l’open source, est celle des outils de génération, qui permettent d’automatiser les opérations de génération d’un programme, en gérant les dépendances entre composants. Depuis le rustique make Unix, jusqu’à Ant, et plus récemment, la Rolls de la catégorie, Apache Maven.

Intégration continue

Les projets open source ont généralisé la pratique de l’intégration continue.

L’intégration continue consiste à générer et contrôler de manière quotidienne l’ensemble de l’application, afin d’identifier le plus en amont possible d’éventuelles régressions, erreurs ou incompatibilités entre modules.

On sait depuis longtemps que le coût de correction d’une anomalie croît de manière très forte avec le temps qui sépare son apparition dans le code de sa détection. L’intégration continue vise donc tout simplement à réduire ce temps au maximum : si au jour J un programmeur commite un changement comportant un bug, son erreur lui est signalée à J+1, et le coût de correction sera extrêmement faible.

L’intégration continue entre dans le cadre plus général du test-driven development, développement piloté par le test. Cette approche consiste à écrire les scénarios de test et mettre en place les outils associés, avant d’écrire les programmes. Les tests vont du niveau unitaire, jusqu’au niveau interfaces.

Les principaux outils d’intégration continue sont CruiseControl, et Continuum, qui est intégré à Maven.

Suivi des demandes et bugs

Moins sophistiqués, mais importants néanmoins, sont les outils de suivi des demandes et des anomalies, les « issues », avec en particulier le célèbre Mantis, mais aussi Bugzilla, associé au projet Mozilla.

Outils d’échanges

Enfin, les développeurs utilisent pratiquement tous les outils d’échange communautaires existants, au développement desquels ils ont souvent participé :

  • Mailing-lists automatique
  • Forums
  • Wiki, en particulier pour spécifications et documentations
  • Messagerie instantanée