GNOME Project suffering the NIH disease

When I first read about GNOME dropping support for BSD and Solaris, my impression was that this is a good idea to aiming to unify limit resources and get the work done. I was also excited about the idea of the GNOME OS. I think it is necessary to keep the big picture in mind when developing the different components. Previously Ubuntu was the only project that did this and it was also the reason why I started using Ubuntu. Because it made the different parts of Linux work together to achieve the big goal of a great overall system.

But then things started to go wrong. Instead of picking existing components and giving them the final polish like Ubuntu did before, the GNOME project started developing things from scratch without any apparent reason to do so. And even worse: incompatible to existing solutions. It started with the rejection of the appindicator specification implemented by Ubuntu and KDE. At that point it was not clear to me whether the specification was broken or whether the responsible people at GNOME were just ignorant.

Then came systemd. And it started to be apparent that unfortunately it was the latter. To my knowledge Ubuntu is the biggest deployment of GNOME and it is based around the Linux ecosystem. So dropping support for Ubuntu has nothing to do with unifying limited resources. Ubuntu is your target audience, so if you should try to collaborate with a project you should collaborate with Ubuntu. My opinion on that is that some Fedora developers were pissed that the Unity interface was exclusive for Ubuntu and instead of packaging it for Fedora they started making GNOME Shell exclusive for Fedora.

Next I read about the overlay scrollbars re-developed for GNOME. While the first reaction might be the developers simply do not want to use Ubuntu technology, I think the reason is different. The developer does not seem to have any antipathy towards Ubuntu and if we look at the project he developed the scrollbars for another explanation becomes visible.

But first lets take a step back. Lets take a look at the core of GNOME. By this I mean the programming language it is written in. It is C/GObject; plain C extended with naming conventions and libraries to allow modern paradigms such as object oriented programming and events/ observer pattern. From today’s perspective one might wonder why one should choose this over C++, which integrates most of the features at the language level. But back when the GNOME project started C++ was not mature yet which meant that your program might break with the next compiler update or even the next STL update.

Therefore basing your project on plain C was a good idea. But a few years back it became obvious that programming in C/GObject seriosly lacked behind more modern programming languages like C++, Java and C# for application development.

Unfortunately instead of moving the straightforward route from C to C++, which most of C developers took when C++ matured(that was about 10 years ago), Vala was born.

So instead of using a proven and mature foundation, a new layer of indirection was created to essentially provide the same feature set. Commonly this is referred to as the “not invented here” symptom. A more derogative phrase would be reinventing the wheel..

What is sad here is that being an open source project, GNOME disregards the biggest advantage of open source software, namely standing on the shoulders of giants. With open source software you can use take an existing solution and improve upon it. This way you get the base functionality as well as the bug fixes that went in it for free. If you would develop it from scratch, you most likely would have to fix the same bugs again yourself.

To sum up here is what GNOME is losing right now

  • 30 years of language and library experience by using Vala instead of C++
  • 5 years of deployment and bug fixing by using systemd instead of extending upstart
  • 1 year of development testing and design if they reimplement overlay-scrollbars
  • 8 years of foundation development that went into Eclipse, by developing Gnome Builder from scratch
  • but most importantly: the synergy effects by collaborating with others

Do not get me wrong, I am not saying that the GNOME solutions could be replaced by existing solutions – I am saying that by extending existing solutions the GNOME project and the free software landscape would be better off as a whole.

  • http://www.facebook.com/bertvandepoel Bert Van de Poel

    What you are saying is very true. I would also like to add another example where they messed up stuff, you can read all about it in this post: http://www.stefanoforenza.com/compiz-is-getting-rapidly-sick-of-gnome/ (it concerns how their strange obsession with gnome-shell is killing compiz)

  • Lucas

    Lennart has exposed the reasons why systemd was developed. It’s definitely not NIH syndrome:

    http://0pointer.de/blog/projects/systemd.html

    About the other points, they are fairly reasonable.

    • Anonymous

      in this post he explains the shortcomings of upstart. And he is most certainly right about that. But my point was that he should have built upon upstart instead of starting from scratch.
      Now Lennart would probably respond that it would be too difficult to add the new features, but the recent updates to upstart which actually add lots of systemd features to it prove this wrong. The bottom line is maybe the collaborating with others is indeed harder than working on your own. But thats plain NIH.

  • http://felipec.myopenid.com/ Felipe Contreras

    You lost me when you pushed C++ forward. Linus Torvalds has explained very well the reasons why C++ sucks. It might suit your needs, but there’s a lot of people who think otherwise.

    • Anonymous

      do you refer to this post of Linus? http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
      If so most of his arguments can be as well applied to Vala – in this regard it rather supports my point ;)

      But seriously, Linus might be right that plain C is more efficient where performance is the primary goal. But for GUI applications performance is not the primary goal, as they mainly consist of glue code to different libraries.
      And for a open source project with limited resources, the expressiveness of the language is also important – there is a reason why alomst everything in gnome is being rewritten in Vala now..

  • Pawlo

    @Felipe Contreras

    Linus was talking about kernel programming and not about desktop environments. Don’t you think it’s strange that Linus preferred KDE over gnome?

  • Pawlo

    You could also add MSOOXML to the list. When KDE and FSF openly said ODF is way to go, gnome foundation didn’t say a thing, but some people from gnome were leaning toward MS ugly format. I think the main culprit of gnome suffering from NIH is Icaza. He still has quite big influence on gnome and he’s working for MS. It’s in their interests to divide and conquer.

    I’m very happy such systems like Kubuntu and Ubuntu exist. They’re very user friendly which cannot be said about Fedora and gnome shell.

  • Nicolay Doytchev

    Absolutely the case. And the biggest deal of all are GObject and Vala. There are so many good reasons why one would go with C++ over making another language that it’s not even funny…

    In fact I am glad that Ubuntu chose to use Qt for Unity 2D as it is an ultra-mature and written in proper language toolkit.

  • Hans

    Say, how about talking this Shuttleworth guy out of Gnome and starting this whole GUI thingy anew? From scratch.