Smon a écritEn même temps dans le libre les mecs ne se bougent pas le cul si il n'y a pas un concurrent pour leur mettre la pression.
Exemple qui se sont bougés les fesses : Firefox avant l'arrivée de Chromium, le fork LibreOffice contre OpenOffice, Gnome Shell contre Unity, ...
Exemple qui stagnent : Gimp, Inkscape, scribus, thunderbird, ... Et comme par hasard ils n'ont pas de réel concurrent.
Et je suis entièrement d'accord avec toi. Sauf qu'aucun de ses projets ne font partie de la base commune qui définit la plateforme GNU/Linux. J'ai jamais dit qu'il ne fallait pas de concurrence, j'ai dit que sur le serveur graphique, c'est de l'intérêt de tout le monde, y compris d'Ubuntu, d'avoir quelque chose de standard développé collaborativement.
Smon a écritDonc le fork est logique.
C'est pas un fork, mais un nouveau projet indépendant et incompatible. Sur le long terme, je pense pas que ce soit une décision logique, c'est un pari, plutôt risqué d'ailleurs.
Mir n'est pas encore terminé. Si le processus de développement de Wayland est si lourd et prend autant de temps, c'est pas parce que les développeurs sont mauvais, c'est parce que pour avoir un bon résultat, il faut s'en donner les moyens. Canonical pense pouvoir faire mieux, en moins de temps et avec des gens qui ont moins d'expertise. Je serais vraiment étonné s'ils arrivent au même résultat que Wayland d'ici Mars 2014. Tant mieux pour eux s'ils y arrivent, mais permet moi d'en douter. En attendant, Wayland sera utilisable en production d'ici là, sans eux. S'ils avaient investit les ressources qu'ils mettent dans Mir sur Wayland, ça aurait peut-être même pu aller plus vite. Mais c'est sûr que ça aurait pas été sans contraintes.
Smon a écritC'est pas ce qui s'est passé.
1 - Google a voulu upstream leurs modification de Linux.
2 - Il se sont fait jeter par Torvalds parce que leur code était pourri et dupliquait une fonctionnalité.
3 - Ils ont maintenu leur noyau en parallèle le temps de modifier le code et de négocier pour la fonctionnalité dupliquée.
4 - Les noyau Linux "natif" est maintenant en pahse d'assimilation du code de Google.
Je te fais confiance là-dessus, je connais pas l'histoire dans les détails. Mais mon argument reste valide. Le fait de maintenir leur code en parallèle est très lourd et même Google, qui a une équipe de développement d'une toute autre mesure que celle de Canonical, cherche à utiliser la version upstream. Si Torvalds a refusé le commits, c'était pas pour faire chier Google, mais parce que c'était la meilleure décision à prendre pour la qualité du noyau. C'est le principe des projets développés collaborativement. Mais si l'idée de base est bonne, le code finit par être intégré, après que les problèmes mis en évidence ont été réglés.
Smon a écritIl y a quand même une grosse différence de densité entre un noyau et un serveur graphique ...
Comme le noyau, le serveur graphique est une brique élémentaire. Canonical n'a pas de besoin fondamentalement différent des autres acteurs pour ce composant, donc ils auraient tout intérêt à collaborer avec les autres, comme c'est le cas pour le noyau et pour la plupart des projets hébergés sur FreeDesktop.org.
