Je suis moi même développeur depuis plusieurs années.
Certains prétendent que c'est grâce aux quatre libertés, garanties par la GPL.
Mais pour moi ces 4 libertés sont nécessaire, mais pas suffisante.
Voici les conditions qui me font aimer un logiciel libre :
- Le code source soit être disponible depuis le gestionnaire de version (svn, git, ...). La dernière version de développement et l'historique doivent être accessible au public.
- Il doit être facile de faire accepter une modification dans la branche principale. L'accès en écriture dans le dépôts principale doit être donné facilement.
- Il doit être facile de joindre les développeurs actif (par mail, jabber, irc). Et ceux-ci doivent être sympa et ouvert.
Ces conditions sont nécessaires pour que le développement soit agréable.
Le projet KDE est typiquement un bon exemple de ce style de développement.
Un compte SVN est donné sur simple demande, et permet de commiter dans toutes les applications ou bibliothèques du projet. Pas de long processus de review ou de karma. (Biensûr les débutants feront relire leur patches par les développeurs confirmés.)
Toutes les discutions se font en public.
Et en plus les développeurs sont en général sympa et accueillants.
Pratiquement personne n'est payé pour programmer sur KDE.
Tout cela fait de KDE un projet très libre et ouvert pour lequel il est agréable de participé sur son temps libre.
Évidemment, KDE n'as pas les impératifs de qualité qu'aurais un logiciel développé par une entreprise.
Mais l'ouverture et la facilité de développement et les choix techniques libre en font tout de même un excellent produit de qualité.
# Libre != Communautaire
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu veux forcer les gens à être sympa avec toi, te donner les clés de chez eux comme toi tu l'entends?
Bof, je ne vois pas le rapport avec le libre.
Ce que tu veux imposer (ou un autre verbe, car je ne vois pas à quoi tu veux en venir) est personnel, lié à la mentalité des gens, à leur volonté de faire un projet communautaire.
Et je ne vois pas pourquoi on devrait limiter le libre au libre communautaire, si MS file un produit sous GPL, il me convient aussi, même si MS n'est pas sympa, même sans SVN. Le tout est que ce que j'utilise (distribué) soit libre. Le reste est du bonus, suivant ta perception des choses.
[^] # Re: Libre != Communautaire
Posté par Aldoo . Évalué à 1.
Pffiou fait froid dehors, dans les rues de Moscou !
[^] # Re: Libre != Communautaire
Posté par jcs (site web personnel) . Évalué à 3.
Entre à la Loubianka, tu verras il y fait chaud :-)
[^] # Re: Libre != Communautaire
Posté par Gof (site web personnel) . Évalué à 2.
> pas sympa, même sans SVN.
Moi il ne me conviendra pas car je ne pourrais pas «participer» facilement.
Elle est là la différence.
À quoi te sert le libre sinon ? À pouvoir dire « supaire j'ai les sources » ?
Car si tout le monde doit maintenir un fork pour chaque petite modification, ça va pas aller.
Et donner un accès au SVN ne signifie pas donner les clef[1]. En cas d'abus, il est facile de faire un revert. (Et en pratique j'ai jamais vu d'abus)
[1] Ou de laisser sa voiture ouverte ;-) (pour ceux qui suivent)
[^] # Re: Libre != Communautaire
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Libre != Communautaire
Posté par ragoutoutou . Évalué à 2.
Tu vas adorer l'AGPL toi :)
[^] # Re: Libre != Communautaire
Posté par Gof (site web personnel) . Évalué à 2.
Mais je vois pas le rapport.
[^] # Re: Libre != Communautaire
Posté par ragoutoutou . Évalué à 2.
Non, mais c'est pas grave... c'est vrai qu'entre maintenir son fork en interne et devoir en plus le publier (ce qui est un cas fréquent avec l'AGPL), il n'y a pas des masses de différences...
[^] # Re: Libre != Communautaire
Posté par Gof (site web personnel) . Évalué à 2.
Et il est toujours possible de respecter une licence à la lettre sans en respecter l'esprit.
L'esprit de l'AGPL est que si je fais des modifications, je dois les fournir.
[^] # Re: Libre != Communautaire
Posté par Zenitram (site web personnel) . Évalué à 2.
Faut arréter de dire des conneries... On dirait le FUD classique contre la GPL!
Si tu fais des modifications est que tu diffuses la version modifiée, tu dois fournir le source de la modification aux clients qui utilisent ton site web.
* Si tu l'utilises juste pour toi, tu ne dois rien redistribuer
* Si tu l'utilises sur l'intranet de l'entreprise, tu dois fournir le code source aux employés de l'entreprise qui utilisent ton soft.
* Les gens qui ne touchent pas à ton soft (99.999% de la population mondiale quand même) n'ont aucun droit de te demander tes modifs.
L'esprit de l'AGPL est le même que la GPL, la seule (grande) différence est la notion de distribution, qui dans le cas le l'AGPL est la personne qui accède au site.
[^] # Re: Libre != Communautaire
Posté par ragoutoutou . Évalué à 2.
Ben ça aussi c'est une affirmation avec des relents de fud Microsoft... Si tu utilises une application AGPL dans ton entreprise et que les employés y accèdent dans le cadre de leur activité professionnelle, c'est une seule et même personne morale qui utilise l'application, et il est peu probable que l'obligation de redistribuer soit applicable dans ce cas.
L'esprit de l'AGPL est une caricature de l'esprit de la licence GPL, une forme exagérée ou on renforce les devoirs et où on réduit les droits de la personne ayant fait le choix d'utiliser l'application au profit de celle ayant décidé d'utiliser le service offert par la première...
L'effet de bord amusant sera la multiplication des forks.
[^] # Re: Libre != Communautaire
Posté par Zenitram (site web personnel) . Évalué à 2.
est trop gros.
Qu'est-ce que l'AGPL change par rapport à la GPL pour les forks? Rien.
Tout le monde a accès au code de Linux sous GPL, plein de monde se fait refouler, ça ne motive pas les forks.
l'AGPL ne fait que rendre plus redistribuable le source, je ne vois pas ce qui te permet de dire que ça permet d'augmenter les forks.
Les forks, par definition, sont plutôt limités au nombre de personnes motivées pour maintenir un truc à coté, pas une différence licence BSD/LGPL/GPL/AGPL/Toute licence libre que tu souhaites.
[^] # Re: Libre != Communautaire
Posté par ragoutoutou . Évalué à 2.
vu que l'AGPL oblige à publier ses modifications (dans le cas ô combien rarissime où on les utilise sur internet), ça va dans les faits pousser chaque utilisateur ayant fait une modif à mettre à disposition sa propre cuvée... rapidement, on va se retrouver avec des dizaines de versions pas tout à fait équivalentes de chaque application AGPL, avec des écarts de version par rapport au code de base, des changements rendant incompatibles, ...
le risque est de se retrouver avec une jungle maintenue à bout de bras par des gens pas forcément motivés.
[^] # Re: Libre != Communautaire
Posté par BAud (site web personnel) . Évalué à 2.
Un bon point pour l'AGPL donc ;-)
[^] # Re: Libre != Communautaire
Posté par Putifuto . Évalué à 2.
[^] # Re: Libre != Communautaire
Posté par ragoutoutou . Évalué à 2.
Drôle mais peu réaliste...
Dans la majorité des cas, les utilisateurs contraints de devenir distributeurs vont le faire en se foutant de la qualité de ce qu'ils redistribuent. L'AGPL va forcer la redistribution, pas la qualité, pas la méthodologie.
Et si en upstream une modif n'est pas intégrée, ça fera effectivement et irrémédiablement un fork (parce que l'utilisateur en bas qui a besoin d'une fonction/modif, même légère, ne va pas attendre qu'on réagisse en haut)
Le libre, ce n'est pas modifier une application, renvoyer ses modifs et attendre la bénédiction de l'auteur et l'intégration dans le code "canonique" pour les utiliser.
[^] # Re: Libre != Communautaire
Posté par z a . Évalué à 2.
[^] # Re: Libre != Communautaire
Posté par ragoutoutou . Évalué à 2.
Ou il va camper sur sa version en ne backportant que les éléments qu'il juge important en provenance des nouvelles versions...
A la longue il va s'éloigner de l'original et ses modifs seront de moins en moins faciles à intégrer dans la version "officielle"
[^] # Re: Libre != Communautaire
Posté par Guillaume Knispel . Évalué à 1.
J'ai du mal à suivre.
Les forks, ils sont là de fait de toute façon. Je préfère qu'ils soient publiés, même si je n'irai pas jusqu'à dire qu'il est scandaleux qu'ils ne le soient pas.
[^] # Re: Libre != Communautaire
Posté par ragoutoutou . Évalué à 2.
Je dis juste, qu'en forçant la redistribution des forks "privés", on va peut-être récupérer des choses intéressantes, mais on va singulièrement détériorer le rapport signal/bruit.
Pour ma part, je ne suis pas absolument contre l'idée de forcer à un moment donné la redistribution du code, mais à forcer la redistribution de tout et n'importe quoi, on va se retrouver avec tout et n'importe quoi.
[^] # Re: Libre != Communautaire
Posté par Erwan . Évalué à 1.
Je prends l'exemple de Flock, qui est plus ou moins un fork de Firefox (en fait pas vraiment parce qu'on garde les modifications "à part" avec des overlays pour pouvoir mettre à jour facilement la version de Firefox qu'on utilise - comme a on est toujours sur la dernière version stable).
Flock est un logiciel libre, sous licence GPL, et le SVN est publique. Par contre, on soumet des patchs à Mozilla quand on modifie du code qui touche au cœur de Firefox et peut lui être bénéfique.
En bref, le fait que le SVN de Flock soit publique n'ajoute aucun bruit : personne n'est forcé d'aller lire le code de Flock, et ça ne nous empêche pas d'envoyer des patches upstream.
[^] # Re: Libre != Communautaire
Posté par Gof (site web personnel) . Évalué à 2.
Beaucoup de distributions modifient certains logiciel sous licence GPL et fournissent leurs modification.
Et en pratique cela ne crée pas vraiment de fork.
[^] # Re: Libre != Communautaire
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Dans ce cas là, faudrait pas attendre longtemps avant qu'un "gros" fork plus sympa et ouvert prenne le relai et s'attire les contributeurs. Voire l'affaire Mambo/Joomla ou xfree/xorg
Si Microsoft ou un autre distribue du libre avec un cadre contributif trop contraignant, c'est naturellement ce qui va se passer, les sources étant dispos.
[^] # Re: Libre != Communautaire
Posté par Zenitram (site web personnel) . Évalué à 2.
Je vais résumer ton journal alors : tu n'aimes pas les logiciels libres (tu les classes dans la même case qu'un logiciel propriétaire à source ouverte ou pas), tu aimes les logiciels communautaires.
Chacun est libre (sic :) ) d'aimer ce qu'il veut, mais moi j'aime tout ce qui est libre, na!
# C'est vendredi
Posté par patrick_g (site web personnel) . Évalué à 6.
Ce qui explique les 12 milliards d'options de chaque application de KDE et leur ergonomie "particulière".
[^] # Re: C'est vendredi
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
# Et la BSD c'est du poulet ?
Posté par Mr Kapouik (site web personnel) . Évalué à 0.
Et la sainte GNU/GPL n'est pas libre !!!
RMS est un menteur !!!
ps : vendredi tout est permis !
[^] # Re: Et la BSD c'est du poulet ?
Posté par Gof (site web personnel) . Évalué à 2.
J'ai donné des condition pour qu'il soit agréable de contribuer.
[^] # Re: Et la BSD c'est du poulet ?
Posté par 태 (site web personnel) . Évalué à 3.
« Logiciel libre [...] : Ma définition. »
(Comment ça je ne lis que ce que je veux bien lire ?)
[^] # Re: Et la BSD c'est du poulet ?
Posté par suJeSelS . Évalué à 2.
Chaque projet doit voir son mode de développement étudié en fonction de son chef de projet, de ses objectifs (sécurité dans mon exemple), et de ses contributeurs.
"Et ceux-ci doivent être sympa et ouvert"
Je ne suis pas d'accord, il faudrait plutôt qu'ils mettent des super stripteaseuses qu'on pourrait rencontrer pour discuter du projet.
Nan mais sérieux, chacun à sa personnalité et il faut faire avec, déjà travailler dans le logiciel libre, c'est une bonne marque de qualité.
[^] # Re: Et la BSD c'est du poulet ?
Posté par Krunch (site web personnel) . Évalué à 1.
Bon, a priori il n'y a pas de strip-tease mais je ne vois pas de projet qui s'en approche plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Pas le point 2
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Ce n'est pas parce qu'on ne donne pas les clés à tout le monde au dépôt de source que le projet est moins communautaire. Très franchement, je préfère qu'une certaine confiance s'instaure entre les dirigeants d'un projet, et un contributeur, avant de lui donner les clés. Pourquoi ?
- parce que même si on peut annuler des modifs, c'est franchement une perte de temps que de corriger les merdes de contributeurs peu scrupuleux, codant comme des porcs, ou tout simplement débutant. Et dieu sait si le temps nous est particulièrement précieux.
- J'ai pas envie, sur mes projets que les types commit n'importe quoi, des fonctionnalités dans tout les sens, des trucs qui font dévier le projet de ses objectifs, ou encore des trucs inutiles, au risque de mettre en péril le produit même : au niveau stabilité, utilisabilité etc.. (c'est du vecu)
- Si on s'aperçoit qu'un type auquel on vient de donner l'accés, fait du mauvais boulot, c'est encore une perte de temps pour le virer (lui expliquer, tout ça...), et ce n'est jamais agréable pour les deux parties. En tout cas, c'est un risque fort de tuer l'ambiance du projet si le gars en question n'est pas content et qu'il fait des histoires parce qu'on lui a couper son accès. Éviter ce genre de problème, c'est des soucis en moins. Bref, je préfère qu'il y ait une sélection à l'entrée, plutôt que de devoir virer les gens.
- Corollaire : Ne pas donner accès en écriture à tout le monde est un gage d'une certaine qualité, en tout cas d'une qualité du niveau de ce qu'attendent les responsables du projet.
- Je ne vois pas franchement à quoi ça sert de livrer l'accés en écriture si il y a un outils de suivi (bugzilla ou autre) et qu'il est utilisé efficacement : n'importe qui peut faire un checkout, faire sa modif en locale, et proposer un patch dans un ticket. Où est le problème ?
De plus, tu penses qu'un processus de review c'est long et contre-communautaire : moi je dis que l'absence de review est synonyme de code pourri (en tout cas, pourrissement à moyen et long terme, donc de plus en plus dur à maintenir). Les reviews permettent d'une part aux nouveaux venus d'apprendre par leurs erreurs, et d'autre part de faire en sorte que le code commité soit d'un niveau de qualité minimal. Par exemple, dans Mozilla, les patchs, de qui que ce soit (qu'il soit débutant sur le projet ou un vieux de la vieille), sont revues par au moins deux personnes. Et pour un projet d'une telle complexité, c'est pas du superflu.
D'ailleurs, la revue de code est un des fondements des méthodes "agiles" de développement, et garantissent, avec les tests unitaires, d'une qualité **constante**, et en tout cas plus uniforme sur l'ensemble du projet.
Bref, je préfère donner les clés à des contributeurs qui ont montré par leurs contributions passées, qu'ils sont sérieux, qu'ils codent pas trop mal et qu'ils sont actifs.
Il est possible que les devs de KDE donnent accès en écriture à tous, mais je serais vraiment étonné si ils ne mettent pas des droits restreints sur certains répertoires...
Pour conclure, non, restreindre l'accès en écriture au dépôt de source n'est pas une condition pour que le développement soit agréable. Ça n'empêche nullement de coder, de proposer des patchs. Ce qui fait qu'il est agréable de contribuer à un projet, c'est le contact que l'on a avec les devs, c'est le fait qu'il ne soit pas fait n'importe quoi sur le projet, et donc qu'il y ait des objectifs clairs et définis, qu'il y ait un minimum de serieux (sans tombé dans une atmosphère dictatoriale), que les reviewers soient "pédagogiques" genre pas dire, "ton patch il est nul", mais expliquer pourquoi ici ou là ça ne va pas, qu'est ce qu'il est préférable de faire etc. Bref, avoir l'impression qu'on apprend quelque chose, qu'on avance tous ensemble dans la même direction.
Ah oui au fait, en utilisant des dépôts décentralisés, ton point 2 n'a pas lieu d'être... les dépôts centralisés sont has been, surtout pour les gros projets... (même si j'aime bien et j'utilise subversion :-) )
[^] # Re: Pas le point 2
Posté par Gof (site web personnel) . Évalué à 2.
C'est la même chose que avec Wikipedia. Tout le monde peut contribuer sans exception. Et ça marche !
Bon, dans le cas des logiciel ça risque d'être légèrement plus dangereux. C'est pour ça que avec KDE il faut quand même avoir un compte SVN. Ce serait l'équivalent sur Wikipedia s'ils interdisait les contribution d'IP.
Le fait que tout le monde puisse participer ne veux pas dire qu'il n'y a aucune relecture. Les mainteneurs des différentes parties du code lisent bien entendu le journal des commits. Et les nouveaux envoient leur patch et questions sur la mailing list (par politesse)
En pratique, dans KDE, il n'y a eu à ma connaissance aucun abus.[1]
Non, il n'y a aucune restriction d'accès en écriture au code de KDE.[2]
Si il faut des plombes pour que un patche soit « accepté » par le reste des devs, ça va pas marcher. Et ça peut arriver si on ne donne pas d'accès en écriture car les mainteneur peuvent être occupé et penser qu'un autre répondra.
Ça marche avec Wikipedia, ça marche avec KDE, pourquoi ça marcherais pas avec le reste ?
[1] (une fois, un développeur actif a peté un cable et a commencé à comiter n'importe quoi. C'est je pense le seul cas ou un compte cvs à l'époque à été fermé. Et ce n'était pas un nouveau contributeur)
[2] les seules restrictions sont sur les répertoire d'admin du SVN et sur les page web.
[^] # Re: Pas le point 2
Posté par 태 (site web personnel) . Évalué à 2.
wikipedia, la Norvège et kde seraient les preuves vivantes que faire confiance aux autres n'est pas catastrophique et qu'il est globalement plus intéressant de parier sur les bonnes intentions de la majorité que de se surprotéger contre les mauvaises intentions d'une minorité.
À cela, on peut te rétorquer (cela a été fait plus haut) que dans le cas d'un logiciel, les bonnes volontés peuvent le faire dévier de ce qui est son but fixé par le leader du projet, mais aussi qu'en l'absence de police, les mauvaises volontés (sauvageons ou concurrents) peuvent être très virulentes soit par pure méchanceté, soit avec un but particulier. On peut faire l'analogie avec les créateurs de virus : ils ont un pouvoir de nuisance énorme et pourtant on ne leur donne pas les clefs du système, et ce qui protègerait actuellement kde serait la relative confidentialité du projet...
[^] # Re: Pas le point 2
Posté par Zenitram (site web personnel) . Évalué à 2.
- la Norvège : euh... L'avantage de la Norvège est d'avoir des très gros puits de pétrole pour la partie économique, donc bon, ce n'est pas un exemple (et en plus, ils sont très policés). Ils sont certes très démocratique, mais je ne vois pas le rapport avec ce que tu cherches à décrire.
- kde : Tout le monde a accès au CVS? Comment ils font quand un gars veut un menu "nouveau" pour KDE4, et un autre veut l'ancien style? Ca commit en permanence? Il doit bien avoir une police... Ou alors KDE vit dans un merveuilleu monde bisounours où tout le monde est gentil et demande avant de commmiter? Je ne connais pas ce monde-la...
[^] # Re: Pas le point 2
Posté par Gof (site web personnel) . Évalué à 2.
> et un autre veut l'ancien style?
On en discute sur la mailing liste entre gens civilisés jusqu'à arriver à un consensus.
--
Étonnant que vous parlez de la Norvège car j'y suis justement en ce moment.
[^] # Re: Pas le point 2
Posté par Gniarf . Évalué à 3.
[^] # Re: Pas le point 2
Posté par farib . Évalué à 2.
Personnellement, je trouve qu'il y a beaucoup de bugs dans wikipedia. Certes, ils se corrigent, mais il y en a toujours de nouveau. Wikipedia, c'est un peu la trunk de dev mise en prod. Heureusement, que les plantages sont pas trop graves...
(attention, humour)
[^] # Re: Pas le point 2
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Y a pas de raisons qu'un patch soit intégrés après des plombs. Par exemple dans Mozilla, quand tu proposes un patch, et que tu demandes une revue, elle se fait dans les quelques heures ou jours, mais pas des semaines. Et ceci parce qu'il y a des responsables, des reviewers pour telle ou telle partie de code, et que la revue de code fait partie de leurs tâches (le code de mozilla est tellement gros qu'il n'y a personne qui connait suffisement bien *tout* mozilla pour pouvoir faire les reviews de n'importe quel patch).
bref, ton "ça va pas marcher" n'est pas vrai. Ça fonctionne dans de nombreux projets.
>Ça marche avec Wikipedia, ça marche avec KDE
Ouai enfin, la qualité des articles dans wikipedia est très très inégale. Et ils ne sont pas systématiquement toujours relus. Mais à la limite, on s'en fiche un peu, un mauvais article ne met pas en péril le projet. On ne peut pas en dire autant dans un projet informatique comme KDE : du mauvais code peut ajouter des trous de sécurité, des problèmes de stabilité etc... Je trouve donc ça hasardeux de comparer Wikipedia avec un projet informatique.
[^] # Re: Pas le point 2
Posté par Gof (site web personnel) . Évalué à 2.
Dans un projet comme KDE ou tout le monde est volontaire, certains patches peuvent rester sans réponse. Certaines parties du code n'ont en effet pas de mainteneur officiel, ou celui ci est absent ou n'as pas le temps pour répondre.
> Je trouve donc ça hasardeux de comparer Wikipedia avec un projet informatique.
Pourtant c'est pratiquement pareil.
La qualité des applications ou plugins dans KDE est également inégale.
Certaines sont très stables et d'autre moins.
Mais c'est un peu ça le libre non ? Des applications de qualité et d'autres moins, et c'est l'utilisateur qui choisis.
[^] # Re: Pas le point 2
Posté par Erwan . Évalué à 2.
D'autre part dans Mozilla aussi il y a des patches qui restent sans réponse pendant longtemps (il faut savoir "pinguer" la bonne personne sur IRC). Mais a mon avis ça vaut mieux que du code pourri committe sans que personne ne remarque. Ben oui : si personne n'a le temps de faire des revues à priori, j'imagine que personne n'a le temps de faire des revues à posteriori?
Je pense même que devoir réparer les bêtises de développeurs peu scrupuleux (genre qui hackent un truc vite fait sans réfléchir avant) doit prendre bien plus de temps que de faire des revues à priori.
Pourtant c'est pratiquement pareil.
Non, c'est pas pareil du tout. Ce serait pareil si, avec KDE:
* N'importe quel utilisateur aurait la competence et la possibilité de corriger un bug en quelques secondes (editer -> [modification] -> sauver)
* Corriger un bug dans un module ne risquait pas d'en casser un autre
Mais c'est un peu ça le libre non ? Des applications de qualité et d'autres moins, et c'est l'utilisateur qui choisis.
Oui enfin un projet est censé avoir une qualité assez constante. Et si un projet fait par un dev sur Sourceforge à zéro controle qualite, c'est normal, mais un projet de l'envergure de KDE se doit d'avoir un certain controle. Sinon c'est pas possible avec tant de personnes ! Mais ca m'etonne pas mal, KDE a certainement un certain niveau de controle par un nombre reduit de personnes pour chaque module.
De plus, si comme tu dis n'importe qui peut avoir un accès CVS et committer dans tous les projets, même quelque chose comme Konqueror n'est pas d'une qualité certaine.
[^] # Re: Pas le point 2
Posté par Gof (site web personnel) . Évalué à 2.
Certains développeurs de KDE travaillent en plus pour une distribution. Mais ce qu'il font pour KDE est sur leur temps libre. Et les employés de Trolltech sont payés pour développer Qt, et s'ils travaillent aussi sur KDE c'est également sur leur temps libre. Et en général, ces derniers participaient déjà à KDE avant d'être employés.
> * N'importe quel utilisateur aurait la competence et la possibilité de
> corriger un bug en quelques secondes (editer -> [modification] -> sauver)
N'importe quel visiteur de Wikipedia n'a pas les capacités pour corriger des erreurs. Soit je visite un article sur un sujet que je ne maîtrise pas, soit je ne connais mal la langue quand je visite des Wikipedia étrangères.
> * Corriger un bug dans un module ne risquait pas d'en casser un autre
En général c'est le cas. Corriger un bug dans une application ne risque pas d'affecter les autres. Sauf s'il y a intégration ou que c'est une bibliothèque. Mais on peux faire l'analogie avec les portails ou les template si l'on veux vraiment.
>De plus, si comme tu dis n'importe qui peut avoir un accès CVS et
> committer dans tous les projets, même quelque chose comme
> Konqueror n'est pas d'une qualité certaine.
Et c'est également ce qu'on critique sur Wikipedia. Mais dans la pratique, je remarque que ça marche.
Les développeurs savent en général juger leurs propre compétences et évitent de faire n'importe quoi.
Mais il est vrai que KDE n'as pas le niveau de qualité d'un bon logiciel professionnel. Mais pourtant il s'en rapproche assez bien.
[^] # Re: Pas le point 2
Posté par rewind (Mastodon) . Évalué à 2.
http://www.cornu.eu.org/texts/cooperation
http://fr.wikipedia.org/wiki/Coop%C3%A9ration-r%C3%A9ciproci(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.