blog.bressure.net

Il est courant de faire l’éloge des outils open source dans l’atelier de production logicielle au travers de Maven ou Eclipse, mais est-ce par idéologie ou par raison économique ou bien par réel intérêt ? N’existe-t-il pas des cas où les solutions propriétaires constituent un alternative judicieuse ?

Nous entendons par atelier de production logiciel ou usine de production logiciel, l’ensemble des composants techniques et processus permettant de réaliser le logiciel. Cela va des outils de spécification, de modélisation aux outils de contrôle de la qualité en passant par les outils de développement. Il est indéniable que là où se battaient pléthore éditeurs comme Symantec ou Borland, ne subsiste aujourd’hui qu’un ou deux acteurs commerciaux tel que IBM tellement les solutions open source sont devenues  légions. Mais derrière cette percée de l’open source il se cache peut-être une disparité de l’offre.

Nous pouvons distinguer plusieurs domaines suivant l’usage de l’outil en commençant par la phase de conception et de spécification. Les AGL (Atelier de Génie Logiciel) sont un domaine où l’open source est très peu présent et ne peut rivaliser avec les offres payantes. Les fonctions de round-trip (aller-retour entre le code et le modèle) ainsi que la prise en charge de technologie d’implémentation (EJB, Webservice) sont l’apanache des solutions propriétaires payantes. Au contraire le domaine des outils de build et les IDE sont le terrain de jeux de l’open-source. Le système de build Ant est devenu le standard à l’intérieur de nombreux IDE, même propriétaires. Mais aujourd’hui ce système de build est vieillissant et sera supplanté par Maven dont les principaux IDE commencent à s’accommoder et il n’est pas nécessaire de s’appesentir sur la « part de marché » d’Eclipse dans les IDE. Enfin l’autre bout du spectre, celui du contrôle de la qualité au travers des outils d’intégration continue et de tests automatiques est mitigé. L’intégration continue est un concept avancé du génie logiciel que les éditeurs n’ont pas encore exploité laissant le champ libre à l’open source avec CruiseControl par exemple. A l’inverse le concept de test d’intégration est très industrialisé les éditeurs sont présents avec par exemple TestDirector.

Finalement c’est la partie centrale constituée du developpement et un peu de la phase suivante que l’open source occupe réellement dans l’atelier de production logiciel. La présence de brique propriétaire est donc encore nécessaire.

Cette situation va-t-elle évolué ? Pour les idéalistes de l’open source il serait de bon ton que les récents efforts pour intégrer des fonctionnalité UML directement aux IDE se poursuivent a l’instar de Netbeans . Ainsi la première phase de l’atelier sera conquise. Reste à savoir si le phase d’intégration évoluera vers une prise en charge complète par l’open source. Je tiens le pari que oui. L’histoire a montré que la valeur ajoutée de l’informatique s’est déplacée du matériel au logiciel et aujourd’hui elle se déplace du logiciel au service. Les éditeurs de logiciels non personnalisés que ce soit des logiciels outils ou pas sont bien concurrencés par l’open source comme le montre OpenOffice. Les éditeurs de logiciel devront faire du sur-mesure ou offrir du service d’expertise. Les raisons pour lesquels cette évolution me semble inéluctable est que la pression sur les coûts pousse à une rationalisation des dépenses. L’entreprise préfère utiliser chaque euro du budget du projet dans la création de fonctionnalité à valeur ajoutée donc la pression sur les coûts des outils fait tourner l’entreprise vers des solutions open-source gratuites. Cela réduit les revenus des éditeurs d’outils propriétaires qui pour assurer leur rentabilité ont tendance à réutiliser des solutions open-source maquillées dans leur produit.