L'étude est intéressante, mais la redéfinition du mot 'libre' est peut-être malvenu.
Pourquoi ne pas plutôt essayer de créer un nouveau "concept" comme 'communautaire', ou 'public' ?
Parce qu'on parle bien de libre.
Parce que là, ça fait un peu : vous n'avez rien compris, les 4 libertés fondamentales, ça suffit pas pour être libre, faut aussi (tous vos critères).
Déjà que certains trouvent que la GPL, de part son obligation de redistribution sous GPL, n'est pas si libre que ça. Si en plus, il faut fournir les sources à tout le monde, mais aussi avoir un serveur publiquement accessible, à ses frais, de gestion de mailing-list, de bugs et downloads ...
Le métier dont je vis depuis 1999 est l'intégration de logiciel libre : je prend des logiciels que j'adapte pour les clients, et j'essaie qu'ils ne soient pas obligés de faire des pieds et des mains pour les maintenir, qu'ils puissent les comprendre, les maintenir, les étudier et les modifier et les redistribuer. Les 10 règles proposées, sont des règles simples issues de ma pratique pendant 6 ans. Les 4 libertés s'appliquent au logiciel comme un tout, non aux licences uniquement. Se baser uniquement sur la licence, c'est comme jugé une personne sur ces intentions et non sur ses actes. Après tout, les licences ne sont qu'une déclaration d'intention.
Se poser des questions de la pratique de libérer les logiciels (qui nécessite une licence libre) est à mon avis une démarche saine. Les licences libres sont une conditions nécessaire mais non suffisante pour accéder aux quatres libertés.
Pour info, on a pas fait de critère pour l'évaluation du code, car libroscope n'a pas vocation à parler technique. À ce titre je rajoute les critères pour le code sur linuxfr que j'applique.
En ce qui me concerne quand je regarde le code je regarde :
0) les données internes et externes ! (la chose la plus importante en ce qui me concerne)
1) dispersion des fichiers (beaucoup de fichiers dispersés c'est un enfer, tout dans un gros fichier aussi)
2) cohérence dans les nommages (begin/end,star/stop), notation wiki ou avec_underscore suivie
3) inclusion des tags $Id$ pour le traçage des versions (svn/cvs)
4) style de l'auteur (est-ce que l'on à affaire à un texte littéraire dont les noms sont faits pour aider ou un truc laborieux)
5) programmation scolaire (genre les gens qui veulent du OO partout et qui font des getteur et des setteurs pour accéder aux tables de hachage en PHP je fuis),
6) intégration (la personne s'appuie-t'elle intelligemment sur l'OS/distro) ;
7) réinvention de la roue ou sur-utilisation de projet ;
8) complexité (plus un code est complexe, plus il risque de foirer)
9) Enfin pour vérifier que je comprend le code, j'essaie systématiquement de trouver comment modifier la fonction login/authentification.
Un bon code ne nécessite pas de doc, SAUF pour les librairies ou l'API doit être décrites (arguments en entrées, en sortie, traitement, et exemples de code). Je lis toujours les documents : sur les modes de configuration d'un logiciel, l'idée générale derrière le projet.
Cependant, j'ai souvent remarqué que les 10 critères énoncés dans le benchmark étaient suffisants pour assurer de manière satisfaisante la qualité du code ; peut être que quand le code est visible/modifiable par tous, il a plus de chance d'être corrigé.
PS j'ai au mieux 70% comme note avec le code que j'écris.
[^] # Re: Evaluation de projets libres
Posté par Jul (site web personnel) . En réponse à la dépêche QSOS ou comment gagner en objectivité dans l'évaluation et la sélection de logiciels libres. Évalué à 2.
Parce qu'on parle bien de libre.
Le libre est une démarche exigeante. Vae victis.
http://www.libroscope.org/Liberer-les-logiciels
Le métier dont je vis depuis 1999 est l'intégration de logiciel libre : je prend des logiciels que j'adapte pour les clients, et j'essaie qu'ils ne soient pas obligés de faire des pieds et des mains pour les maintenir, qu'ils puissent les comprendre, les maintenir, les étudier et les modifier et les redistribuer. Les 10 règles proposées, sont des règles simples issues de ma pratique pendant 6 ans. Les 4 libertés s'appliquent au logiciel comme un tout, non aux licences uniquement. Se baser uniquement sur la licence, c'est comme jugé une personne sur ces intentions et non sur ses actes. Après tout, les licences ne sont qu'une déclaration d'intention.
Se poser des questions de la pratique de libérer les logiciels (qui nécessite une licence libre) est à mon avis une démarche saine. Les licences libres sont une conditions nécessaire mais non suffisante pour accéder aux quatres libertés.
Pour info, on a pas fait de critère pour l'évaluation du code, car libroscope n'a pas vocation à parler technique. À ce titre je rajoute les critères pour le code sur linuxfr que j'applique.
En ce qui me concerne quand je regarde le code je regarde :
0) les données internes et externes ! (la chose la plus importante en ce qui me concerne)
1) dispersion des fichiers (beaucoup de fichiers dispersés c'est un enfer, tout dans un gros fichier aussi)
2) cohérence dans les nommages (begin/end,star/stop), notation wiki ou avec_underscore suivie
3) inclusion des tags $Id$ pour le traçage des versions (svn/cvs)
4) style de l'auteur (est-ce que l'on à affaire à un texte littéraire dont les noms sont faits pour aider ou un truc laborieux)
5) programmation scolaire (genre les gens qui veulent du OO partout et qui font des getteur et des setteurs pour accéder aux tables de hachage en PHP je fuis),
6) intégration (la personne s'appuie-t'elle intelligemment sur l'OS/distro) ;
7) réinvention de la roue ou sur-utilisation de projet ;
8) complexité (plus un code est complexe, plus il risque de foirer)
9) Enfin pour vérifier que je comprend le code, j'essaie systématiquement de trouver comment modifier la fonction login/authentification.
Un bon code ne nécessite pas de doc, SAUF pour les librairies ou l'API doit être décrites (arguments en entrées, en sortie, traitement, et exemples de code). Je lis toujours les documents : sur les modes de configuration d'un logiciel, l'idée générale derrière le projet.
Cependant, j'ai souvent remarqué que les 10 critères énoncés dans le benchmark étaient suffisants pour assurer de manière satisfaisante la qualité du code ; peut être que quand le code est visible/modifiable par tous, il a plus de chance d'être corrigé.
PS j'ai au mieux 70% comme note avec le code que j'écris.