Modèle de développement

Le modèle de développement de KDE

Un projet de la taille et de l'envergure de KDE ne peut réussir que s'il est capable d'attirer un grand nombre de développeurs. Pour parvenir à réunir beaucoup de développeurs désireux de passer leur précieux temps libre au développement de KDE sans aucun espoir de rémunération (au sens classique du terme), il faut que le développement soit plaisant. Nous avons appris qu'il faut toujours qu'il y ait 'quelque chose à utiliser et à tester'. Une implantation du projet doit être disponible à tout moment. C'est la leçon principale à tirer de l'échec apparent de projets précédents.

Notre propre expérience montre que ce n'est pas vraiment une bonne idée de rédiger un cahier des charges pour un projet, quelque soit sa qualité, et ensuite de demander aux développeurs de trimer sans possibilité de créativité ou de proposer leur propre point de vue. Il est essentiel d'avoir une implantation exécutable du projet à tout moment. Une implantation qui puisse être montrée, aussi imparfaite et incomplète soit-elle, et qui sera améliorée progressivement même si cela signifie qu'après un certain temps, le code doit être jeté et réécrit du fait que la conception précédente n'a pas donné satisfaction. Reconnaissons que cette manière de procéder n'est pas toujours la plus logique. Mais le résultat final est pourtant bien meilleur, puisque l'importante augmentation du nombre des programmeurs compense largement cette légère diminution de la productivité individuelle de chacun. Il vaut mieux avoir 100 développeurs motivés et enthousiastes améliorant le projet au fur et à mesure plutôt que d'avoir 5 développeurs travaillant selon un cahier des charges et ainsi d'une manière moins efficace. Le groupe de 5 développeurs s'ennuierait rapidement, car il y aurait peu de place pour la créativité et ils ne réussiraient pas à attirer des développeurs sympas pour la même raison.

Le projet KDE étant un projet internet dont les développeurs sont des ingénieurs en informatique sacrifiant leur temps libre à l'avancement de KDE, il n'y a pas de structures hiérarchiques classiques. Contrairement aux méthodes d'une entreprise ou d'une société, il est impossible d'assigner des tâches aux développeurs en fonction de leurs compétences. Aucun développeur ne s'engagerait dans un sous-projet uniquement parce que le gestionnaire du projet lui a dit de le faire. En l'absence d'une hiérarchie classique et de structures puissantes, comme celles que l'on trouverait dans une entreprise de développement logiciel, le développement doit rester agréable, dans l'intérêt final du projet. Le respect et la considération envers les développeurs du projet sont uniquement basés sur la grande qualité des contributions et non sur un statut artificiel. Nous considérons l'absence d'une structure hiérarchique comme une opportunité unique et un avantage permettant de faire bouillonner des idées et en extraire les meilleures pour les implanter avec satisfaction indépendamment de leur origine.