Re: [Kos-dev] Comment attirer de nouveaux développeurs ?

[David Anderson]

Yepla,

>  - il n'y a pas beaucoup de documentation, même si la série d'articles 
> sur SOS est en train de combler ce manque.

A mon avis, c'est un manque assez cruel. Il faudrait vraiment une sorte 
de HACKING assez complet sur la structure du bordel, parce que le 
développeur vaguement intéressé va la chercher avant de se plonger dans 
le code. Et même si pour toi le code parait clair, je peux t'assurer 
que, vu de l'exterieur, sans doc, ca parait assez folklo, voire 
décourageant.

>  - le projet n'a pas d'utilisateurs et n'en aura vraisemblablement 
> jamais. Il n'y a donc que la satisfaction d'apprendre et de faire un 
> truc qui marche, pas un truc qui soit utilisé.

Il faut avouer que dans l'état actuel, difficile d'avoir des 
utilisateurs. Il reste du chemin à faire avant que kos ne devienne 
utilisable par l'end-user, donc c'est un peu normal qu'il n'y en aie pas 
actuellement ;-)

> Malgré cela, des développeurs ont par le passé été intéressés par le 
> projet. Je voulais donc avoir votre avis sur ce qui manquait dans KOS 
> pour trouver de nouveaux développeurs. Plus de documentation ? Dans 
> quelle langue ? Plus de communication sur le fait qu'on recherche des 
> contributeurs ? Plus d'ouverture ? Une TODO-list de choses simples à 
> réaliser ?

Dans l'ordre (amha):
  - Ecrire le HACKING, qui décrit la structure du projet, la structure 
de KOS. Même les grandes lignes, on pourra affiner au fur et à mesure au 
besoin.
  - Une TODO-list de choses simples (et moins simples aussi) à faire, 
avec des instructions claires: s'abonner a kos-dev et dire qu'on 
s'attaque à une feature, envoyer un patch, toussa...
  - Une annonce en première page du site qui dit que le projet est à la 
recherche de gens motivés pour le faire bouger.

> L'objectif de ce mail est d'ouvrir une discussion autour de ce sujet. 
> Laissez libre cours à vos impressions pour dire ce que vous pensez du 
> projet et de ce qu'il est nécessaire de faire pour attirer du nouveau 
> monde. Peut être quelqu'un de la liste ?

Je vais te donner mon point de vue sur KOS. Pour les autres, le point de 
vue est donc celui d'un "utilisateur final": je n'ai pas (encore) 
développé sur KOS; j'ai une expérience en programmation et une culture 
minimale sur les OS qui me permet de m'y retrouver plus ou moins dans 
les sources, et je comprends à peu près ce qui se passe quand KOS boote; 
j'aimerais contribuer au projet dans un avenir plus ou moins proche.

La première impression lorsqu'on arrive sur le site, c'est que c'est un 
projet intéressant. Il serait bien de séparer le "developper's corner" 
de la partie "pays des bisounours", pour ne pas effrayer les gens qui 
passent avec la description assez barbare de Karm, pour ne donner que 
cet exemple.
Je sais bien que la tentation est grande de tout de suite sauter dans le 
grand bain en expliquant exactement toutes les features tuning, mais 
lors d'une première visite, c'est déroutant de voir qu'on ne comprend 
plus qu'un mot sur deux ;-)

Bon, dans mon cas, il en fallait plus que ca pour me décourager. Je 
checkout le cvs, je veux attaquer les docs, mais on me dit qu'elles sont 
plus ou moins toutes obsolètes. Ah, ben ca la fout pas terrible pour se 
familiariser au chbouib. Et encore moins pour compiler le chbouib, 
puisque l'INSTALL est aussi obsolète.

M'aidant du Thomas que j'avais sous la main, j'ai une image grub. Encore 
quelques minutes à m'énerver sur bochs, et ca bootaize. Et puis la... 
"Ouais, cool, ca boote, c'est super... Et maintenant?" Sans 
documentation, je n'osais attaquer le code que du bout des doigts. 
C'était sans doute psychologique, mais bon voila.

Donc mon avis, c'est que pour attirer du monde, il faut:
  - rendre le site un peu moins rebutant pour le surfeur de passage, au 
niveau technique (rester succinct sur les caractéristiques exactes de 
Karm ou de l'architecture modulaire, expliquer en termes simples, et 
laisser les explications sur le linkage dynamique multistage pour le 
coin des développeurs :-)
  - Faire des docs à jour, documentant la structure globale du code, les 
choix faits pour les composants existants... Une sorte de Documentation/ 
comme celle qu'on trouve dans le noyau linux: un fichier par composant, 
avec une explication plus ou moins fournies, des remarques, des idées; 
quelques fichiers qui synthétisent le fonctionnement global des divers 
morceaux entre eux; une TODO-list, à jour elle aussi, avec les choses à 
faire, qui les fait (si elles ont été affectées), des pistes sur des 
solutions possibles, etc.

Bref, document, document, document :-)

Voila. Je pense que mon intervention est des plus inutiles, puisque 
c'est aparemment la direction qui est prise, mais voila, mes 2¢. Et puis 
ca devrait te rassurer: tu ne parles pas dans le vide ;-)

- Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://the-doors.enix.org/pipermail/kos-dev/attachments/20050106/ea3c0f77/signature.pgp