Aux soirées, les gens ne me regarde plus avec un regard vide quand je leur dis que j'écris des logiciels libres. "Oh, oui, des logiciels libres—comme Linux?" disent-ils. Je signifie vigoureusement mon accord d'un signe de tête. "Oui, exactement! C'est ce que je fais." C'est agréable de ne plus être complètement en marge. Dans le passé, la prochaine question était habituellement assez prévisible: "Comment faites-vous de l'argent en faisant ça?" Pour répondre, je résumais l'économie du logiciel libre: qu'il existe des organisations pour lesquelles l'intérêt est qu'un certain logiciel existe, mais qui n'ont pas besoin d'en vendre des copies, ils veulent seulement s'assurer qu'il soit disponible et maintenu, comme un outil au lieu d'un service.

Récemment, cependant, la prochaine question n'a pas toujours été au sujet de l'argent. Le business casedu logiciel libre ^[1] n'est plus si mystérieux, et plusieurs non-programmeurs comprennent déjà—ou à tout le moins ne sont pas surpris—qu'il y a des gens employés à cela à temps plein. Plutôt, la question que j'entends de plus en plus souvent est "Oh, comment cela fonctionne-t'il? "

Je n'avais pas une réponse satisfaisante de prête, et plus j'essayais d'en trouver une, plus je m'apercevais comment ce sujet est complexe. Diriger un projet de logiciel libre n'est pas exactement comme administrer des affaires (imaginez devoir constamment être en pourparlers concernant la nature de votre produit avec un groupe de volontaires, que vous n'avez jamais rencontré pour la plupart!) Pour différentes raisons, cela n'est pas non plus exactement comme administrer une organisation à but non lucratif traditionnelle, ni un gouvernement. Cela a des similarités avec toutes ces choses, mais je suis lentement venu à la conclusion que le logiciel libre est sui generis. Il existe plusieurs choses auquelles il peut être comparé mais aucune qui lui soit semblable. En effet, même la prétention que des projets de logiciels libres peuvent être "dirigés" est poussée. Un projet de logiciel libre peut être démarrer , et il peut être influencé par des parties intéressées, souvent assez fortement. Mais ses avoirs ne peuvent devenir la propriété d'un unique propriétaire, et aussi longtemps qu'il y a des gens quelque part—n'importe où—intéressés à le faire évoluer, il ne peut pas être unilatéralement arrêté. Chacun a un pouvoir infini; chacun n'a aucun pouvoir. Cela créé une dynamique intéressante.

C'est pourquoi j'ai voulu écrire ce livre. Les projets de logiciels libres ont permis à une nouvelle culture d'évoluer, un ethos dans lequel la liberté de modifier le logiciel pour qu'il fasse tout ce que nous souhaitons est le principe central, toutefois, le résultat de cette liberté n'est pas la dispersion des individus, chacun travaillant pour son compte dans le code, mais la collaboration enthousiaste. En effet, l'habileté à la coopération elle-même est l'une des qualités les plus prisées dans le logiciel libre. Diriger un de ces projets c'est s'engager dans un type de coopération hypertrophiée, où l'habileté de non seulement travailler avec d'autres mais de concevoir de nouvelles manières de travailler ensemble peuvent résulter en de bénéfices tangibles pour le logiciel. Ce livre essaie de décrire les techniques avec lesquelles ceci peut être obtenu. Il n'est d'aucune manière complet, mais au moins c'est un début.

Produire un bon logiciel libre est un but louable en soit, et j'espère que les lecteurs qui sont venus à la recherche de manières d'y parvenir vont être satisfaits de ce qu'ils vont trouver ici. Mais au delà de cela, j'espère également vous transmettre le réel plaisir de travailler avec une équipe motivée de développeurs de logiciel libre, et celui d'interagir avec les usagers de la manière merveilleusement directe que l' Open Source encourage. Participer à une projet de logiciel libre qui a du succès est amusant, et ultimement c'est ce qui permet à tout ce système de fonctionner.