This is obviously my personal opinion. Also, I don’t work for an open source / free software company.
The conscious split
On Nov 4 2010, Mark Shuttleworth announced:
The next major transition for Unity will be to deliver it on Wayland, the OpenGL-based display management system.
To me such an announcement implies a commitment of resources.
They also considered writing their own solution, but thought it was a bad idea:
We considered and spoke with several proprietary options, on the basis that they might be persuaded to open source their work for a new push, and we evaluated the cost of building a new display manager, informed by the lessons learned in Wayland. We came to the conclusion that any such effort would only create a hard split in the world which wasn’t worth the cost of having done it. There are issues with Wayland, but they seem to be solvable, we’d rather be part of solving them than chasing a better alternative. So Wayland it is.
About 6 to 9 months ago, Canonical moved from their idea that Unity at one point magically would run Wayland, to their own solution. Doing your own thing is perfectly fine by me. What I heavily dislike is keeping that complete change of direction a secret. There is no law against it, but hiding such things for a very long time makes me assume that I’ll never hear anything timely at all. I still have not seen that this decision was taken on technical reasons and it just removes the trust I had in Canonical.
Now, there an amusing call for GNOME and KDE to join Mir. Doing that to me would mean:
- To give away your copyright, something which the GNOME project is against
- To know that you not be consulted in decisions and big decisions will be made known 6-9 months after the fact
- To write and maintain yet another abstraction layer to make Wayland, X and Mir work
- To (seemingly) rely on LightDM (no GDM!)
- To likely switch switch distributions, as code upstreaming is not a strong suite of Canonical. Maybe Mir will work, but I expect loads of patches to Qt/Gtk+ for a Mir backend, as well as other components (accessibility, etc). I think this due to the amount of patches Unity required and the sudden code dumps that GNOME sometimes got.
- You’re working with someone consciously is ok with creating a ‘hard split in the world’
Mir seems totally out of the option. After the really public announcement of Canonical, I was expecting them to have invested resources into making happen what they publicly promised. Instead, that is not to happen, so that slack has to be picked up.
Development speed of Wayland
Some people (not me!) spend a few days investigating the current status of Wayland and what is still left to do. This as we only 6-9 months after the fact we know we had to do this ourselves.
Unfortunately, the various blogposts about the 6-9 months of hidden Mir work, plus the incorrect assumptions and statements made about Wayland have resulted in a various incorrect impressions that I see often repeated. To correct a few:
- There was already a lot of work done for Wayland
- Speed was not slow, there was just no timeline on when to complete the rest
Seems quite logical to at least wait for a 1.0 release and some adoption from distribution, but oh well - Supporting X, Mir and Wayland implies way more than just a “gdk backend” patch to Gtk+ and something similar for Qt
- Wayland does not do everything that X does, but Mir is lacking that and way more
Yet another abstraction layer is not really the preferred way of working in GNOME. Adds to the things that has to be maintained, plus you can only use something as much as your abstraction layer allows - Competition on this level is not good
See: yet another abstraction layer
Finally some progress
Anyone still thinking: finally some progress has really ignored that various GNOME applications already work on Wayland. Furthermore, we already had a port of Mutter. This all before we finally are allowed to know for sure to not expect any resources from Canonical towards Wayland.
Of course, it still is nice to be quicker to release something quicker than the other person. But let’s focus instead on providing something which works as nicely as the old thing. Including things as XSettings, XRANDR, keeping track of idle time, colour management, accessibility, etc. Competing with Mir is stupid anyway. If we make applications work under Wayland, it will benefit Mir as well. We could release something and call it stable, but easier if we release it when we think it is good enough. That will still be too early for some, but oh well 😛
If we’d known 6-9 months ago that we couldn’t have relied upon Canonical, we could’ve taken that into account. In my opinion, keeping that decision secret slowed things down.
Communication and GNOME
Now, I am pretty harsh towards Canonical regarding their communication. I think GNOME can hugely improve as well, though I don’t think that is really relevant. The “but you do the same” is just a bad excuse. I had big issues (especially after the work done for Ubuntu GNOME remix) that we still did not have anyone from Canonical/Ubuntu in the release team. If we had someone on the release team, we could still be bad at communicating, but at least there would be one person who should be knowing what was going on on both sides. I still think it would be nice (though do not think it is that big of an issue after all the heavily delayed statements from Canonical) to have someone from Canonical, but not sure if the person would ever be allowed to share anything, thus the benefit seems much lower.
PS: The release team bit is not new. I’ve said this initially privately, but also publicly many months ago, see release-team archives. GNOME does almost everything in the open.
I don’t think it would have matter a lot if Canonical had decided to stay with wayland. They would have assigned resoures to port compiz/unity to wayland instead of mutter/gnome-shell.
Getting Unity to work on Wayland is more than just porting Compiz. You also need to handle all the stuff I wrote about, e.g. accessibility and so on.
No, it’s even more ironic: Canonical switches back to QML and with QtWayland there already are proper Wayland wrappers for Qt. That project even has a (demo quality) QML based compositor: http://www.youtube.com/watch?v=jLiSEmtRvGs
So the foundations are all done, what would have been left for Canonical, is to cooperate with the Qt project and with Digia to finish that stuff. This all is just nuts. I really don’t understand why Canonical and Mark Shuttleworth are willing to ruin their reputation with this mess.
Just like to clarify some details.
You say the is “an amusing call for GNOME and KDE to join Mir”. From Chris’s blog post:
“Mir is about creating a library to make the most awesome Unity display-server-compositor-thingy. We’re not aiming to satisfy anyone’s requirements but our own.”
and
“Perhaps we’ll become so awesome that it’ll make sense for GNOME or KDE to rebase their compositors on Mir, but that’s a long way away. ”
i.e. there is no such call.
There is no hard dependence on LightDM. To use Mir you’ll need a display manager that supports Mir, much like a display manager will need to support Wayland.
Mir is not an abstraction layer. It’s a different display technology like X and OSX and Windows. There’s no additional abstractions planned to support multiple platforms other than the current Toolkit backend abstractions.
Thanks, I read “it’ll make sense” as that there is a wish for Desktop Environments to use Mir. I still disagree with most that is written by either you or others about Mir on Planet Ubuntu (I don’t really look at names). Abstraction layers are awful.
Also, if Mir is really an Ubuntu-only thing, I don’t expect much support from e.g. Gtk+ or other projects.
Regarding LightDM dependency: https://lwn.net/Articles/541150/
“it’ll make sense” IF “we become so awesome”. i.e. not by our definition but by GNOME and KDE’s. Still not sure where you’re getting the idea there’ll be an abstraction layer…
That LightDM code is a hack we did to test the system compositor. That’s why it has “lightdm” in the method names. It will be removed soon.
Wayland does not do everything that X does. So we’ll do things differently for Wayland. Eventually relying only on Wayland. If Mir is exactly the same as Wayland, then why does Mir exists. If there are differences, you need an abstraction layer for the differences.
Keep in mind that the following is predicated on the scenario “Canonical have done a bunch of work on Mir and it would now be possible for GNOME Shell to gain a bunch of features if it were to use the Mir compositor-display-server library”. You may not find that scenario likely, but that’s the scenario ☺.
If you’ve already got an abstraction layer for X/Wayland, then adding Mir and becoming X/Wayland/Mir isn’t going to add an extra abstraction layer; it’s going to use the same abstraction layer.
If and when GNOME has entirely drops support for X, and will only work when Shell is the display server, then you’d potentially need to re-add a Wayland/Mir abstraction layer to the bits of the shell which are client code – the settings panel et al. Shell itself would never need an abstraction layer because it is the display server.
You add support for Greaphicssystem, etc. to the toolkit which already has proper abstraction layers to support X11, Wayland, Windoes, OSX, etc.
For accessibility have a look at https://wiki.edubuntu.org/Accessibility/Mir
s/concious/conscious
Thanks, there are probably a few others still in there. Despite proof reading, typo’s + crappy grammar always slips in.
The paragraph header is the only one worth correcting since it’s right in the face 🙂
Theres no difference between how Canonical and GNOME Foundation (most Redhat people now), they work exactly the same, they do what they want and don’t care about anyone else. So why blame one if most opensource projects and companies does the same?
If you want a example, look at changes in GNOME 3.6. GNOME Foundation consulted someone 6~9 before about remove “LOTS” of features in Nautilus that lots of people still missing?
I don’t like how this Foundations and Companies does this decisions but please, stop to blame one or another when everyone just “do what they want”.
As I said, I don’t work for Red Hat, nor do I think “they do it too” is a good reason. Furthermore, the Nautilus changes were done in the open. Try again with better arguments.
Hey, sorry if my comment sounds rude, I am really tired of this and last weeks I had some problems with people that want a new distro release with old Nautilus.
I am agree with you, “they do it too” is not a good reason but someone must stop to do it first and I think that GNOME could be the first to start a better communication.
About Nautilus, yes, their changes were done in the open but… well, it was like:
1. William Jon McCann (from RedHat) wants to remove something because he don’t like, think is ugly or think is not useful.
2. Cosimo Cecchi (that is a very nice and good developer) don’t disagree and just review the patch.
3. Some (sometimes lots of people) disagree and ask to revert because they use, think is useful or don’t agree that is ugly.
4. No comments from William Jon McCann and Cosimo Cecchi, they just go ahead, commit and make Nautilus 3.6 a nightmare for some users.
Don’t beliave me:
* Use a list model instead of a tree model:
https://bugzilla.gnome.org/show_bug.cgi?id=676531
* Remove extra panes:
https://bugzilla.gnome.org/show_bug.cgi?id=676858
* Remove compact mode:
https://bugzilla.gnome.org/show_bug.cgi?id=676842
Theres much more, and also lots of comments if website from people that disagree with this is much more changes but William Jon McCann (from RedHat) just remove lots of useful features from Nautilus, ignore users complains and now we must make some hacks to have a better Nautilus.
If you want, I have lots of other examples of exactly same behavior in GNOME (eg. Empathy 3.6 and feature removal).
I respect your opinions but I am much more sad with GNOME than with Canonical because I expect this from a company not from a foundation/community.
I think the Nautilus changes should have been done in a feature proposal. That combined with GNOME being terrible at communicating. We do things in the open, but often don’t go further than working in the open. Tend to forget that some things should be announced and so on.
So in short: I agree.
PS: See also release team minutes for same point: https://mail.gnome.org/archives/release-team/2012-October/msg00136.html
To make this point again: it’s kind of reductive to say “William Jon McCann (from Red Hat)”, as if his status as a Red Hat employee means anything in the context of the change.
It doesn’t. Red Hat’s and GNOME’s relationship is nothing like Canonical’s and Unity’s. GNOME is not strategically significant to Red Hat. Red Hat’s top brass does not sit around having meetings and deciding on edicts to send down to the GNOME developers who work for Red Hat.
The GNOME developers who work for Red Hat are basically GNOME devs sponsored by RH. They have their GNOME commit privileges based on their status as GNOME contributors, not as RH staff. RH does very little in terms of setting direction for the GNOME devs who work for RH. It is one of the cases where RH basically hires people who are _already_ significant contributors to a project and gives them a paycheck to continue to be significant contributors to it.
Nautilus changes were known to the world the moment they were commited. And before the commits, there were bug reports with the patches. All of that visible by anyone with access to the Internet. And there were at least two months before the final release, so the changes were not even final.
The criticism was about the changes not having been included in a Feature Proposal.
Had those changes been kept secret, and suddenly released yesterday, right before the code freeze… then you would have a case.
Hi
I think that your comment on copyright is wrong, to quote “To give away your copyright, something which the GNOME project is against”. IIRC current Canonical contribution license agreement does not require anything like that, just broad licensing. It is _not_ the same CLA that people complained about years ago.
They say you retain your copyright, but Canonical is free to do with your work whatever they want, including distributing it under a different license.
I don’t see how that is not an assignment of copyright.
One key difference between the copyright assignment that Canonical had prior and the current CLA Canonical has now.
Project A under the old Canonical copyright assignment is forked into Project A+ and requires copyright assignment.
I can not create a patch and have it included in both projects without additional agreement.
Under the current Canonical CLA
Project A requires CLA forks into project A+ with similar CLA requirements. I can create a patch that applies to both.
It’s subtle but its important because it keeps the full copyright rights with the contributor making it possible for the contributor to respond as needed to pretty much any potential situation that could arise with the codebase.
I am not saying the the current CLA is good. It’s not. It’s still a barrier to entry to contribution for many. But because it gives me full control of my contributions (even for forked codebases) it meets my personal requirement if in the future working as a contributor to downstream distributor I’m faced with the need to send a patch upstream and I’m required to sign the CLA.
But it is a marginal step forward from the full copyright assignment that Canonical previously had on its project. And I choose to celebrate that small shift, in the hopes it can be coaxed into a larger shift over time.
-jef
Are you sure Canonical would require copyright assignment for 3rd party work done on Mir? The current version of their contributor agreement says:
As said in the other reply, Canonical can relicense your work.
“We may license the Contribution under any license, including copyleft,
permissive, commercial, or proprietary licenses. ”
Seems a pretty clear copyright assignment to me.
No, that’s not what copyright assignment means. Whether I, as a copyright holder, have granted others the right to re-license my work is orthoganol to copyright assignment.
Yeah, a lot of people seem to have the idea that because Gnome is based on Gtk (or KDE based on Qt), they’re trivially portable to any platform those toolkits support. They’re overlooking the fact that both tookits provide only a fraction of the APIs needed to build a desktop environment, and that both desktop and apps still use quite a lot of X libraries directly.
>> and that both desktop and apps still use quite a lot of X libraries directly.
And how would they shed their dependency on X ? Any effort to move to truly move toward wayland/mir should involve refactoring that code. I know- we will continue to run against X-Wayland and pretend we are using wayland. And herein lies the problem for canonical- they are trying to improve the development life cycle.
Besides, I am not sure how a scenario of using X over wayland will play out for GLX dependencies.
Many of the points in your post are factually incorrect or misleading:
There is no requirement for copyright assignment in the Canonical CLA. Contributors retain copyright on their own works. Read it yourself: http://www.canonical.com/contributors
There is no way for this to “force” Gnome to rely on LightDM. LightDM is not dependent on Xorg, Mir, Wayland, Gnome, or KDE.
The issue about it being done in secret is BS. Many popular projects were started in secret months before being announced: Pulse Audio, Compiz, Linux Kernel, System D, et cetera.
Hi Matt,
I see you are using the ‘they did it too defense’. For one that is a poor argument to make and I already addressed the ‘they did it too’ in my blog. But my main issue is that initially one thing is publicly said, but follow up is not done and the change in direction is done in secret. Now compare this to e.g. the development of gnome-shell, idea was started at a hackfest. Commits started within a month in a public git repository.
I also never suggested that we would be forced to use LightDM, just that Mir seemingly relied on LightDM. You might want to read the comments, because I already responded to this with a clear reference and got a real clarification.
Regarding copyright assignment. Canonical mentions: “We may license the
Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. “. That is a clear case of copyright assignment to me.
Regarding factually incorrect: Please back that up. At the moment you’re stating this but nothing more.
Its clear that you are disregarding everything people are saying in your comments. For some reason you are holding Canonical to a much stricter standard than Gnome.
The CLA clearly says “The contributor continues to own the copyright in the contribution, with full rights to re-use, re-distribute, and continue modifying the contributed code, allowing them to also share that contribution with other projects.” Which is not copyright assignment.
The part that says “We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses” is called a license grant. Contributors keep their copyright, and give Canonical the right to license it under different terms.
I asked you to back up your claims. You’re not doing that at all. I also said that pointing towards others is rather poor form, yet you continue to do so. Meanwhile, you suggest that I ignore what is said here. Gives the impression that at most, what you’re doing is: http://en.wikipedia.org/wiki/The_pot_calling_the_kettle_black.
I’ve stated in my blogpost that I don’t work for a free software or open source company. Yet I get a real impression that you’re dismissing what I’m saying as ‘Canonical hate’.
Regarding CLA: Just because the thing is reworded as “relicensing” does not make GNOME’s objection to CLA’s go away.
Again about copyright assignment: I don’t see why you should be concerned with that. That would only apply if you contribute your GNOME Shell/Mir work back to Canonical, which I don’t think you would do (and Canonical might not be interested in GNOME Shell anyway).
Normally in a project if you want changes to be made, you contribute those changes towards the project. It is highly unusual to not do so, except for distribution specific changes. If making GNOME work on Mir requires changes in Mir, then the only solutions are either forking Mir, or contributing those back.
I’m really confused why you think this is not an issue.
Well, from the blog post you linked, it is pretty clear, “We’re not aiming to satisfy anyone’s requirements but our own.” and “We don’t intend to support re-implementations of the Mir client libraries, and will make no effort to not break them if someone tries.” so they don’t care nor want to expend the extra time of improving Wayland in a way that keeps everyone happy 🙂
This blog post on its own is indeed actually very clear. I read it at the same time as a few others, where they welcomed contributors.
So indeed, only Unity is wanted at this time. I prefer working a bit more in a freedesktop.org fashion though.
Wrt. a Canonical person on the GNOME release team: I don’t think that would have helped for this issue. As you said, any person that did know would have been under non-disclosure terms. Also, I’m not actually convinced that all that many people from the platform team (i. e. the guys who build the distro, package GNOME, etc.) knew about the full impact of this. E. g. I had been aware that Canonical was working on MIR for many months before the public announcement, but I had thought it was a reimplementation of weston and we’d use libwayland. I could have found out about this much earlier of course, but it didn’t occur to me to ask that question. 🙂