GNOME OS is unfortunately very loosely defined, but from what I can gather it's essentially controlling the entire stack that GNOME is to make a better experience and make it easier to work on the project.
What I like about this strategy:
- It's focuses on the users that GNOME is targeted at. We've had a strong direction since GNOME 2 days and the focus on features that these users need through design is the right way of getting there.
- It's dropping old desktop metaphors and moving to new ones. There are other desktops like XFCE which will continue the Windows 95 desktop metaphor and be successful with it; it's right for GNOME to move on and be more cutting edge.
- It downplays the value of GNOME as a "box of bits". The drum I'm banging at the moment is about sharing infrastructure. This is something GNOME has been very successful with in the past and discouraging this cuts off a lot of places where GNOME can get investment from other projects.
- It puts very strong requirements on distributors which they don't want to / can't meet. GNOME is not like Apple, it can't control the entire stack from hardware to sales. It needs to work with distributors or have a distribution strategy. Building a perfect desktop is not enough.
34 comments:
I like the definition of GNOME OS, and it seems to be a sensible way to spend upstream's limited development resources (limit the number of configurations etc). I also can't fault the idea that a tighter platform/OS will give a more coherent and polished user experience.
I take issue with your statement
It downplays the value of GNOME as a "box of bits". The drum I'm banging at the moment is about sharing infrastructure. This is something GNOME has been very successful with in the past and discouraging this cuts off a lot of places where GNOME can get investment from other projects.
GNOME tried this for the last N years, and what negatives did it get us?
* little contribution from some downstreams.
* forks of key system components (GDM, the desktop shell, nautilus, control center)
* stagnation
So now we are trying something new.
IMO the trajectory of GNOME OS was set around the time GNOME Shell was conceived, it is just a shame that by the time the definition was settled Ubuntu had already, well, Unity, ayatana, whatever it was called back then.
Hi John,
I haven't actually seen anyone show a direct link between the "box of bits" policy and this having a negative effect on GNOME. If anything, the history seems to show GNOME technology being the most successful of any desktop project and being widely used and developed outside of GNOME.
GDM, the shell, nautilus have not been forked to my knowledge, rather alternatives have arisen and the competition is more good than bad. (Can you show an actual connection with new projects and a reduction in GNOME developers?).
I think GNOME had stagnated due to the very success of the release policy that didn't encourage major changes. Shell reinvigorated GNOME development at the right time.
I'm not sure what your connection to Ubuntu/Unity is, but this article is written by a long time GNOME developer who wants GNOME/the open desktop to succeed very much. The points about sharing overhead apply just as much to any other project, including Unity.
"Competition is more good than bad"
When you reduce the number of resources from A to assign to B, it means that A has less resources, which is bad, even thinking that B could be good.
In brief, and to stretch your analogy, I think a box of bits works when the cost of keeping the bits working together is shared by all those people using the bits. Ick.
IMO the trajectory of Ubuntu pre-unity, and further confirmed by Unity and the last 12 months, demonstrated that strategy was not an efficient use of resources, there wasnt enough contribution to reinvigorate all the bits to keep up with competitors.
GNOME OS is a rather better use of resources.
Juanjo, you are making the assumption that there are a fixed amount of resources. GNOME is not a company with a fixed budget. It doesn't assign people to tasks. We are limited by only who we can attract. We can do A and B as long as the two tasks are distinct and attract different people.
About the value of GNOME as a "box of bits" I agree to you that it's important, but it's not the main goal. What I mean is I think that the goal of the GNOME project is to write a good free desktop for everyone in first place and, as result, the GNOME project produce a lot of components that could used by other people, which is great.
PS: BTW, I like a lot your blog. Thanks for sharing your ideas and opinions :-)
John, can you substantiate such claims? I don't think the GNOME community was spending any time supporting Ubuntu / Unity specifically and I don't think anyone was asking them to. The only specific thing I have heard change post GNOME OS is time has been saved by not supporting BSD.
I'd like to reassert this post is not really about Ubuntu at all. This is about the free desktop community can best achieve success and where we can work together.
Juanjo, thanks! I really appreciate hearing this discussion is interesting (I think it is so). I think the free desktop space is a really interesting place to be involved in, we're fighting a huge uphill battle, but it's a battle I'd love any of the desktops to win.
I totally agree the "box of bits" is not a core goal of GNOME, but there's a number of strategies open to GNOME:
1. The highly integrated model (aka the Apple model). In this we'd control all the software from the kernel to the applications. It can make an excellent product but it's very expensive to do. It's also a dangerous breeding ground for groupthink and not invented here syndrome. I'm worried GNOME is tending too much to this model without having the current or future resources to complete it.
2. The distribution model where you assemble bits and pieces from different developers. This model I think has shown itself to not deliver the quality required for mass adoption. It's my personal opinion that we're in the last phase of the traditional Linux distribution and moving to more of an OS model (GNOME OS has got it right here).
3. Somewhere in between the two where GNOME can have tight control of the user experience, but share everything else thus maximizing development into what makes GNOME, GNOME. This is really about standardization; Linux really has become the standard kernel, X is the standard display technology and GStreamer has standardized codecs. We can standardize more things like user management (AccountsService), display management (LightDM), process management (systemd) without compromising out user experiences.
Which claims?
* Stagnation of G2 seems self evident. Reasonable people can disagree on whether G2 was the peak of GNOME innovation and should be kept for ever, but it certainly was set in its ways.
* Lack of contribution (to core GNOME) from Ubuntu is demonstrated in the GNOME census
* Lack of involvement in G3 planning / design, etc is chronicled by dave neary and the series by jdub. Additionally I largely agree with the timeline posted here.
* Again, it is self evident that a single contributor choosing to hack on A instead of B deprives B of that contribution with all other things being equal. Can you provide evidence that this is not true in aggregate, that is can you show that the contributions to GNOME and Ubuntu have both increased enough to negate this the division of labour?
I'm not trying to make this about Ubuntu, they are certainly free to do as they wish, and I am a reluctant user myself. I choose to contribute upstream.
But it is not a full picture to discus contributions to GNOME without acknowledging the elephant in the room.
I also don't understand the relevance of thing you said about BSD. Doesnt that speak to my feeling that the negatives of GNOME OS have been massively overstated?
Additionally, I think it is difficult because you have skin in this game (LightDM), but I encourage you to check out the GNOME 3.2 shell + gdm tight integration and re-evaluate the statement
... standardize more things like ... display management (LightDM) ... without compromising out user experiences..
The GNOME 3.2 login experience is really without parallel.
Hi John,
Sorry, I should have been more specific. I meant the claim "demonstrated that strategy was not an efficient use of resources".
This assumes that a) GNOME has made a significant investment for this strategy and b) this strategy has not had a return worth the investment.
My gut feel is that the cost of a) has been overestimated and by not being open to collaboration you forgo any return in b) now or in the future.
The comment about dropping BSD support indicates to me the cost of this strategy was quite low (I find it hard to believe BSD support was difficult more than annoying for non BSD users).
The census shows consistently increasing development which is a good sign that this overhead is not sinking the project. Of course we wont really know until we look at these statistics a year after a change in strategy.
The census had some shortcomings that would have been interesting to see:
- Analysis of non code improvements, e.g. quality (perhaps using bugzilla), userbase
- How the company contributions were changing over time. If contributions from a particular downstream were small now but increasing we might be shortsighted in criticising contribution levels.
I'm pretty convinced that "all other things being equal" is not true - we have an elastic resource that can support multiple desktops. I think that resource is less elastic with regards to the harder low-level code.
I have no complaints about the login experience of GNOME 3 but I know this experience was not dependent on the use of the majority of GDM but just the top layer. Giving credit to GDM in it's entirety is kind of like saying the great integration of GNOME Shell is due to the X server.
GDM wasn't giving a great integrated experience for the other desktops, which is why LightDM exists. No-one wanted to write a new display manager, especially me (I would have modified GDM if I thought it could work). But I did and now we can share that effort.
To give an example where going it alone can hurt GNOME - if LightDM gets Wayland support before GDM then GNOME will have to spend time implementing that when they could have got it for free.
Well we seem to have reached the core of our disagreement.
My gut feel is that the cost of a) has been overestimated and by not being open to collaboration you forgo any return in b) now or in the future.
Basically I reject the premise that GNOME was not open to collaboration.
Unfortunately, the die has now been cast, the twin ships of GNOME and Ubuntu are on divergent paths that will take time to change course; even if a new course is agreed and all parties are willing.
I guess only time will tell.
John, I don't mean to say that GNOME wasn't open to collaboration but rather that to implement the GNOME OS strategy as it stands now it will become increasingly closed to collaboration.
And it's not just Ubuntu that can offer value to GNOME. It's KDE and XFCE and LXDE and Elementary and other future projects that we can't predict.
So far GNOME OS has just made many of the previously optional lower in the stack bits required, and no longer optional. And put GNOME shell on top.
WRT your point
GNOME OS strategy as it stands now it will become increasingly closed to collaboration.
Which bits do you feel are becoming increasingly closed for collaboration?
Things that make me see GNOME becoming increasingly closed to collaboration:
- The idea that for good integration all the components need to be under the direct control of GNOME.
- The push back against distributors customising the GNOME experience.
- The rejection of the "box of bits" use of GNOME.
As I read this and other posts coming up I really feel like I should attend the Linux Plumbers conference next time instead of GUADEC.
Sorry, I should have been clearer. I meant technical 'bits'. Not conceptual practices.
Which technical bits (or components as you call them) do you feel are becoming increasingly closed for collaboration?
Specific decisions that indicate to me GNOME is become closed to collaboration:
- GNOME Control Center not supporting modication of system options.
- GNOME not wanting themeing changed.
- The new feature proposal system that focuses only on user features and not technical ones.
- Suggestion that Deja Dup needs to become a GNOME only project to be part of core GNOME.
Hi Robert,
I honestly don't see what this list has to do with GNOME OS...
- GNOME Control Center not supporting modication of system options.
What are system options?
- GNOME not wanting themeing changed.
What does theming have to do with being an OS? Besides, that decision was made before the idea of GNOME OS even arose. (Also, 'GNOME' does not want anything, *sigh*.)
- The new feature proposal system that focuses only on user features and not technical ones.
Being an OS doesn't mean you can't make changes for technical reasons, nor does the feature proposal process preclude making changes for technical reasons.
- Suggestion that Deja Dup needs to become a GNOME only project to be part of core GNOME.
I'm pretty tired of those comments being brought up, tbh. I raised a question in the context of discussion. I wasn't pushing for a particular resolution and I actually made a real effort to be constructive. Really, I find it pretty remarkable that such a big deal is being made out of one or two very open comments that I made on a discussion list.
I think you'll actually find that I am incredibly open to collaboration, and have even worked with Michael on Deja Dup in the past.
- GNOME Control Center not supporting modication of system options.
For distros this is perhaps unfortunate, but it seems the distros hacked around this anyway. Not supporting Nvidia-crazy-controlcenter-breaksyoursstuff-applet or this-random-piece-of-whatever-thinks-its-systemwide is a very good signal however.
- GNOME not wanting themeing changed.
From distros or users? Distros do what distros do, but taking away user theme cutomization UI was the best thing that happened in several years. With my Thunderbird hat on I think it's amazing to have it down to two themes to test for (Ubuntu and GNOME) instead of 1000+ themes that people might be running. UI-testing-wize OSX is still the best platform to develop ui's for. How the UI will look in people's machines is very, very predictable.
- The new feature proposal system that focuses only on user features and not technical ones.
I still haven't figured out if I think this is a good idea or not. I think it needs to run for a cycle or two before we look for something else. It might be good for fleshing out new big pieces here early in the GNOME3 cycle before things starts to stabilize.
- Suggestion that Deja Dup needs to become a GNOME only project to be part of core GNOME.
I really want to see Deja Dup (or any kind of backup story) in GNOME. It is very unfortunate the discussion ended up being so much about hosting-details but I can sympasize with the notion that having one piece of the control center somewhere else completely could end up being problematic (both Ubuntu and Fedora who ship DejaDup by default hacked around this it seems though).
Also, could you explain how these things reduce collaboration? I honestly have no idea how you are making that connection.
GNOME Control Center not supporting modication of system options.
- GNOME not wanting themeing changed.
- The new feature proposal system that focuses only on user features and not technical ones.
- Suggestion that Deja Dup needs to become a GNOME only project to be part of core GNOME.
Hi Robert!
I think theming can be changed, we're just not pushing it. After all it's mostly css and javascript anyways, and there are many themes already available. The reason we aren't changing the themes is that the default look of GNOME is the brand from a marketing position. GNOME is GNOME when you use the default setup and not change GTK+ themes or any other such things. Secondly, it makes it easier for application developers to target the platform and have all apps look consistent. Most themes don't do a good job of that at all.
I can't comment on teh feature proposal. I don't think it was properly rolled out in my opinion and I think the whole setup is in flux.
The argument with backups is that we want to make it a part of GNOME internally, and so the name deja dup is pretty much meaningless at that point. It becomes a capability that is deeply embedded as part of GNOME OS. It's a completely exclusive contract. It might be still possible to fork it and have other systems use it. I am two minds of it myself, but that is the thought behind it.
Hi sri.
What does
"""
The argument with backups is that we want to make it a part of GNOME internally, and so the name deja dup is pretty much meaningless at that point.
"""
actually mean in practice? It seems like you mean "if your code provides core functionality that GNOME needs it cannot be shared", to which I'd vehemently disagree. GNOME already shares a bunch of infrastructure with everyone else and exposes some of it to the user - the Display control panel pane being an obvious example, where the user is interacting with multiple levels of the X stack.
I get wanting to produce an integrated, coherent experience. That's an excellent goal. I don't think it means that GNOME needs to assimilate every piece of the stack, though. You don't need to own all the code; you just need to be able to improve the bits of the code that don't currently work for you, and that's precisely one of the strong points of open-source anyway.
I don't think it's necessary (or healthy) for even core GNOME components to be tied with an "exclusive contract", as long as their maintainers are responsive to the needs of GNOME. Hell, GTK+ is about as core as you can get, and that's not in anyway exclusive to GNOME; it works on Windows and Mac, at one point formed the core of Nokia's linux phoneish UI, etc.
Hi Allan,
Sorry to pick on the Deja Dup example, the particular example isn't important, and I was just prompted for some cases. I don't want to imply that any individuals don't want to collaborate as I don't think that's the case at all. But our strategy/policies do affect how well we can collaborate.
To sum up what I see in the examples:
- It shows the GNOME product being treated as a whole unit which shouldn't be modified. This conflicts with how distributions want to and are using GNOME and how effectively distributions can collaborate with GNOME.
- It shows a trend for all components in GNOME needing to be developed inside the GNOME project. This cuts down the places for collaborating with other projects.
I think these are the logical extension of treating GNOME as an OS.
Even though GNOME doesn't have a formal strategy I think we can and should talk about the direction of GNOME (I wouldn't say "wants" though as there are always different camps withing GNOME). We have de facto standards, and trends that are worth talking about so we're aware of where we're going. I think going to a more integrated product and not having written down our strategy for that is a recipe for disaster.
Hi sri,
Yes, I meant more the marketing/brand side of GNOME. This is a major conflict with how distribution of GNOME has traditionally worked.
For GNOME to control the entire brand and behaviour is to make the distributions obsolete. And this would be a fine strategy if GNOME had another method of distribution. If GNOME could market directly to OEMs and get GNOME in the hands of users that would be a great strategy. But it's a pipe dream. The amount of time and money required to maintain a distribution and have those relationships is huge.
Unless GNOME can resolve this distribution issue it has to collaborate with the distributions. It has to understand they need to differentiate from eachother, and they need to modify some parts of GNOME. If GNOME is not flexible it risks it's preferred desktop position on major distributions. It will work as designed, but it will become a niche product.
Hi Andreas,
Yes I mean from the distro point of view. Dropping user options is a great move that reduces maintenance (and the options are not missed by the majority of users).
I think the reason OSX can do this well is they are both and OS and a distribution. Ubuntu is both an OS and a distribution (now). GNOME is becoming an OS, but it's missing the critical distribution part.
btw, I think you should make some actual hats so you can wear them at conferences :)
Hey Robert,
I think the reason OSX can do this well is they are both and OS and a distribution. Ubuntu is both an OS and a distribution (now). GNOME is becoming an OS, but it's missing the critical distribution part.
I think this is all too out there. Neither Ubuntu or GNOME can be quite compared to something like OSX, since Apple not only handles the distribution but they define the entire user experience themselves. GNOME doesn't do distribution and Ubuntu doesn't write its entire user interface from scratch.
A practical way of looking at it is that the GNOME developers have been working on it for over a decade now and the need to integrate more closely with the rest of the system only grows the more advanced it becomes. I still remember when automounting CD's was a big deal for a friendly user experience on Linux!
Ubuntu also moved from basically packaging Debian with the latest GNOME and an ugly orange theme to writing components like a new panel or even trying define API's applications should be using, things that were traditionally handled by the "desktop environment".
I think the GNOME OS approach will work better for the GNOME project since it's what motivates people to work on GNOME. I also think it will be mostly well integrated in distributions like Fedora, openSUSE, Debian and all the others that are not trying to define a completely new user experience themselves instead of collaborating on that with the GNOME, KDE, XFCE or other projects set up for that.
The GNOME OS approach is not optimal for Ubuntu, which wishes to take GNOME as a base but still heavily change it and the user experience. This is what essentially a fork and as such I don't see things getting easier any time soon.
For example, some of the great new features of GNOME 3.2 are the online accounts integration and the new contacts application, both designed to integrate well with evolution-data-server; meanwhile, Ubuntu is not using Evolution anymore. These conflicts will continue to happen in the future, it's just how it is with forks.
Hi Robert,
Feature-based development doesn't mean that modules have to be developed inside GNOME. GNOME has started using both Tracker and Folks in the current 3.2 cycle, for instance. (Woo hoo!) We've also seen lots of Telepathy integration work being done by the fine people at Collabora (yay for collaboration).
I agree that GNOME 3 is a more clearly defined product than GNOME 2 was. That's a good thing in my opinion (and is the outcome of a long-held aspiration by many in the project). Coherence, consistency and seamlessness are perquisites for a great UX, and we can only provide those things by having a defined product. This also gives the project a clear focus and provides contributors (many of whom aren't aligned with a particular distribution) with a common reference point. I also agree that GNOME 3 poses real challenges in relation to distribution. I don't pretend to have the answers here, but I do think that the ecosystem needs to face up to these challenges if it wants to be competitive.
There seems to have been a lot of misunderstanding about the Deja Dup discussion. The question I raised was specific to design and to Deja Dup [1]. It had nothing to do with the general rules relating to which module can be included under which circumstances. It upsets me that this keeps being held up as an example of Something Bad™ when virtually no one has even tried to discuss the question with me. I feels like I'm being heckled from the audience when all I really wanted was for people to join me on stage.
It seems odd that you are advocating the modification of upstream products by distributors as a positive goal that should be pursued. My understanding is that upstream collaboration delivers better (read: integrated, coherent) products that can be shared and collaborated on. Is there something I'm missing there?
[1] I would like GNOME 3 to have a backup facility, but I have absolutely no view on whether Deja Dup would fit into that role as an underlying technology. My question purely relates to the user visible part of Deja Dup - the UI and, to a lesser extent, its documentation. The question is simple - from the user's point of view, would it make sense to have an independent app inside something that is presented as 'System Settings'. Note that the working definition of system settings has been 'non-application specific settings'! Also note that there are no other app specific settings inside System Settings. :)
Haha, yes, the hats would be amazing!
Hi Allan,
The modification of upstream products is one of those necessary evils to work with distributions. The problem with the ideal of us all working together is then the distributions become interchangeable. They need to differentiate to compete (unfortunate, but the reality of economics).
We need to come up with a distribution strategy for GNOME, especially if we want this control.
The idea the OEMs will just come and use GNOME without any strong relationship and full time staff to support that relationship just wont work.
Some ideas:
- GNOME presents itself as an application to the distributions. It expects to be packaged as provided upstream and installed as an option in many distributions (this is where we seem to be drifting).
- GNOME picks a reference distribution and works with that. They put CD images on the gnome website and use those to present to OEMs. (probably would cause a lot of conflict but would be a good way to split the effort of an OS).
- GNOME starts treating distributions as upstreams and takes their platform and builds GNOME on top of that replacing the distribution branding. (more effort on GNOME, but lots of control of the experience).
Loads of people who work for GNOME do so for a distribution. You mention "They need to differentiate to compete (unfortunate, but the reality of economics).".
But the only think you think of is modifying upstream code. That's IMO a waste. There are so many ways to differentiate, mixing and matching different components will just make your life harder. Far far will you change the components? How would you maintain it?
It know it would completely go against what is practiced at Red Hat; upstream first.
Suggest rethinking your assumptions.
Robert,
Those distribution questions that you're talking about are precisely the kinds of issues that 'GNOME OS' is trying to address, I think.
The modification of upstream products is one of those necessary evils to work with distributions. The problem with the ideal of us all working together is then the distributions become interchangeable. They need to differentiate to compete (unfortunate, but the reality of economics).
Free Software naturally leads to collaboration on common upstream code bases, and that logic implies that upstream components should be distributed with as little differentiation as possible.
Additionally, if you're making a user experience and you want to make it great, that user experience needs to be designed as a single whole [1]. I don't think you could design a UX that is both great and intended to be chopped up and rearranged. This was one of the problems with GNOME 2 that GNOME 3 set out to correct, in fact.
And there are ways for people to build businesses around GNOME other than differentiation, such as providing support or incorporating additional services. Ensuring that GNOME is able to facilitate the latter is something that I would strongly support.
This is a good discussion to be having. Thanks for getting it started, Robert. :)
[1] Many of the design decisions that you cite as being evidence of this GNOME OS thing were really just about making GNOME good. I doubt GNOME being an OS or being a single product was really on the minds of the people who made them.
Hello, Robert.
Like me - oooooooold GNOME user since the 90's -, many people is feeling "betrayed" by some design decissions in GNOME 3... The main concept is ok, but certain ideas aren't.
The new Shell "behavior" is very good for tablets - even when touchscreens aren't properly supported now -, but isn't really productive when you use the Shell with many program windows - programming, monitoring servers, ...-.
With this model, you are forcing people to make their applications working with tabs, whatever the app is, if you want to use many windows in the same screen... Even the default shell behavior doesn't allow you to launch an app instance with a simple click - the "old" and universal behaviour -, and you must use the specific command "new window" in the left dock -with the 3.0 release even the dock must remain in the left side -.
Even in GNOME 3 devs threw away the classic menu structure - and specification - and made the "Application tab" ... breaking with the intuitive model of a classic and well known start menu, without a "migration" path from one concept to another. Do youi remember the KDE's new menu? KDE devs left the new as default, but users can use the classic KE menu if they want.
Too Apple-like, sorry. Now, about the lack of integration with other desktops...
The N.I.H. syndrome is deep entrenched in KDE/GNOME devs, specially in the GNOME side; we could remember the "libindcator" and sistem tray controversies, the NULL effort to cooperate with the integration of KDE apps in the GNOME environment when the KDE folks did the opposite many times, and other "problems"... Facts that made GNOME devs look like stubborn children that don't want to play if the other children don't follow their rules; this facts affect loyal GNOME users too, who feel neglected and dissapointed when we aren't heard by devs.
I don't need to tell you that K3B - an obvious example - is used by maaaaany people in the GNOME desktop, right?
GNOME 3 will evolve, polishing some annoyances, but the mantra "our way is the only one" is hurting the users and developers communities... You can't sell the GNOME OS concept to the people if you impose the "only this one or nothing" principle.
Post a Comment