insideIT.fr : le blog des architectes IT de SFEIR

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.