Le logiciel libre commence à prendre de l'importance même au sein des entreprises et/ou gouvernements (OpenOffice dans les administrations françaises, Surcouf qui vend des ordinateurs avec Ubuntu, etc).
En temps qu'utilisateur de logiciels libres vous prêchez certainement leur utilisation à la place de logiciels propriétaires équivalents auprès de vos proches (qui sont pour la plupart des gens ayant une connaissance très limité de l'informatique et une appréhension démesurée dès que vous leur proposez de leur remplacer les outils propriétaires qu'ils connaissent). Bref, vous passez déjà assez de temps à essayer de les former à ces nouveaux outils (et à assurer la maintenance) en espérant qu'ils finiront aussi par prêcher la bonne parole et lutter contre le propriétarisme 
Mais vous avez peut-être envie de passer le cap supérieur en n'étant plus simplement un utilisateur du libre, mais aussi l'un de ses nombreux contributeurs. Vous avez certainement quelques connaissances dans un langage de programmation possédant un compilateur lui aussi libre (par exemple C ou C++). Prenons alors le cas où vous souhaitez développer une bibliothèque libre pour l'un de ces langages.
La première question à se poser est sous quelle licence allez vous partager les sources de votre bibliothèque ? En tant que bibliothèque libre, si elle rencontre un certain succès, elle sera amenée à être réutilisée, voir même améliorée, par d'autres développeurs. Et même si comme moi vous n'êtes pas un expert en droit, vous avez déjà entendu plusieurs noms de licences existantes pour les logiciels libres (licences GPL, licence BSD, licences Creative Common, licence CeCILL, etc.). Mais comment choisir celle qu'on utilisera pour notre bibliothèque ? Les nuances entre toutes ces licences peuvent être subtiles, pour ne pas dire invisibles, au néophyte. Par fainéantise (et car mon éditeur de texte me permet de rajouter automatiquement en entête de mes fichiers le jargon associé à la licence GPL, c'est celle-ci que j'ai choisi.. mais si vous êtes moins fainéant que moi, peut-être en choisirez vous une autre).
Une fois la question de la licence réglée, il faut choisir un système sur lequel le développement de votre bibliothèque pourra se faire de manière collaborative (car si les sources sont partagées, vous pouvez espérer obtenir de l'aide de la part d'un autre développeur de logiciels libres). Pour ma part le choix fut encore plus rapide que pour le problème de la licence, car connaissant assez bien le logiciel libre de gestion de version Subversion et ayant un serveur à disposition, je l'ai retenu.
Un autre point important est la portabilité de la future bibliothèque : en effet en temps que logiciel libre, elle est amenée à être utilisée sur de nombreuses architectures différentes et du coup vous devez vous assurer que votre bibliothèque fonctionnera (ou du moins compilera) sur une machine qui n'est pas la votre et qui peut même être très différente de la votre ! Cette tâche très difficile est en partie gérée à votre place par un ensemble d'outils : les Autotools. Je dis en partie, car leur utilisation reste encore pour moi une tâche compliquée qui me demande beaucoup de temps pou obtenir le résultat attendu (à savoir d'être à peu près sûr que l'utilisateur de votre bibliothèque réussira à la compiler).
Bien, la partie la plus compliquée, mais aussi la plus intéressante dans la création d'une bibliothèque libre est la suivante : la conception. En effet, votre bibliothèque sera à terme – vous l'espérez – utilisée par de nombreux développeurs qui devront réussir à s'en servir sans vous demander de venir leur faire une présentation dans leur bureau. Ils devront même pouvoir lui rajouter des fonctionnalités sans avoir à modifier le code que vous avez écrit. Cette généricité et modularité n'est pas facile à obtenir et demande un réel effort de votre part. Il ne faudra pas seulement développer un outil uniquement pour l'objectif que vous avez, mais au contraire chercher perpétuellement comment séparer aux mieux tous les ingrédients dont vous avez besoin afin qu'ils puissent tous être utilisés séparément. Malheureusement je ne connais pas de solution ni d'outil miracle pour cette étape dans la réalisation d'une bibliothèque libre. Et seul l'utilisation abusive de papiers, stylos, tableaux et autres ustensiles de réflexion pourra vous aidez à réussir cette étape…
Enfin une dernière étape, mais néanmoins indispensable, est la mise à disposition de votre bibliothèque au reste du monde ayant accès à la toile. Vous pouvez bien sûr juste déposer une tarball (make dist) de votre projet sur un site Web. Mais dans ce cas, le suivi des bugs; et le retour des utilisateurs de votre bibliothèque sera bien moindre que si vous leur offrez la possibilité de faire un rapport via une interface Web. Comme j'utilise subversion (svn) pour le développement de la bibliothèque, utiliser Trac semble être une bonne idée.
Voilà je pense que ce billet est suffisamment long pour ne pas rajouter un tas de détails sur chacun des outils cités tout au long de ce billet. Je détaillerai peut-être un jour certains de ces outils, mais l'idée principale à retenir est que le développement de logiciels libres demande un surcoût non négligeable dans toutes les phases de réalisation, mais ce surcoût conduit à un produit d'une qualité bien supérieure.
En attendant j'aimerai améliorer mon classement sur Google ; Voici la mise à jour de ma page professionnelle Oudinet
longues années pour obtenir un dénouement positif à cette histoire !
