- The scope is widened to include more as part of core GNOME. This is to allow more control and integration to produce a better user experience.
- The project focus is being narrowed to have tighter requirements. This is to reduce support overhead and complexity.
- If we build the perfect OS in GNOME it will not be enough. History is littered with better products that fail to succeed. Making an OS successful is as much about the OS design and quality as the ability to deliver that OS to end users.
- If we base all our decision making on "what user visible change does this have?" then we risk losing innovation in our platform. End-users are only one type of user in an OS and not all changes are relevant to them. We have to think more in terms of "will this have a bad effect on end-users?" and look at other aspects.
- If we narrow our focus too much we risk losing some of our current community. The community is an enormous asset of GNOME, and not something we should take for granted. This is not a company, and is driven by motivated individuals (some of who are then employed by companies). There is great number of communities out there and GNOME needs to be competitive.
- If we try and control everything then we increase the burden of maintenance onto one project. There is no funding guaranteed to get us to GNOME 4. We should always look (within reason) for opportunities to collaborate with other communities.
UPDATE: Changed description of project focus, as it is confusing the point of this post.
19 comments:
Hi Robert,
For my part, I think Jon's call for a narrowed scope of support is exactly what is needed to focus limited resources. Gnome lives in an oxygen scarce environment, like somebody trapped under the ice in a frozen lake. Supporting all those different kernels is like punching and kicking at the ice in all different locations. Focusing just on Linux is like that person putting all their effort into just one spot try to break the ice, get more air, and be free.
Anecdotally, in the orgs I have worked at we have deployed Linux in numerous ways, but never BSD and rarely even Unix lately. I think Linux is the way to go -- the way to break through that ice.
As a lurker on the Gnome mailing lists, I assume your position on "user visible changes" comes from the discussions around GDM vs LightDM?
My view is that the developers aren't resistant to making changes that aren't user-facing - the Gnome 3 effort certainly included plenty of those.
But you're doing a lousy job of selling the benefits of switching to LightDM. A cleaner architecture is nice, but it's not something that benefits Gnome as a whole - only those hacking on the display manager component. And well, that's the people who wrote GDM, and would rather not throw away all their work because someone else doesn't like it.
I'd also suggest that your timing is poor. The Gnome developers have just spend several years making major architectural changes to their system to clean up the accumulated problems of the years. They're released their new version. And now you come along suggesting they're unwilling to innovate in the platform? Seriously?
To be very clear, this post is not about LightDM or any any other work I am doing in GNOME. This post is about changes in the GNOME project and the effects they may have.
The concern I have is that we are choosing direction without thinking though if this will achieve our goals or not.
One of the problems I have with the “scarce development resources” argument is that development resources aren't fixed. By expanding the scope of GNOME I fear that the pool of development resources will contract - there's less scope for shared infrastructure and so turn off people who would like to help GNOME but don't have it as a primary focus.
I think Deja Dup is a (still potential) example of this - if you read the proposal thread, there's a strong sense that it either becomes entirely assimilated or not at all.
There's clearly still debate amongst GNOMErs about what “GNOME OS” actually means, but if it comes down too far on the restrictive side I think it'll be a huge loss.
> "what user visible change does this
> have?" then we risk losing innovation
> in our platform.
I literally have no idea what the point of this paragraph is. The desktop user driven improvements of GNOME Shell (and Unity) and the sysadmin driven improvements of systemd in the last 12 months really put your point to shame.
As an experiment I also did s/GNOME/Unity/ and your post continued to make no sense...
I think everyone needs to read the mailing list thread again. Some harsh comments from a few people but I am confident the conclusion will be a whole heap of dbus interfaces for system management (c-k replacement, hostname, time, language, etc). You love freedesktop standards, correct?
I think 95.5% of the controversy comes from the fact the first implementation of these services will be by systemd, and live in the systemd git repo. Non linux distros will need to write code to implement these interfaces, some linux distros will move to systemd out of a matter of practicality and I guess Ubuntu will just keep muttering to themselves about upstart until 12.04.
This is a bit over dramatic. My reading of the entire discussion is that kernel developers for alternative kernels who want to leverage GNOME tech can step up and code what is necessay to support the interfaces.
I think the linux kernel architecture porting work is a great parallel to think about. Do the people pushing things forward in the main linux tree have to be blocked by the ARM or MIPS port of the linux kernel?
The point of this paragraph is that a one-dimensional statement does not solve all your problems and may well limit your options.
Sure, if the result of the current thread about systemd (again, not what this post is directly about) ends up then that would probably be a good thing.
This post is about the direction of the GNOME project and how we solve current and future issues. Is GNOME going to be where we want it to be in five years? Do we even know where that point is?
A good thought exercise to determine how the bazaar will be affected by this move is just to ask: how much actual Gnome contribution really results from supporting those other systems (BSD, Unix, Solaris)? Are there any key features which have come about or which are maintained as an incentive to their maintenance? Every resource used has its opportunity cost.
Gnome is never going to become a big player on BSD, Unix, or Solaris. It should pick its winning champion and devote all its resources on maintaining and expanding that platform.
BTW, this discussion is in relation to this email string: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00439.html
That thread is related to, but not the driver of this blog post. This blog post has things I have been thinking about over the last year.
Yes, it is good thought exercise to consider if you are better off dropping something. But as raof points out, we do not have fixed resources. There are network effects. There are motivations for contributors. It's not simple, and it shouldn't be treated as such. Scope narrowing is also more than just about what platforms GNOME supports.
Also, please, please, please if you want to comment here please sign your comments. It is impossible to know if this is one or three anonymous people. Pretty soon I'm just going to drop fully anonymous comments.
Oh Jef, I thought you would appreciate the drama :)
Again, the kernel aspect is not the whole point of this post. In hindsight I should have dropped the "in this case Linux only". It's kind of confusing the point.
Dramas are boring...musicals are where its at! If you had written your post in rhyming couplet it would have been much better.
Anyways.. forget the systemd support of kernel as the specific case you want to. My point still stands.
Linux kernel development happens in the mainline and is focused mainly on specific hardware platforms due to developer interest. Hardwre like MIPS and ARM are "ports" of the mainline kernel which extend coverage to new hardware platforms based on developer interest in those platforms.
This is a direct parallel to what you see happening in GNOME. Mainline is focusing on key platforms and the door is left open for "porting" to for other platforms based on developer interest to do the "porting" work. Noone is holding anyone back or holding anyone down...but mainline rolls onward. If
It's not a breakdown of the bazaar model... it _is_ the bazaar model.
And this has been going on far longer than one year. What you are seeing has its roots in project Utopia.
http://www.linuxjournal.com/article/7745
People, many of the same people, have been iterating on implementation specifics around those goals for years. Goals which require better and better integration from the linux kernel up into the GNOME UI. What you are seeing now is the newest iteration of that work. Its the same work that has been going on for the better half of a decade. There is nothing new here...its an iteration on a process which has been devoted to killing sacred cows which are standing in the way of a very good linux desktop OS experience.
They killed my favorite cow a long long while ago. I mourned for a bit, but I finally got hungry enough to try one of the far less sacred hamburgers that were the result. And you know what, the hamburgers pretty tasty.
-jef
Jef, so your point is that you can focus on one target, move faster, and let interested parties do the work to catch up. Very much agree.
What we've being seeing in GNOME, unfortunately is the door is not being left open, but it is firmly closed, go home, we don't need your help anymore. Hopefully good sense will prevail and a model more like the kernel will emerge. Perhaps the language being used is a strategy to shake things up, then give some ground to open the door just a crack (and thus avoid a poor compromise solution).
Not sure, but I think it's worth discussing, and what effect it is having, and what effect it will have in the future.
(And the interesting side story is who has the authority to make big decisions like this? What do this say about GNOME governance?)
Great post, Rob!
I strongly disagree with your door is shut line of reasoning.
But to continue the kernel development analogy, i believe the grsecurity people would love to talk to you about how open kernel mainline is to some of the ideas they are interested in seeing developed further. Or the Android people about how hard it is to get something into the mainline kernel.
My point is... don't fall into the trap of making grass is greener comparisons. I hold up kernel development as a parallel not because its friendlier or more receptive...but because its really _not_ as receptive to ideas on the edges as you would believe it is. GNOME and kernel development are looking more and more the same to me as development culture as kernel and GNOME get tighter integration. And that is to be expected because their are more individuals working up and down the stack to make that tighter integration happen.
-jef
The door is certainly not yet closed but some comments we've been seeing appear to show some people moving in that direction.
I'm not proposing any particular model to work towards. We need to think carefully what our goals are and whatever model we pick is going to deliver them.
Eh? What difference does it make? If Gnome loses all of it's followers (like myself with the release of v3), there's no one to care what happens next.
If you limit the scope, you also limit the possible contributors.
The linux kernel did it the other way around; they increased the scope, and they got the corresponding contributors.
I see no chance of Gnome becoming a cathedral. A cathedral needs an architect. Gnome has zero leadership.
Lots of vocal people, some of whom are very talented, some of whom have the best intentions, some of whom have a lot of power at Fedora, but no leadership.
Whether or not this is a good thing is up to the Gnome community to sort out. It certainly doesn't look like Gnome is about to ask actual users what matters to them.
Ron and Anonymous nailed it. v3 is closing doors (3D requirement, Linux only, ...). That is the wrong direction.
Post a Comment