Laurent HAUSERMANN

"Libérez cette nouvelle version", semble être l'injonction à la mode dans le monde de l'open source et du Logiciel en général.

J'évoquais déjà notre envie à tous de voir sortir plus souvent nos logiciels préférés. En effet, dans les temps qui cours, on ne peut pas rester plus de 6 mois sans apporter de nouvelles versions, de nouvelles fonctionnalités à ses utilisateurs, à ses clients.

Il est vrai que les usages en matière de gestion de cycle de vie sont extrêmement variables en fonction des entreprises et des projets open source majeurs. Ainsi, Microsoft explique en détail sa politique de gestion du cycle de vie de gestion du cycle de vie de ses produits (on notera un effort d'explication remarquable de la part de l'éditeur) et distribue de ses produits environ 5 ans. Suite à ces 5 années (une moyenne), le support se poursuit pour environ 2 années après la fin des ventes. On notera tout de même une accélération du cycle de vente car on passe d'un cycle sur 7/8 ans pour MSDOS 6 (!), à un cycle sur environ 5 ans pour Windows XP.

Les projets open source ont, quant à eux, des politiques de sortie de versions très diverses, allant du vieil adage "When it gets ready" (entendez, "quand ca sera prêt"), à des cycles plus stricts de 6 mois comme les projets Gnome, ou OpenBSD. Mais ces projets open source ressentent aussi la même pression de leurs utilisateurs et il est fort probable que la gestion des sorties, le rôle de Release Manager, devienne prépondérant au sein des communautés.
Ainsi, le projet Debian, qui doit renouveler son "Debian Project Leader"s'anime autour de la question de la gestion des release.

"Libérez !", sembleraient donc dire les usagers des logiciels et les producteurs de logiciels de s'adapter en conséquence...

Mais plein de contradictions, nous cherchons des logiciels qui durent (l'affaire Bouygtel nous l'avait rappelé).

J'en veux pour preuve l'émotion que suscite l'arrêt par Microsoft du support gratuit et du développement de VB.6.
Certains vont même jusqu'à lancer des pétitions à Microsoft pour que la société éditrice continue à faire vivre le langage. La grogne des développeurs est compréhensible : après avoir investi tant d'années dans des développements VBA et VB6, pourquoi devraient-il continuer à investir dans la technologie VB.NET pour refaire ce qu'il ont déja ?.
Joel Spolsky, enfonce le clou :

But here's the thing. If you have a million line code base that's mission critical, as many companies do, and VB suddenly changes, as it did, you have a choice: keep using VB 6 or spend a lot of time (=money) upgrading to VB.NET. If you keep using VB 6, eventually new things will come out that will not be supported from VB 6, and you'll be stuck using the yucky old VB 6 IDE until the end of time. Already most of the big component vendors are doing all the new components as .NET components, not OCXes.

If you spend the money to upgrade to VB.NET, well, you just spent a lot of money to stand still. And companies don't like to spend a lot of money to stand still, so while you're spending the money, it probably makes sense to consider the alternatives that you can port to that won't put you at the mercy of a single vendor and won't be as likely to change arbitrarily in the future. So as soon as people with large code bases start hearing that they're going to have to work to port their apps from VB to VB.NET with WinForms, and then they start hearing that WinForms isn't really the future, the future is really this Avalon thing nobody has yet, they start wondering whether it isn't time to find another development platform.

J'avais d'ailleurs senti un sentiment de frustration chez les développeurs de la communautés Microsoft qui n'ont pas aujourd'hui les idées claires. Quelles seront leurs "fondations" de demain avec des technologies de développements Microsoft évoluant très (trop ?) vite. Lors des DevDays nombreux étaient ceux qui se faisaient du soucis pour leurs anciens applicatifs...

Quelle autres alternatives ont ces développeurs ? Migrer vers des langages de développements open source, qui leur garantissent une maintenance facilitée , car avec les sources, à coeur vaillant, rien d'impossible :). Ces langages, tels que Perl, Python, offrent surtout un processus d'évolution pragmatique, et permettant aux communautés d'utilisateurs/développeurs d'influer sur les modifications, les évolutions. En quelque sorte, ces projets permettent un contrôle par les usagers de leur outil de travail (qu'est-ce qu'un langage de développement sinon ?).

Bref, si on doit aujourd'hui offrir toujours plus de fonctionnalités et de nouveautés, il faut toujours veiller à faire progresser sa base installée vers ces nouvelles versions.
Les investissements réalisés aujourd'hui autour des logiciels et des réseaux ne peuvent pas être remis en cause, tous les 5 ans, à cause de la politique Marketing d'une grande société. L'open source, par la capacité de maintenance qu'il offre à ces utilisateurs permet de construire aujourd'hui des logiciels qui seront maintenus demain.

Note à toutes les entrepreprisies : vos clients d'hier seront sûrement ceux de demain, il serait donc plus prudents de ne pas les semer en route... (qu'on se le dise à RedMond !)

Que dire de plus,

Finalement le texte est passé en FORCE (c'est peu dire). Alors que des nombreuses voies demandaient une nouvelle lecture devant le parlement, un nouveau débat, bref une véritable démocratie.

Est-ce le dernier épisode ? Aura-t-on un jour des statistiques détaillées sur le sujet ?

Pour ceux qui voudraient voir le monde autrement, je vous propose d'aller faire un tour sur le site "Creative Commons", qui propose des contrats pour créer et partager (la video à ne pas manquer).

Nous aurons l'occasion d'y revenir dans une prochaine note !