Posts like these really show the problems in the current free software development world; balkanization between different stakeholders and bizarre processes that alternate between bureaucracy and anarchy. Watching the tug-of-war between Red Hat and Canonical play itself out in the form of dysfunctional community development process is depressing. I'm aware that watching sausage being made never makes you very hungry, but as a user of free software, I don't feel my needs are served very well by the territorial and political battles being fought.
What makes it even more frustrating to me is that not only are KDE, Gnome 3, and Unity all failing to cooperate successfully on shared resources, but they are all marching resolutely in the wrong direction, regardless of the pleas of the user community. So far as I can tell, everyone hates Gnome Shell, everyone hates Ubuntu Unity, and everyone thinks that KDE 4 has been a big mess compared to KDE 3. I see all of these projects as engaging in a slappy fight as they march together off the cliff of unusability and misguided redesigns.
I think to be fair to all three, you have to give them six months after they are actually released before we judge them. As is typical in OS Linux community, a very vocal minority is probably speaking up and "hating" all three. I would wager that the majority opinion is much different than what you hear from the vocal minority.
"Everybody" doesn't hate anything, perhaps all you hear are the people complaining. These projects are being accepted by various Linux users reasonably well. Any type of change is going to inspire some ire among longtime users.
And I'm afraid these types of conflicts happen in the non-free-software world, too, the most easy examples being recent stories about internal projects in Nokia and Microsoft. Things get messier when you want standards and interop.
This type of lazy thinking in generalizations amazes me. Inefficient at what? If you mean it's inefficient for rapid decision making, I wholeheartedly agree. If you mean inefficient at allowing people to express themselves, I disagree.
Fair enough - Open systems explore the landscape of all possible systems through diverse implementation and designs. This diversity sometimes leads to open systems finding the global optima, but even in less ideal circumstances the various different approaches reach a local optima for some subset of user needs.
Closed systems on the other hand try to reach the global maxima by analysis, design and 'vision'.
The original poster laments the competing implementaions, back stabbiness and ideologies. From my perspective that is how open source is supposed to work - people who are full of it trying to take their vision to its maximum limit. Competing implementaions and backstabbiness is not a modern phenomenon - bsd vs linux, emacs vs vi, xemacs vs emacs, n implementaions of scheme, n implementations of common lisp, ironpython/jython/python/pypy.
You bring up an interesting phenomenon: well-developed open source environments share a cut-throat competitive culture for consumer mindshare rather similarly to multinational corporations. I wonder if there is a scalability issue in human management where at some point we go berserk trying to define the mainstream.
As far as open source is concerned, it might be helpful to split the projects into two categories before examining their motives
1) Corporate driven projects. Here the need to reinvent might be due to profit based motives, or it could be because someone is trying to create work for themselves.
2) Volunteer driven projects. In this case I think it's the geeky need to understand things from first principle that drives the reinvention. The fact that for poorly documented projects the cost of reimplementation early on is comparable to rewriting from scratch doesn't help. Also large projects seem disorganized and bloated when compared against a new naive implementation with few features.
These problems might take forever to solve [as the organisations are large]... In the meantime, I wouldn't be surprised if someone came up with a better technology model as a replacement.
Id like to see a desktop development model more like modern web development - UI in HTML5/javascript/SVG, json data messaging, UI & system events coming from a port [eg. shinetech/eventserver], able to write small server-like plugins in Node.js / C / Ruby / lisp that can provide services and be remoted away from the UI.
Would be nice if some of this was reusable across OSX/Win/Linux. Perhaps my desktop work should be done in the browser?
The old unix guys might have approached it this way if they had the current web at hand to reuse/augment/embellish upon. Maybe this is more in the true spirit of unix than QT/GTK/Xwindows?
While everything's possible, HTML+CSS is a really horrible choice for UI description, and the whole webapp stuf is a kludge. Webapps are only done this way because there's no other choice.
Developers are running away to more higher-level abstractions, which provide things that are completely missing in bare HTML+CSS. For example, there are so-called layout managers, which are at the core of every sane widget toolkit, but in HTML world, are only emulated with plugins like jQuery.UI.Layout (or implemented it pure HTML+CSS by re-inventing lots of boilerplate code).
Cappuccino and SproutCore have a very good reason behind them.
I [obviously] disagree.. while HTML DOM may be a mess, I think SVG + Javascript is a really nice way to do UI.
The pain is almost all in the area of browser compatibility.
I kind of agree with your point, in that I think there is a layer missing [ eg. to make resizable UI work well ]. But I think that layer is best implemented in Javascript upon SVG/DOM.
As a comparison : I've used XCode's Interface Builder, and then thrown it away and written iOS UI Layouts by hand, and apparently Im not alone in this. Then I compare that to how much less code I'd need to write in Javascript for the same UI. [ I have implemented HTML5+js UI for iPad that looks like native Cocoa]
Dont get me wrong, I think Cocoa is a good traditional API. But compared to SVG+js APIs such as Cocoa/QT/GTK feel incredibly verbose, slow to iterate and brittle, IMO.
> But I think that layer is best implemented in Javascript upon SVG/DOM.
Could you, please, elaborate on this choice?
Why not, for example, Tcl/Tk? For a simple example, take a look at http://www.tkdocs.com/tutorial/firstexample.html. I doubt it would be simpler in any combination of HTML+CSS+SVG+JS (and, for example, it would be problematic to have system-wide look-and-feel)
With GTK+3 and GNOME3, there is a push towards a development model like you've described. GNOME Shell's UI is written in Javascript, the core is written in C. Themes are done in a CSS-alike language. DBUS (a cross-desktop standard that works in both KDE and GNOME) provides data messaging and your "UI & system events coming from a port." This allows daemons (your "server-like plugins") to communicate across programs, share data, UI elements, and whatever else you feel like communicating between processes.
One of the most important changes is the gobject-introspection work, which allows library authors to annotate their library's API in a way that allows bindings to be automatically created for any language. This is how GNOME Shell is able to use Javascript to call into GTK+3. Developers wanting to develop for GTK+ in their favorite language, be it Ruby, Python, Lisp, C#, D, or anything else, don't have to write bindings themselves or wait for someone else to write them.
Many new GNOME applications and libraries are being written in Vala, a language with an object model based on GObject but a syntax like C#. It offers a modern language with garbage collection, and everything compiles down to C in the end. The same compiler can also compile a language called Genie, which is designed to have a syntax similar to Python (although, in my opinion, it hasn't done a great job at that yet, and I've seen no use of the language in the wild). It also compiles down to C.
Tensions are high in the FOSS desktop world right now but that's nothing new. Flare ups like this come and go. Sometimes the problems are fixed and we find new ones to argue about a few years down the line. Sometimes the wounds fester, become gangrenous, and people leave for good.
Most of us just want to write code we can use and have fun writing.
Id like to see a desktop development model more like modern web development - UI in HTML5/javascript/SVG, json data messaging, UI & system events coming from a port [eg. shinetech/eventserver], able to write small server-like plugins in Node.js / C / Ruby / lisp that can provide services and be remoted away from the UI.
Sounds a lot like HP webOS (originally developed by Palm). They even include Node.js for non-GUI services.
Can anyone point me to a good architecture/dev overview of Gnome Shell and Unity ? I find it hard to sift out the marketing from the tech in what Ive seen.
GNOME Shell is the window manager (and some would argue a little bit more) for GNOME3. The GNOME wiki is a good place to start. A mostly up-to-date design overview is available at
https://live.gnome.org/GnomeShell/Design/
I'm interested to see how this ends up being resolved (I use Ubuntu, don't like Unity, and Gnome Shell looks to be just as bad) but have only been half-following this drama. This is a really great summary post.
I'm totally unsurprised that Shuttleworth's penchant for decision by fiat and Jobsian cargo-cultishness has driven a wedge between his company and others in the FOSS movement. (For example window controls, before windicators were announced: "Yesterday I decided to move window controls to the other side for our LTS. It's for a secret project. DO NOT ASK ME WHAT THE PROJECT IS."). But I'm also unsurprised that disorganization and what also appears to be at least a little ego and maybe even jealousy has warped things on the other side as well.
"My understanding of GNOME is this: GNOME does not have technical leadership – it hasn’t had clear technical leadership since, as I understand it, the creation of the GNOME Foundation (at which point, by design, the board was given a mandate to build and define GNOME, and then soon afterwards removed that mandate from itself). The foundation does not now dictate any vision or direction for GNOME."
This is a huge problem, as I see it. Even in OSS, where you have very capable people, someone needs to provide direction. I'm reminded of a military story, which I will paraphrase.
Single most important thing in warfare is to have a known objective. That way if the person in charge is killed, as is the second in charge, the troops still know they need to take that hill or everyone dies.
I take the same approach to software and it has worked my entire career. If Gnome doesn't have a stated vision/objective, it is no wonder it looks like chaos to someone outside!
Someone from Gnome _should_ step-up and provide some leadership, some technical direction, some market direction or some general foresight that things are going in the right direction. I hope the author is wrong and there is someone already doing this, but if not...
The key problem is that the desktop community desperately needs one or more architects who can act as a sheepdog and keep the sheep marching in roughly the same direction.
It's far more critical in the Desktop world than in the Linux kernel because in the kernel, there is enough development in the kernel that there is strong incentive to develop in the upstream sources, and not behind distribution-specific source trees. In addition, the Linux kernel releases on a regular 3 month cycle. So even if we don't have formal design documents, it's a lot easier for collaboration between key kernel subsystem developers, because our patches have to come together and _work_ every three months when we push out a release. (In practice, they had better mostly work by the end of the two week merge window, or there will be hell to pay, and Linus, as the great benevolent dictator, will yell at people, and Make a Decision --- which will usually involve reverting the change which broke things functionally.)
In contrast, the Desktop world has a much harder problem, because (a) not everything lives in one source tree, (b) the kernel largely doesn't have a UI, and there are objective measures of "does it work", and "did the benchmark results go up or down", that either don't exist or aren't as important in the UI world. Questions of whether a UI is "good" or "better" than some other UI choice is a question which can't be easily answered objectively. And that, more than any thing else, is probably why we have three major design centers for desktop development: GNOME, KDE, and Canonical.
One of the things that worries me is that all too often, people look at the way things are done in the Linux kernel, and assume that it will port over to their project. In most cases, the Linux kernel is a much larger and more complex project, and things which we do in the Linux kernel world probably aren't needed in other projects. But in the Desktop world, I think the reverse problem is true. It's a much larger and more complicated ecosystem than what we have in the Linux kernel, and so decisions such as allowing the major subsystem developers to negotiate major technical changes organically and informally might work for Linux, but not in the desktop world. (For example, in the storage stack, there are less than a half-dozen people I would need to consult with in order to come consensus about some change to accomodate PCI-attached flash, and we have multiple opportunities a year to get together and work things out). Hence in the desktop world, hiring a full-time architect who did nothing else but talk to the different stakeholders and try to come to consensus on a common vision is probably something which is necessary, even though we haven't found the need to have someone in that role in the Linux development community.
I'm surprised that no one here has yet pointed out that posts like this are a part of the self-correction mechanism present in transparent communities. Sure, it may be drama in the short term, but I think the fact that we know about these altercations is an important thing in and of itself. I would be highly surprised if this kind of drama didn't occur in the proprietary software world, but we don't get to see it and learn from it.
As a KDE developer myself, I have to admit to being very disappointed by the very first section regarding the development of the StatusNotifier specification. Dave complains that there was no problem statement, points out a quote relating to D-Bus, and somehow still entirely misses the point even after claiming to have read through the threads relating to the proposed spec.
The problem statement is easy: Have a way of separating notification items and applications, such that the notification item is part of the desktop and not part of the application. In other words, XEmbed sucks as a way to have notification items in a system tray. Anyone who has ever used e.g. GAIM in a KDE 3.5 desktop with a pixmap background knows exactly what I'm talking about, as GAIM's icon would show up as an ugly box with an icon inside, while the KDE application's would have a notification item with a properly transparent icon drawn.
Claiming that the entire idea was merely to hook up notifications into D-Bus is so far afield that it mystifies me completely, and claiming that no one has ever had issues because of this is patently false. In fact, the VERY EMAIL [1] that Dave quotes has an actual problem statement directly before it:
<quote>
In the past few months in KDE we worked on a new way to represent the systemtray icons to overcome the following limitations:
-lack of communication between the systemtray area and the items, that mean we don't know about their status, their importance of if they are being used or not
-the xembed process is quite slow and doesn't give control to the systray on the paining
-it's not possible to have more than one systray (useful in multi monitor setups)
</quote>
I know this because I actually bothered to use GTK+ and GNOME software even with my KDE desktop, but now I wonder if Dave has ever tried the opposite.
I also was passively watching the threads as they happened back in the day, and stating that there was disagreement due simply to lack of a problem statement would be flatly false.
Dave then goes on to accuse Aaron Seigo and Marco Martin of being obstinate in their positions by that point, which simply does not mesh at all with my memory of things. For instance, A GNOME Panel hacker named Frederic Peters mentioned that it would be nice to be able to merge launchers with notification icons [2], an idea that was warmly received, not thrown out [3].
In addition, given that the implementation changed several times during just the KDE implementation period, there would have been no major problems with even incompatible changes to fix problems. For instance Aaron Seigo in reply to Dan Winship recommending a different way to send notification signals over D-Bus mentioned: "yes, this is a nice idea for limiting the bus traffic. would require an incompatible change to the spec, but it is doable." [4]
I'll read the rest of the article, but if this is the kind of "uncontroversial" fact stating that's going to be going on then I'll probably just unsubscribe from the xdg list and get on with my KDE developing life...
What makes it even more frustrating to me is that not only are KDE, Gnome 3, and Unity all failing to cooperate successfully on shared resources, but they are all marching resolutely in the wrong direction, regardless of the pleas of the user community. So far as I can tell, everyone hates Gnome Shell, everyone hates Ubuntu Unity, and everyone thinks that KDE 4 has been a big mess compared to KDE 3. I see all of these projects as engaging in a slappy fight as they march together off the cliff of unusability and misguided redesigns.