Effectivement, pour un projet quelconque, une documentation riche, qu'il s'agisse de modèles ou de texte, permettrait certainement une meilleure diffusion de la connaissance qu'il y a dedans. Rien que sur l'aspect « qu'est-ce qu'il fait le bouzin ? », ce serait déjà plus facile, mais aussi le côté « et comment tu fonctionne dedans, petit ? » deviendrait, on peut l'espérer, carrément abordable. De fait, ça répondrait bien aux motivations affichées de la communauté, en tant que « groupe de travail ».
Mais il y a un « mais », bien entendu ! On passe souvent trop vite sur le fait qu'un travail collectif n'est pas qu'une somme de travaux individuels, et on ne se rend donc pas compte que les individus, à leur échelle, n'ont pas forcément les mêmes objectifs (pas forcément avoués non plus) que la communauté à laquelle ils se veulent appartenir.
En un peu moins verbeux, un peu plus clair et un poil plus violent : un « free hacker », pris isolément, cherche assez souvent la reconnaissance de ses pairs. Pour l'obtenir, il faut que le reste de la communauté ait à passer par lui pour obtenir telle ou telle information... on pourrait même dire « connaissance ». S'il veut conserver cette reconnaissance, pour rester dans le coup, il ne peut que difficilement se permettre de rendre son savoir aussi public qu'il le prétend.
Résultat, l'idée répandue que pondre de la doc, ça fait perdre beaucoup de temps de codage, alors que « toute l'info est déjà dans le code, n'importe qui peut la faire, la doc » (1), sert en fait de plus sombres (in-)intentions. Je ne dis pas que c'est forcément conscient, mais il n'empêche qu'on a beau être programmeur, on se retrouve parfois à fouiller du code complètement imbitable. Je n'irais pas jusqu'à hurler à l'obfuscation, mais bon... sans analyse, on a l'architecture logicielle branlante qu'on mérite, aussi. ;)
[^] # Re: Il y a d'autres raisons
Posté par gourgou . En réponse au journal Conception et OpenSource. Évalué à 3.
Mais il y a un « mais », bien entendu ! On passe souvent trop vite sur le fait qu'un travail collectif n'est pas qu'une somme de travaux individuels, et on ne se rend donc pas compte que les individus, à leur échelle, n'ont pas forcément les mêmes objectifs (pas forcément avoués non plus) que la communauté à laquelle ils se veulent appartenir.
En un peu moins verbeux, un peu plus clair et un poil plus violent : un « free hacker », pris isolément, cherche assez souvent la reconnaissance de ses pairs. Pour l'obtenir, il faut que le reste de la communauté ait à passer par lui pour obtenir telle ou telle information... on pourrait même dire « connaissance ». S'il veut conserver cette reconnaissance, pour rester dans le coup, il ne peut que difficilement se permettre de rendre son savoir aussi public qu'il le prétend.
Résultat, l'idée répandue que pondre de la doc, ça fait perdre beaucoup de temps de codage, alors que « toute l'info est déjà dans le code, n'importe qui peut la faire, la doc » (1), sert en fait de plus sombres (in-)intentions. Je ne dis pas que c'est forcément conscient, mais il n'empêche qu'on a beau être programmeur, on se retrouve parfois à fouiller du code complètement imbitable. Je n'irais pas jusqu'à hurler à l'obfuscation, mais bon... sans analyse, on a l'architecture logicielle branlante qu'on mérite, aussi. ;)
Pour une explication un peu plus « propre » du phénomène, je ne saurais que conseiller vivement de jeter un oeil aux travaux de Thomas Basset :
http://thomasbasset.net/dea.php(...)
Pour ceux qui préfèrent la télé, sa conf à l'install party de l'ENS Cachan, en 2003, a été enregistrée (attention au mal de mer ;) :
ftp://ftp.crans.org/pub/Install-party/Thomas_Basset.ogm(...) (100Mo, plus de choix
sur http://install-party.ens-cachan.fr/index.php?p=photos(...) )
(1) Un exemple criant dans les sources (ou presque) du noyau : l'introduction de Documentation/sysctl/README.