Je suis plutôt d'accord avec toi, je rajouterai les éléments suivants (plutôt du point de vue du développeur):
- Rejoindre un projet, c'est pas évident. Lire le code est une chose, encore faut-il qu'il soit commenté (ce qui est la plupart du temps le cas), et surtout, dès que l'appli est un peu compliquée, avoir une vue d'ensemble de l'architecture. Je parle pas forcément de diagrammes UML, mais au moins d'avoir une idée de comment le bousin fonctionne, quel bout de code fait quoi... faute de quoi on se retrouve à patauger pendant deux jours dans 25 buffers Emacs différents, c'est un peu pénible et ça aide pas à la motivation.
Pour moi, un projet qui veut des contributions se doit de proposer ce genre de choses. Un bon exemple de ça est Zope (un des trois zope books reprend toute l'architecture) ou le kernel.
- Attaquer son propre projet est très enrichissant, aussi bien d'un point de vue technique (coder un gestionnaire de fenêtre, c'est explorer l'API X en profondeur) qu'humain (travailler en équipe, gérer ses deadlines, le support aux utilisateurs...) C'est aussi gratifiant pour l'ego bien sûr.
Avoir trop de projets, je ne crois pas. Chaque logiciel a un cycle de vie différent, se développe suivant les besoins et les choix technologiques de ses utilisateurs, implémente son lot de fonctionnalités propres (qui finiront par être implémentées par les autres si elles sont efficaces). Le gros avantages du libre est l'attachement à des standards ouverts qui fait que la plupart des applis d'un même domaine utiliseront des formats de fichiers compatibles (par exemple Koffice qui pourra très bientôt utiliser le .sxw)
[^] # Re: Trop de logiciels peut-être
Posté par __caffeine__ . En réponse au journal Trop de logiciels peut-être. Évalué à 1.
- Rejoindre un projet, c'est pas évident. Lire le code est une chose, encore faut-il qu'il soit commenté (ce qui est la plupart du temps le cas), et surtout, dès que l'appli est un peu compliquée, avoir une vue d'ensemble de l'architecture. Je parle pas forcément de diagrammes UML, mais au moins d'avoir une idée de comment le bousin fonctionne, quel bout de code fait quoi... faute de quoi on se retrouve à patauger pendant deux jours dans 25 buffers Emacs différents, c'est un peu pénible et ça aide pas à la motivation.
Pour moi, un projet qui veut des contributions se doit de proposer ce genre de choses. Un bon exemple de ça est Zope (un des trois zope books reprend toute l'architecture) ou le kernel.
- Attaquer son propre projet est très enrichissant, aussi bien d'un point de vue technique (coder un gestionnaire de fenêtre, c'est explorer l'API X en profondeur) qu'humain (travailler en équipe, gérer ses deadlines, le support aux utilisateurs...) C'est aussi gratifiant pour l'ego bien sûr.
Avoir trop de projets, je ne crois pas. Chaque logiciel a un cycle de vie différent, se développe suivant les besoins et les choix technologiques de ses utilisateurs, implémente son lot de fonctionnalités propres (qui finiront par être implémentées par les autres si elles sont efficaces). Le gros avantages du libre est l'attachement à des standards ouverts qui fait que la plupart des applis d'un même domaine utiliseront des formats de fichiers compatibles (par exemple Koffice qui pourra très bientôt utiliser le .sxw)