Novell vient de "publier"[1] de manière plus ou moins officielle de XGL, un gestionnaire de fenêtre en 3D pour serveurs X.
Cette annonce a eu plusieurs effets :
- l'effet demo : "ouaaaaah c'est bo je veux pareil"
- l'effet critique : "oué mais ca sert à rien" ou "oué mais l'autre c'est mieux", etc.
- l'effet perplexe : "Pourquoi n'ont-ils pas ouvert le processus de developpement ?" "Comment se fait-il qu'on soit au courant seulement maintenant ?" "Ca n'aurait pas été mieux de consulter les intéressés avant ?" etc.
Le dernier effet a suscité des réactions qui bien entendu sont remontés aux oreilles des développeurs de Novell s'occupant de Xgl. L'un d'entre eux justifie leur attitude au travers d'une longue argumentation [2], dont je vous traduis le résumé :
"Alors pour résumer : concevoir en commité est mauvais, concevoir en toutes petites équipes c'est bien, les logiciels avec une vision unifiée c'est bien, essayer de nouvelles idées cool d'interfaces c'est bien, du code libre au final ca pue pas, et bien sûr, pour Novell, ne pas vendre Novell Linux Desktop 10 est mauvais. Je ne penses pas qu'il y est quelque chose que nous aurions pu faire pour avoir du meilleur sans que nous ayons eu également du pire."
(Désolé pour la fin de la trad ;))
Bref, la communauté c'est gentil, mais ils préfèrent coder de manière "fermée" dans un premier temps plutôt que du perdre du temps en débats stériles qui n'amène à rien, sauf à des compromis qui n'ont plus aucun avantage.
Avant de commentez, lisez le (long) mail, il amène progressivement à cette conclusion que j'ai ici présenté de manière un peu brutal.
Perso ca me semble pertinent : ils appliquent le modèle de développement utilisé en entreprise (qu'ils reproduisent ici dans une entreprise, Novell), quitte à faire hurler les intégristes si c'est pas "open" et "communautaire" comme processus, mais au moins les résultats sont là. Moi j'aime bien ce point de vue pragmatique :)
[1] : http://linuxfr.org/~Dark_Schneider/20806.html & http://linuxfr.org/~tild/20805.html
[2] : http://mail.gnome.org/archives/desktop-devel-list/2006-Febru(...)
Journal Quand l'union ne fait pas forcement la force...
8
fév.
2006
# Novell a raison
Posté par Mouns (site web personnel) . Évalué à 10.
Je ne sais plus ou j'ai lu ou entendu cela, mais il semblerait que les reunions/commissions/groupes de travail augmente leur productivité de maniere significative jusqu'a 4-5 membres ... apres et jusqu'à 7 l'augmentation est de plus en plus faible ... à partir de 8, la productivité regresse de maniere exponentielle.
donc quand le comité doit "produire de zéro" un truc, ouvrir est une catastrophe de non productivité. par contre, quand il y a un existant solide, ouvrir permet de consolider et fluidifier les echanges puisque qu'il y a une base commune ou plusieurs petits groupes peuvent se former pour ne travailler que sur une petite partie de l'ensemble.
Ce que j'expose est aussi ressenti chez pas mal de codeurs réguliers dans de gros applis libres, ou beaucoup preferent discuter en privé, et fuient comme la peste les threads/listes où des personnes qui ne savent pas coder ou qui viennent d'apprendre essaie de les persuader que ce qu'ils ont fait jusqu'a présent ne peut pas marcher et qu'il faut faire autrement.
Cela se voit aussi dans l'inefficacité du management au niveau du projet Debian ( et je suis debianiste ). Debian peut etre vu comme une super commission de plusieurs milliers de mainteneurs. l'absence de leadership fait qu'il n'y a de release que quand les etoiles sont correctement aligné et que tout le monde est d'humeur a les considérés comme tel.
D'un autre coté, il faut voir l'autre pendant : trop d'utilisateurs trop tot. l'ouverture à tout le monde avant d'avoir un truc de réellement présentable, donne aux utilisateurs soit l'impression d'un produit incomplet et mal foutu, soit crée un engoument et génere des bug-report ou l'équipe de dev ne peut pas suivre ( le projet Mozilla s'est reveillé recemment pour des bugs génant que j'ai rapportée il y a plus de 2 ans et plus de 4 ans, je leurs est répondu qu'entre temps j'avais changé de boite et que je ne pouvais plus verifier ).
Donc, l'attitude de Novell comme de tant d'autres projets Open Source ( qui connaissait Zimbra avant l'annonce fracassante qui a eu lieu ? ) est tout a fait correct.
Release Often disait LBT à propos de son expérience, mais il ne faut pas oublier qu'avant de commencer à le faire, il a passé plus d'un an de silence entre ses deux annonces sur comp.os.minix pour pouvoir avoir quelque chose qui plaise.
[^] # Re: Novell a raison
Posté par Ludovic F (site web personnel) . Évalué à 10.
En effet il est bien plus facile de travailler sur un projet abouti (dans le sens technique), qu'un projet naissant qui pose énormément de problèmes d'organisations. Souvent un projet est mort-né pour la simple raison que ses développeurs ne sont pas d'accords sur les aboutissants.
Bref, il est souvent plus simple de démarrer un projet seul (en consultants d'autres personnes) que de se jeter à l'eau à plusieurs.
C'est pas tous les jours évident d'être développeur... et libriste :-)
[^] # Re: Novell a raison
Posté par kursus_hc . Évalué à 2.
[^] # Re: Novell a raison
Posté par Nicolas . Évalué à 5.
Ils ont fermé un développement qui était "partiellement" ouvert, et surtout ils se sont séparés de contributeur au projet (comme Zack Rusin)... ils auraient au moins pû offrir à certains contributeurs un accés aux sources.
C'est ce que je comprends, d'après la lecture du blog d'A. Seigo (qui n'est pas franchement objectif) :
* http://aseigo.blogspot.com/2005/12/wouldnt-be-it-be-nice.htm(...)
* http://aseigo.blogspot.com/2005/12/bit-more-on-xgl.html
[^] # Re: Novell a raison
Posté par omtonio . Évalué à 10.
Novell à commencer ce développement en étant Open Source et ils passaient beaucoup plus de temps à expliquer "le pourquoi du comment" au différents développeurs (notamment à ceux du projet Xorg qui avaient bcp de boulot déjà à coté) que de réellement développer et au final ils n'avancaient pratiquement pas.
Ils ont donc créer un fork de ces premiers développement (non Open Source) et ont passé quelque mois à fond dans ce projet et voilà le résultat !!!
Je suis entièrement d'accord avec eux car ils ont fait un super projet en peu de temps et maintenant qu'il parrait assez stable, ils le remettent en l'Open Source donc pas de problème.
Ce développeur estimait qu'ils avaient gagné 2 à 3 ans.
[^] # Re: Novell a raison
Posté par HappyPeng . Évalué à -3.
[^] # Re: Novell a raison
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
C'est le cas par exemple pour mon editeur XML wysiwyg basé sur Gecko, et diffusé sous licence libre. C'est quelque chose de complexe (validation temps réèl, hack de Gecko toussa) et donc, je n'ai pas de temps à perdre avec l'exterieur pour justifier mes choix techniques, pour justifier mes hacks sur Gecko, à répondre aux multiples questions qui ne manquerait pas d'y avoir sur un produit non utilisable. (inutilisable = questions pourquoi ça marche pas, forcement).
Bref, j'ai commencé à communiquer sur le logiciel qu'à partir du moment où on pouvait commencer à voir quelque chose d'utilisable, qui fonctionne "à peu prés". Mais je n'ai pas encore fait "la grosse pub" (cependant cela ne va pas trop tarder), car il y a encore pas mal de bug connu. Et j'ai pas envie d'avoir mon bugzilla pourri par des dizaines de doublons de déclarations de bugs.
J'ai fait la même chose aussi pour mon projet perso de framework PHP : j'ai bossé dessus tout seul, sans en parler à personne, histoire de bien reflechir sur les concepts que je voulais développer. Une fois que les bases étaient jétées, j'ai commencé à publier les sources. Et puis j'ai un peu plus de temps puisque le plus dur est fait, et du coup je suis plus receptif aux commentaires d'utilisateurs.
Bref, je pense que la façon de bosser de Novell est trés bien car elle permet effectivement une meilleur productivité.
Le seul problème peut être la review de code quand il s'agit d'intégrer des gros morceaux de code qu'on a développé ainsi en privé, dans un produit existant. Soit les responsables du projet font confiance. Soit il va leur falloir du temps pour valider le code produit et l'intégrer alors dans le tronc. (Par exemple, dans Mozilla, tout patch est revu au moins par deux personnes différentes : mes patchs pour l'editeur XML étant gros et complexes, une fois que je les aurais proposé, vont mettre quelques mois avant d'être intégrés dans le tronc, processus qualité oblige).
[^] # Re: Novell a raison
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Si il en avait parler dés le début, il aurait peut être subit des critiques, voir des moqueries "bouarf, c'est trop dur, ça fonctionnera jamais, c'est pas comme ci comme ça qu'il faut faire" etc.. Cela l'aurait peut etre découragé et on ne serait pas là à discuter de logiciels libres :-)
[^] # Re: Novell a raison
Posté par Aiua . Évalué à 7.
Du coup, les développeurs qui bossaient sur XGL se sont retrouvé dans la situation où ils n'avaient pas accès à la branche courante (puisqu'elle était en interne chez Novell) et n'ont donc pas pu faire de modifs puisqu'elles risquaient de faire doublon avec ce qui se faisait chez Novell.
Enfin c'est ce que j'en ai compris.
Dans ce cas là, on peut au moins critiquer Novell pour ne pas avoir au moins donné un accès en lecture aux développeurs qui travaillaient sur XGL avant qu'ils ne l'internalise (d'après ce que j'ai compris toujours, ils en ont embauché certains mais pas tous)
# Bah, sont libres non ?
Posté par Yth (Mastodon) . Évalué à 10.
Si eux savent faire comme ça, que ça a fait ses preuves, et qu'ils apprécient la manière de faire, il n'existe rien dans tout les préceptes du libre (encore heureux !) qui le leur interdit.
Je n'y vois rien de choquant...
Yth.
[^] # Re: Bah, sont libres non ?
Posté par Nicolas Blanco (site web personnel) . Évalué à 10.
Ils se font de la pub avec XGL sur leur site web ? Et alors ? Si une boîte participe de quelque manière que ce soit a un projet libre, je ne vois pas de probleme a ce que l'entreprise se fasse un peu de pub en parlant ou en faisant de la pub/com.
Y en aura toujours pour chipoter ("bouh, ils font de la pub, ils veulent récuperer toute la gloire, ils font croire que ce sont eux qui ont inventé XGL, patati patata") mais c'est pas de cette manière que ça donnera une belle image de la communauté libre.
# C'est une bonne approche
Posté par Pierre Tramonson . Évalué à 3.
Il faut au contraire avoir une équipe resserrée, qui pourra définir une direction plus précise au projet.
C'est à dire trier les besoins par importance/pertinence, faire les recommandations techniques, coder l'architecture / les briques de base.
Une fois le projet lancé il est alors temps de s'ouvrir pour recueillir les avis, critiques et contributions. Mais la direction du projet a déjà été fixée et elle doit peu bouger.
Là en l'occurrence je vois mal comment Novell aurait pu ouvrir le code à la communauté au milieu du gué (c'est à dire sans démo du résultat final), puisque leur réalisation n'est pas une application mais plutôt un composant technique.
# Développement & Entreprise
Posté par Prae . Évalué à 9.
Par expérience du développement en entreprise (pour la boite elle-même mais aussi et surtout pour des boites tierces), il est parfois mieux de faire du développement en petit comité restreint de quelques développeurs pour arriver à un résultat rapide. ("rapide" ne veut pas forcément dire "mauvais" ...)
Concevoir en comité peut - en général - demander du temps (réunir les autres développeurs, envoyer/réception des mails pour les concertations, etc...); Lorsque tu as un projet à concrétiser, le moindre retard est lourd de conséquence (pénalité financière en général pour l'entreprise émétrice du développement).
Que Novell est fermé temporairement le développement pour se consacrer sur ce dernier en lui-même et pas sur autres choses ne me choque pas; Puisqu'en finalité, ils sont arrivés à un très beau résultat et qu'ils le rédistribuent librement:
Et c'est surtout cela l'essentiel.
# ceci est un sujet
Posté par PloufPlouf (site web personnel) . Évalué à 4.
c'est une approche, qui a effectivement l'avantage de pas se perdre en palabres
et on vera si suse 10 trouve sa place sur le creneau du desktop, ce qui m'etonnerait pas pour avoir vu la demo.
# Y a une erreur
Posté par Jean Roc Morreale . Évalué à 10.
Le dev de XGL était ouvert et David Reveman n'était pas le seul dev actif sur ce projet. Vu le nombre de codeurs au total qui se tient à l'aise sur les doigts d'une main l'argument comme quoi les discussions et explications font perdre du temps ne s'applique pas ici. Surtout quand l'architecture globale de XGl est déjà pas mal définie et que les autres participants en connaissent autant.
Ce qui est regrettable ce n'est pas que Novell est offert à emploi à temps plein à David pour bosser sur son bébé, ça tout le monde s'en était réjoui à l'époque. Le problème est d'avoir pris le code sous le bras et d'avoir forker dans une chambre noire, non seulement en excluant les autres devs mais en ne leur donnant aucunes informations (ne serait-ce que l'existence du projet interne). Ils ont par là même perdu des opportunités de peer review par les rares autres types assez calé sur le sujet.
En comparant avec ce mail à propos de Compiz et en essayant de voir où les arguments en faveur de son fork pourrait s'appliquer à XGL, on se rend rapidement compte qu'aucun ne s'y colle :
- endless debate : ce n'était pas le cas sur la list xorg, à part les trolls de Jon Smirl appellant à tuer EXA
- design by committee : il était déjà fait
- design by very small teams : XGL chez Novell c'était un one-man show, au sein de Xorg c'était déjà une very small team
- l'ouverture n'aurait rien empêché vu qu'il y avait un consensus sur la nécessité de XGL
Il n'y avait pas à mon sens de raisons techniques et organisationnelles pouvant motivé un fork fermé, la seul raison compréhensible étant de s'assurer l'exclusivité des "wooow" en étant les premiers à en faire la démonstration.
Ce n'est pas répréhensible en soi mais le groupe des devs Xorg est déjà suffisament restreint pour diviser ses forces encore plus. Si chaque contributeur individuel ou entreprise se met à lâcher une bombe de code après des mois en solitaire, je doute que le dev général s'en porterait mieux.
Là dans la press release tout parait simple et sans douleur mais ça serait oublier le gros travail d'intégration et de ré-écriture qu'ont du fournir dave arilie et eric anholt pour intégrer le code de david reveman dans le tronc principal d'X.org.
[^] # Re: Y a une erreur
Posté par TImaniac (site web personnel) . Évalué à 2.
- design by committee : il était déjà fait
- design by very small teams : XGL chez Novell c'était un one-man show, au sein de Xorg c'était déjà une very small team
- l'ouverture n'aurait rien empêché vu qu'il y avait un consensus sur la nécessité de XGL
En même temps ses arguments se tiennent tout de même debout : rien ne te dis que se qu'il souligne ne se saurait pas produit : plus le projet aurait avancé et attirer l'attention, plus il y aurait eu de débats inutiles et plus la "very small team" aurait pu s'agrandire. Il y avait un consensus la nécessité de XGL, pas sur sa conception technique. Bref ils ont voulu "éviter des situations", même si elles n'étaient pas encore là.
[^] # Re: Y a une erreur
Posté par Jean Roc Morreale . Évalué à 6.
Il suffit de prendre EXA comme exemple pour voir que même si ça a trollé sur la mailing-list le travail a été poursuivi sans ennuis, permettant à d'autres devs que son créateur de mettre la main à la pâte pour accélérer le processus.
Et il y avait consensus sur la conception technique (XGL avait du code en 2004), le seul point de divergence ayant été la priorité et était le fait d'une seule personne.
* Voilà là seul réponse de Nat que j'ai pu trouver, à lire ainsi que les réponses :
http://lists.osdl.org/pipermail/desktop_architects/2005-Dece(...)
# Pas choquant du tout
Posté par Zorro (site web personnel) . Évalué à 7.
Les orientations de la plupart des grands projets libres, même à développement ouvert, sont presque toujours prises par le noyau dur des programmeurs autour de la machine à café. On l'a reproché à une époque à Mozilla (c'était même une des raisons du départ de Jamie je-sais-plus-quoi, si ma mémoire est bonne), les gens d'OpenOffice font pareil, pour Mandriva, on découvre des fois des trucs du jour au lendemain que personne n'avait évoqué sur la liste Cooker. Et les projets ouverts mais à une seule personne qui développe sont aussi fait quasiment de cette façon.
L'essentiel, c'est que les sources soient libres et dispo - et éventuellement bien documentées.
La GPL et l'Open Source, c'est l'ouverture des sources, pas du développement.
# Tant que ça débouche sur du libre, où est le problème ?
Posté par Cali_Mero . Évalué à 5.
Ca me rappelle un peu ubuntu et ce qu'on a pu en dire dernièrement, tout ça. Peut-être que ça dérange certains de savoir qu'une entité centrale prend des décisions critiques sur l'avenir du projet, quitte à ne pas chercher un vain consensus pendant plusieurs années...
Si on essaye de voir les choses de manière pragmatique, on met ça dans la balance avec le résultat final : les *ubuntu sont sans conteste parmi les meilleures distributions orientées desktop du moment, et on ne peut pas dissocier les deux. Et au final, la distribution n'en est pas moins libre qu'une autre...
A mon avis il en sera de même avec Xgl : Novell se donne les moyens d'avancer dans son coin sur le projet qui leur tient à coeur, qui est quand même d'envergure assez conséquente, et communique autour des résultats concrets obtenus au final. Eh bien qu'ils continuent, et merci Novell !
# Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par herodiade . Évalué à 10.
Ce qui est certain, c'est que sur le point de la "conception" (le design initial etc.) ils soulèvent un débat intéressant et qui mérite, au moins, d'être invoqué.
Très récement, le leader d'un autre très gros projet libre (Ben Goodger) faisait exactement la même remarque pour expliquer le succès de firefox.
cf. son excellent historique de FF http://weblogs.mozillazine.org/ben/archives/009698.html :
le succès de FF, selon lui, est surtout du au fait qu'il ai été (et soit toujours) conçu par un petit groupe qui tente de maintenir une cohérence et une vision d'ensemble du projet (bref, l'inverse de ce qui arrivait auparant, dit Goodger, lorsqu'on additionnait des "opinions" disparates pour aboutir sur des bloatwares mal fagotés).
Combien de gros projets, parmis ceux qui ont fait les beaux succès du logiciel libre, fonctionne sur un processus de décision collégial ?
Très peu. En tout cas pas Apache, pas Linux, pas Qt, pas Gtk, pas *BSD, pas MySQL, pas Firefox, pas Fedora, pas Mdv, pas Ubuntu etc. Il reste debian, mais l'efficacité / la productivité de leur (pourtant énorme) communauté n'est pas un modèle adéquat pour beaucoup de projets.
La plupart du temps, la méritocratie prévaut (ou en tout cas, les participants les plus impliqués, ceux qui écrivent le code décident).
Finallement nous sommes des hordes d'utilisateurs ou developpeurs du dimanche à réclamer telle ou telle fonctionalité, telle direction etc. Ça doit être un pression bien pénible pour ces developpeurs travaillant sur des gros projets.
Autant laisser le soin de concevoir et décider *à ceux qui écrivent le code* (et qui ne sont pas des esclaves au service de la "communauté" !).
[^] # Re: Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par Jean Roc Morreale . Évalué à 4.
Je me permets de citer Alan Cox :
"So if Fedora, Ubuntu and every other Gnome using distribution also start
doing tons of private development then trying to jam it all in CVS
afterwards how do you expect Gnome to develop when all these variants
suddenely try and get merged and all overlap and clash.
Do you want to have situations where people play games like releasing
one day earlier than the other so they can check their stuff into
CVS/Subversion/whatever to block the 'opposition' ?
Nor does the committee argument stand up. It is perfectly possible to
post in advance that "we are going to do this, we've created a temporary
alternate repository for the work and if you want to join in or help
merge stuff back as it meets acceptability please sign up"
Pour ce qui est de XGL (ouais parce que moi en tant que kde user compiz&gnome toussa etc... :p), je me rappelles qu'une des critiques récurrentes qui a conduit à couper les ponts avec XFree86 était l'aspect clos du dev. Alors si on généralise le fait de ne rien montrer pendant des mois je vois pas trop si on va y gagner.
[^] # Re: Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par herodiade . Évalué à 3.
Ce qui est un peu spécifique dans le cas de gnome, et diffère par exemple d'Apache/FF/MySQ/Qt/x.org ..., c'est qu'il n'y a pas un petit groupe qui design & décide, mais plusieurs (et ça, oui, c'est casse gueule).
Je rejoint la remarque d'Alan Cox pour admettre que ça n'est pas une situation idéale (et qu'il vaut mieux au moins prévenir lorsqu'on s'aprete à travailler un aspect susceptible d'interesser d'autres gens).
Pour l'histoire de la débacle XFree865 -> x.org, je crois me souvenir que les critiques concernant l'aspect "fermé" du développement concernait surtout les comptes cvs en écriture (et le droit d'intégrer des modifications etc.), en nombre restreints et controlés par une minorité plus vraiment active dans le dev.
Moi non plus je ne suis pas un utilisateur gnome, et le desktop en 3d ne m'intéressent pas, mais j'ai souvent été frappé par l'incroyable toupet de nombreux utilisateurs de ce projet, qui lancent plus souvent qu'ailleur des débats publics contre les décisions des devs de façon très violente (cf. la fatiguante Eugenia Loli-Queru, ou plus récement John Williams, et même Linus Torvalds), plutot que de remercier les devs pour l'outils qu'ils utilisent -- ou au moins leur foutre la paix.
[^] # Re: Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par herodiade . Évalué à 1.
Pour ce qui est de Linus, on a tous en mémoire sa récente intervention sur le thème "les devs gnome sont des nazis" non ? ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par Barbapapa . Évalué à 3.
[^] # Re: Seulement la partie design + meme remarque de Ben Goodger (Firefox)
Posté par Spack . Évalué à 2.
Car depuis le changement de licence, on n'en entend plus parler et on a l'impression que celui-ci a été abandonné par la "communauté OpenSource"...
Bon au dernières nouvelles donc, la version 4.5 est sortie mais apparement il n'y a pas beaucoup de mouvement... Alors qu'en est-il??
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.