L'origine du projet remonte à la thèse de doctorat de Liblit (qui a obtenu le prix 2005 de la meilleure thèse par l'Association for Computing Machinery). Selon lui : "il est impossible de détecter ou d'anticiper tous les bugs. le comportement est tellement dynamique qu'il est devenu utile de regarder les programmes comme si ils étaient des systèmes organiques dont le comportement complet n'est pas connaissable. Mais il y a des tendances de comportement et vous pouvez les observer statistiquement afin de les déchiffrer".

La technique utilisée est l'instrumentation de divers logiciels afin d'observer ce comportement. Cette instrumentation n'est pas active en permanence car cela produirait trop de données et cela ralentirait trop le logiciel. Au lieu de ça on utilise le code classique la majorité du temps et le code instrumenté n'est exécuté qu'une fois sur 10 ou une fois sur 100 (selon un modèle statistique détaillé ici). L'instrumentation en elle-même est assez complexe puisqu'elle tient compte des embranchements dans le code (les if, then, else) ou des valeurs retours des fonctions, des assignations de variables, etc. Une introduction très générale est disponible sur le site du projet mais, pour ceux qui veulent aller plus loin, de nombreux articles scientifiques sont accessibles sur la page personnelle de Ben Liblit.

Les statistiques sont ensuite envoyées automatiquement avec un format normalisé. Tout d'abord on a le rapport d'environnement (Environment Report) qui donne des informations générales sur le logiciel, sur l'instrumentation qui a été utilisée et sur l'état du logiciel (normal ou planté). Après la définition de l'environnement viennent les données proprement dites (Samples Report). L'interprétation de ces données n'est pas possible en regardant simplement ce fichier. Il est remis en forme par l'équipe du projet à l'aide de l'outil resolve-samples (qui est également mis à la disposition de tous sous licence BSD). Enfin un rapport au format spécifique est envoyé en cas de crash d'une application. Il est à noter que, pour les membres du groupe, un comportement normal est tout aussi intéressant qu'un crash : "The good runs tell us what the software is supposed to be doing. The bad ones tell us what went wrong by revealing how they are different from the good runs. This is what we call statistical debugging: finding bugs in programs via automated statistical analysis instead of laborious manual inspection". Pour les personnes intéressés par l'écriture d'un schéma d'instrumentation d'un logiciel, un guide est disponible afin de vous aider a créer vos propres contrôles.

Bien entendu ce projet ne serait pas viable sans une forte attention portée au problème de la confidentialité des données. Le groupe de l'université du Wisconsin en est bien conscient et il a décidé de consacrer une page à cette problématique. Tout d'abord, pour vérifier l'accord de l'utilisateur, une fenêtre de dialogue apparaît au premier lancement afin qu'il puisse cliquer pour confirmer. Si, pour une raison ou une autre, cette fenêtre ne peut s'afficher, alors tout le code d'instrumentation est désactivé. Si l'utilisateur change d'avis une seconde fenêtre est disponible dans les préférences de Gnome afin d'activer ou de désactiver a posteriori. Une icône de notification est même présente en permanence dans le panel de Gnome ou de KDE afin que l'utilisateur soit en permanence conscient de ce qu'il fait.

Ensuite les rapports de données sont envoyés chiffrés (par SSL) sur le serveur du projet CBI. ces données ne sont accessibles qu'aux membres du projet. Enfin ces données ne contiennent jamais d'informations sensibles puisque le projet CBI ne s'intéresse qu'aux statistiques de comportement des logiciels. Par exemple les rapports contiennent les noms des fonctions mais pas la valeur des arguments de ces fonctions. Comme l'explique la page sur la confidentialité : "We might check whether a particular file name variable is NULL, but we never record the file name itself."

Le fait que le chemin du code instrumenté ne soit exécuté que très épisodiquement est également une garantie que le rapport de données statistiques ne pourra pas être utilisé de façon malicieuse.

Actuellement le projet CBI reçoit plus de 3.000 rapports par mois et, en avril 2006, la base de données comptait 546 crashs de programmes et 11.369 erreurs de bas niveau.

En définitive le projet CBI est une addition de qualité à l'arsenal déjà existant permettant de traquer les bugs dans les logiciels libres. Il est très intéressant d'observer les tendances au crash des logiciels en fonction des périodes (ici un exemple avec Nautilus ou une comparaison entre Nautilus et Gnome-panel).

On peut bien entendu regretter que les versions instrumentées ne soient disponibles que pour Fedora et que le nombre de logiciels soit assez réduit (même si des contraintes existent quand à la sélection de ces derniers).

Il ne reste plus qu'à espérer que de nombreux utilisateurs vont télécharger les logiciels du projet CBI afin d'améliorer leur qualité au profit de tous.