- Le temps humain investi (converti en euros parce que la viande réclame un salaire) : ainsi une équipe pléthorique de consultants-développeurs formés au dernier framework Java à la mode, épaulés par de nombreux consultants fonctionnels débitant de la spéc’ sous Word au kilomètre, encadrés d’innombrables chefs de projets ceinture noire de Powerpoint et champion de buzzword, soutenus par quelques assistantes, dans des locaux superbes, sortira un code forcément plus coûteux que le petit logiciel pensé et codé par un vieux renard et un petit génie dans leur garage — à fonctionnalité égale.

Se rappeler qu’en informatique la productivité gagne un ordre de grandeur à chaque niveau de compétence, de médiocre à normal à expert à gourou à Knuth, que le périmètre/la vision (la spéc’) est un pré-requis à une bonne réalisation, et qu’une équipe ramassée motivée focalisée sur un objectif générera en général quelque chose de plus maniable et léger qu’un monstre technocratique.

Cependant, comment estimer la valeur du temps des milliers de contributeurs à une distribution Linux, pour beaucoup bénévoles ?

- La maintenabilité, ce qui recouvre une masse de choses : le code est-il compréhensible assez facilement par un expert ? un gourou ? le premier développeur venu ? uniquement le développeur originel ? plus personne ? Y a-t-il des pièges ? Le logiciel explose-t-il pour des raisons inconnues à la première modification ? Les tests unitaires sont-ils automatisés et robustes ? Le langage utilisé est-il courant/rare/confidentiel/abandonné par l’éditeur ?

- Peut-on revendre le code à un autre pigeon partenaire ? Ce critère est uniquement commercial. Le cas extrême de SCO montre que ce code n’a pas forcément besoin d’exister ou de vous appartenir d’ailleurs.

- Les fonctionnalités : évidemment, un logiciel ne vaut que parce qu’il permet de faire. Un programme développé en interne permet des gains de productivité. Un éditeur voit plus ce qu’il peut vanter à ses clients. Dans le premier cas, les fonctionnalités, ciblées, doivent marcher ; dans le second il faut un max de «cases à cocher » et la stabilité n’est qu’accessoire (pour l’éditeur).

- La généralité : le code de contrôle du troisième booster gauche d’Ariane 4 n’intéressera pas grand-monde, ce code est archi-spécialisé. Une bibliothèque sympathique de calcul numérique bien fichue se répandra comme la poudre dans les universités. Un code de lecture de MP3 est susceptible de se retrouver dans n’importe quel bout d’électronique.

- La non-généralité ou plutôt le monopole : un produit seul sur son créneau vaut évidemment plus. Après, est-ce lié au code superbe, efficace et bien maintenu, au business model, à l’hyper-spécialisation de la niche, à un verrouillage par brevets, à la fidélisation des clients par leur satisfaction ou par corruption de leurs chefs... ça dépend.

- Le temps économisé : typiquement, un gros éditeur (Oracle, SAP, Microsoft...) préfère souvent acheter un produit innovant et l’ajouter à son catalogue que redévelopper un concurrent lui-même. Nombreux sont les cas où du code pourri n’a d’intérêt (et de succès) que parce qu’il a été le premier.

- La licence : ironiquement, la valeur associée à ce critère dépend de la personne visée. Le code de Linux, s’il pouvait être acheté par Microsoft, ne vaudrait rien (l’argent serait jeté par la fenêtre, le code GPL une fois libéré ne pouvant être rappelé) : Microsoft devrait acheter les développeurs. Et à l’inverse, ce code n’a de valeur pour moi que parce que Microsoft ou Oracle ne peuvent mettre la main dessus. Inversons : si je mettais par magie la main sur le code de Business Objects, je ne pourrais rien en faire (légalement) pour des raisons de droits d’auteur. (Ajout de 2010 : Oracle est en train de se brûler à ce phénomène : ayant racheté MySQL et (indirectement) OpenOffice.org, les deux produits sont victimes de forks par des membres de la communauté mécontents de la manière dont Oracle les traite.)

- Le service rendu : le problème devient plus celui de la valeur d’un outil de manière générale, différent de son prix, qui est le capital qu’un utilisateur accepte de mettre sur la table pour gagner de la productivité plus tard.

- La maturité : c’est la position de Microsoft, défendue un jour par Joel Spolsky dans un billet que j’ai la flemme de rechercher. Un code pourri fonctionnel et à peu près débogué vaut mieux qu’un nouveau développement propre que l’on stabilisera pendant des années, au risque de perdre le marché (stagnation des fonctionnalités, perte de clients frustrés...) ou de se prendre un « effet second système » en pleine face.

Ajoutons enfin que la valeur d’un code peut descendre en-dessous de zéro (en clair : on est plus riche sans ce code).

  • Le code ancien, sans les gens qui le connaissent, prend plus de temps à être compris et maintenu que réécrit de zéro (ce qui dépend tout de même fortement de la maturité de l’industrie, de l’importance de la compatibilité avec l’existant, des évolutions futures à insérer au chausse-pied dans le vieux code, du langage…).
  • Pour une nouvelle équipe concurrente qui démarre de zéro avec le concept en tête, un code existant serait un cadeau empoissonné : soumission inconsciente aux paradigmes de l’existant ; temps perdu à comprendre le code original au détriment du nouveau ; risques légaux souvent évidemment. L’explication du succès de Microsoft et autres non-innovateurs est en partie là : piquer leur idée aux vrais inventeurs, et refaire de zéro, mais sans le passif des essais-erreurs (toujours visibles dans le code). Comme quoi les spécs et le principe sont une fois de plus le plus important. Apple est assez doué aussi pour reprendre un concept existant (lecteur MP3, smartphone...) et le peaufiner.

Bref, one more time, le dilemme revient : dois-je jeter l’existant décrépi, plein de recoins mystérieux, limité, lent, pour investir dans un nouveau système tout nouveau tout beau tout propre qui sortira Dieu sait quand avec un gros risque d’« effet second système » ?

Difficile décision à chaque fois qui dépend de l’état des spécs, des commanditaires impliqués, de la balance quotidienne entre maintenance de l’ancien et développement du nouveau, de la décrépitude du code, des outils employés, du turn-over des développeurs, de la péremption des paradigmes sous-jacents...

Le critère le plus important : les gens. Or, d’une part :

In fact, the most important thing that gets reused from most failed projects is the (now more experienced) programmers.

Les seules choses que l’on recycle de la plupart des projets abandonnés sont les (à présent plus expérimentés) programmeurs.

Cleaner, Slashdot.org, 6 décembre 2008

D’autre part, comme dit plus haut, le vieux code n’a souvent d’intérêt que parce que les gens qui l’ont fait sont encore là. Match nul.