Journal Quand l'union ne fait pas forcement la force...

Posté par (page perso) .
Tags : aucun
0
8
fév.
2006
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(...)
  • # Novell a raison

    Posté par (page perso) . Évalué à 10.

    pour rappel, GIT le SCM du noyau fait par les dev du noyau ... a été fait en mode fermé avec une équipe super restreinte, puis l'équipe s'est partiellement ouverte et maintenant est totalement ouverte.

    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 (page perso) . Évalué à 10.

      Je n'ai peut être pas l'expérience qu'ont beaucoup de développeurs libre mais je plussoie ton argumentation.
      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 . Évalué à 2.

        C'est la théorie des leaders éclairés... Prenez la musique classique par exemple. L'écriture ne se fait pas à la manière d'un petit groupe de rock où chacun donne son avis/ travaille pour l'équipe. Un tout petit nombre de personne écrit/dirige pour les 200 autres, qui n'ont pas vraiment leur mot dire, ce qui n'empêche par de donner (parfois) des oeuvres magnifiques.
    • [^] # Re: Novell a raison

      Posté par (page perso) . Évalué à 5.

      Je suis plutôt d'accord avec l'argumentation. Mais le cas est légèrement différent pour XGL, enfin c'est ce que j'ai compris.

      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 . Évalué à 10.

        J'ai discuté avec l'un des développeur de XGL au salon solution Linux et son principal argument était le temps de développement qui est beaucoup plus long.

        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 . Évalué à -3.

      Je suis pas certain que GIT soit un excellent exemple ...
    • [^] # Re: Novell a raison

      Posté par (page perso) . Évalué à 9.

      C'est une attitude que j'ai tendance aussi à avoir.

      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 (page perso) . Évalué à 8.

        Si on y repense bien : linus a fait la même chose pour Linux. Il n'a commencé à parler de son projet qu'une fois que son truc commençait à fonctionner.

        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 . Évalué à 7.

          A priori, le problème ici est qu'ils n'ont pas commencé le projet de zéro, mais sont parti d'un projet existant.
          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 . Évalué à 10.

    De toute manière, chacun a bien le droit de coder comme ils le souhaite non ?
    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 (page perso) . Évalué à 10.

      entièrement raison, j'en ai marre de ceux qui chipotent. Du moment qu'ils respectent les licences du libre, laissons les faire ce qu'ils veulent.

      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 . Évalué à 3.

    Quand on spécifie un besoin et qu'on pose les bases d'une architecture, il est contre-productif d'être "le plus nombreux possible".
    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 . Évalué à 9.

    > Alors pour résumer : concevoir en commité est mauvais, concevoir en toutes petites équipes c'est bien

    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 (page perso) . Évalué à 4.

    Ce projet est bati autour d'un homme, qui a des idées, on le paye pour les mettre en oeuvre, l'objectif n'est pas de faire quelque chose de bien qui plairait au plus grand nombre, ou qui respecterait les concepts faisant l'unanimité (que nous savons etre faux), l'objectif est de fabriquer les programmes que Fiedman a dans la tete, parce que novell pense que ce type a une bonne analyse des problemes d'ergonomie...

    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 . Évalué à 10.

    Quelques rectifications : XGL c'est le backend OpenGl d'X, Compiz c'est le gestionnaire de fenêtre. le mail que tu cites abordes donc les problèmes de Compiz et non pas de XGL ce qui fait une grosse différence.

    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 (page perso) . Évalué à 2.

      - 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

      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 . Évalué à 6.

        Ses arguments sont destinés à justifier le fork de Compiz, pas celui de XGL. On ne peut vraiment pas dire que X.org fonctionne comme GNOME (regarde le nombre d'inscrit à la xdevconf, divise par 2 et tu auras le nombre maximum de personne qui aurait pu être impliqué), je doute que David Revman aurait rencontré ce type de problème. D'ailleurs ni lui, ni Nat n'ont servi ce genre de justification*.

        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 (page perso) . Évalué à 7.

    Je ne suis pas choqué par l'attitude de Novell.
    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 . Évalué à 5.

    Le libre c'est aussi le droit de s'organiser comme on le souhaite.

    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 . Évalué à 10.

    Dans l'échange que tu cite, il est question de conception et de prise de décision, je pense que "la communauté c'est gentil, mais ils préfèrent coder de manière "fermée"" est une (petite) exagération.

    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 . Évalué à 4.

      On peut parfaitement décider de "fermer" le dev d'un projet à d'autres sans pour autant le mettre dans une boîte noire hermétique. Il y a une différence de taille dans le rapprochement que tu fais avec Ben Googder, c'est que les plans et les sources étaient publiques.

      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 . Évalué à 3.

        Oui tu a raison, ce n'est pas le même problème que pour FF, et je parlais de façon trop générale du "design by committee".

        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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.