Erich fait un retour
d'expérience sur ses 7 années de développement de Eclipse.
La première étape du projet était de créer un outil. Le process de
développement à ce moment là était clos, voire secret. L'objectif final était
bien d'avoir un produit en opensource, mais pour le lancement l'équipe voulait
avoir quelque chose à lancer.
Durant cette étape il a été décidé que les classes et les jar n'étaient pas
suffisant pour créer un produit extensible. La notion de plugin est arrivée
assez rapidement. Pour Erich, un plugin n'est ni plus ni moins qu'un composant.
Ce composant est décrit à travers un manifest qui représente la partie visible
de l'iceberg.
La notion d'API est au cœur d'Eclipse. Durant cette phase l'équipe a
beaucoup travaillé sur cet aspect. Car une fois l'API d'un composant publiée,
il est impossible de revenir dessus. Erich conseille d'avoir au départ des API
minimum. Il est toujours possible de rajouter des fonctionnalités dans les
versions suivantes.
Cette période était très stressante, car tant que logiciel "secret" n'est
pas livré, il n'existe pas. C'était aussi assez frustrant pour l'équipe de
développement.
La première release a été un grand soulagement. Mais là, commençait un
nouveau challenge. D'abord il avait fallu convaincre en interne de l'intérêt
d'avoir un produit en opensource. Ensuite, il fallait transformer cette
ambition d'opensource en succès : une communauté active autour d'Eclipse devait
naitre. Par ailleurs, il fallait aussi accepter de coder en public, de discuter
en public, de construire le produit en public. Autant de choses qui ne sont pas
forcément évidentes au départ.
Une fois le projet transformé en un véritable projet opensource.
D'autres considérations sont entrées en ligne de compte :
- amener un rythme, pas trop court, pas trop long (l'année a été
choisie),
- choisir une date de release, juin permet à l'équipe de partir en vacances
tranquille,
- convaincre tout le monde qu'il est important de respecter le rythme,
- garantir la stabilité des API
- garder les utilisateurs heureux,
- avoir des développeurs qui continuent à aimer travailler sur ce projet :
intégration des pratiques de développement des méthodes agiles : réunion du
matin, chaque équipe s'auto-organise, rétrospective, démo,...
Fort de cette expérience, Erich a adopté cette manière de développer des
logiciels. Il travaille maintenant sur un nouveau projet Jazz. Le mode de
production de ce produit, qui n'est pas opensource respecte les principes de
création de logiciel opensource : code téléchargeable, mailing list public,
Milestones,...
Au final, Erich a fait un rapide sondage, 70% des personnes dans la salle
utilise Eclipse. Pas mal ! Nous avons aussi appris que Eclipse est construit
par une équipe distribuée de 60 développeurs.
Une belle histoire.
Développer ne relève pas de
l'exploit, mais développer bien, un peu plus... Les nouvelles méthodes de
développement imposent un rythme soutenu, une polyvalence permettant
d'intervenir sur des portions de code appartenant à un autre membre de
l'équipe, etc. Bref, plein de bonnes raisons qui encouragent de maintenir un
code propre, suivant des règles communes entre membres de l'équipe, testé de la
façon la plus exhaustive possible... On pourrait croire que seul un monde
parfait peut permettre d'atteindre cet objectif, et bien pas forcément : il
existe différents outils que vous connaissez sûrement, peut être que vous
utilisez aussi, qui aident à atteindre cet objectif. Ces outils ne doivent pas
être une mallette de secours quand tout commence à aller mal, mais le fil rouge
au long du cycle de vie du projet qui sera le gage de la performance de
l'équipe.
J'ai assisté récemment à la migration d'un
projet de Maven1 à 
