Le d\u00e9veloppement de logiciels libres rel\u00e8ve, dans la plupart des cas, d’une initiative communautaire.
\nUne communaut\u00e9 de d\u00e9veloppeurs s’agglom\u00e8re autour d’un projet, de mani\u00e8re relativement naturelle, en fonction des int\u00e9r\u00eats et des comp\u00e9tences des contributeurs.
\nAinsi, pour joindre un projet et contribuer \u00e0 son d\u00e9veloppement, il faut :<\/p>\n
Tout est question de confiance et de l\u00e9gitimit\u00e9 gagn\u00e9e. Logiquement, un contributeur qui propose ses comp\u00e9tences sur un projet ne re\u00e7oit pas au d\u00e9part une tr\u00e8s grande confiance : ses patches sont relus et (\u00e9ventuellement) appliqu\u00e9s par d’autres, on ne lui demande pas son avis pour les questions d’architecture.
\nQuand la sauce prend (apr\u00e8s quelques patches*(semaines|mois|ann\u00e9es)), le projet peut commencer \u00e0 reconna\u00eetre ce contributeur, et \u00e0 lui attribuer des fonctions officielles. C’est ainsi que l’on gagne son “droit de commit”.<\/p>\n
Ce mod\u00e8le permet aux acteurs de se conna\u00eetre avant de s’accorder la confiance de modifier le coeur des projets en question. <\/p>\n
Bien entendu, les proc\u00e9dures diff\u00e8rent selon les projets. Tr\u00e8s souvent, tout ceci est extr\u00eamement informel. Mais pour certains gros projets, les choses ont \u00e9t\u00e9 quelque peu structur\u00e9es. Le projet Apache, par exemple, <\/p>\n