in GNOME, Linux

Hobbyists & Hackers

Dave Neary wrote an interesting blog post yesterday commenting that the recruitment of new developers appears to be slowing.

I’ve had similar a similar thought on my mind for a while but coming from a different angle.

First though, revisiting Dave’s thought, he writes:

But it was a learning experience. Installing Linux was the period in my life where I learned the most about how computers worked, hardware and software. Back then, if you wanted to try out an application you heard about, there was only one way to do it – download the source code and compile it.

I had a conversation with Jono Bacon and Opportunistic Development (more on this in a different post) at the Linux Foundation Collaboration Summit two weeks ago that comes to mind.  Jono and I were talking about how kids in the 80’s had a chance to learn to program through BASIC, LOGO or other languages.  I remember using my first computer and buying magazines that had the machine code you’d program in by hand to create a game.  (Ok, I’m old).

But it leads me to an interesting thought about the evolution of younger users and how they are introduced to computers, becoming programmers and ultimately hackers or makers.

  • In the early 80’s we had the TRS-80, Commodore or Apple II (and later the Atari ST or IBM PC) computers and were encouraged to learn Basic or LOGO
  • In the 90’s we saw the beginning of Linux and other free software tools that raised a different generation of hackers.  We had the World Wide Web explode creating a generation of Web programmers.
  • And in the first decade of the 21st century, especially the second half, we saw the rise of the smartphone and the app store.

Dave asks the question:

Is it any wonder that recruitment of developers appears to be slowing, that prominent older projects are suffering something of a demographic crisis, with hoary old 30 year olds holding down the fort, with no young fiery whippersnappers coming up to relieve them?

(And I encourage you to read the comments on his blog as well).  I don’t know if that’s the right question – I think the fiery whippersnappers have more choices today for development – web apps, iPhone or Android apps, Linux and more.

For the GNOME community specifically, I wonder if we could make it easier for new developers or projects.  As an upstream project, I understand we don’t want to make it too easy and have a wasteland of abandoned projects hosted on our infrastructure, but I also see innovative new projects like Zeitgeist or Getting Things GNOME! using Launchpad instead.  I think the recent Zeitgeist proposal highlights both the benefits and challenges of using one or the other platforms for development.  I don’t know what the answer is, but I’d be curious to hear the communities opinion on it, whether it’s opening a GNOME branch on Gitorious or other ideas.

From whatever direction you come at these questions, it is an interesting challenge to have.

  1. The number of Open Source projects in the world has grown tremendously over the last 10 years. Perhaps the slowing rate of new developers in a specific set of projects in simply due to the number of projects growing at a faster rate than the number of developers is growing.

    So far as GNOME, at least from my perspective the biggest issue is that it feels like a technological dead end. GTK+ is light years behind Qt in functionality and it clings to a disgusting mess of an OOP-style C API that I wouldn’t wish on anybody. The response of the GNOME project to that problem has so far been either to introduce a brand new language that no developer would have had any prior experience or exposure to (Vala) or to bind dynamic scripting languages to the core libraries and pretend that they’re actually up to snuff as large scale application development languages (Javascript, Python, etc.), all while STILL failing to deliver on utter basic like a proper canvas library, official OpenGL integration, etc.

    Last but not least, the GNOME documentation blows. Sure, you guys have very complete and thorough API docs generated from the sources. That kind of documentation is not that useful though. A new programmer sitting down to develop an app is completely and utterly disinterested in looking up which function to call to set a specific property on some widget. The kind of documentation he needs is the HOWTO variety. Not so much a tutorial as just as a systematic top-down approach to building an application: what are the core GNOME modules, how should a modern GNOME application do its initialization, overview of file I/O, developer-oriented guide to designing basic UIs, how does the configuration system work, how to make applets or status icons, how to embed GTK-WebKit in a simple app for use as a canvas, etc. Raw API docs are only useful to people who are already deep into a library and need more information on a specific part there-of that they already know exists but can’t remember the specific interface for. When you’re totally new, the API docs are just a big ball of meaningless function prototypes… especially when the API is larger (e.g., more than 30 or so functions). Even if the individual modules are small and easy to understand, that still leaves out the whole-system approach. Knowing how the dconf API works for example is useless if you don’t know how that is supposed to plug in to the other 10+ modules you need to use to build a real application.

  2. i have found no difficulty in greping with google code search or browsing

    The docs are awesome =) some of the modules do not use all available new features and that’s a pitty.

    about your bragging about “lightyears” behind/ahead. Where is the symbols table for all Qt & KDE libraries? Oh right you have C++ and horid symbols mangaling which is unmaintainable…….

    Also are you expecting me to use svn to contribute to KDE? I have never used that…….

    So it’s all relative =)

    I understand C code and gtk is very clean & lean to understand.

  3. Dmitrijs,

    I disagree with your reply and mostly agree with Sean. I believe that GNOME can do better with what it calls its core API. I’m not exactly sure what the answer is at this moment, but I agree that OOP C is very disgusting. I try and avoid using it whenever possible. What I’ve found usually is that when someone seems to really like GObject based programming is when they learned to program in a procedural language like C and really don’t quite understand the power of design that languages like C++, Java, C#, Ruby, etc, that incorporate first-class OOP, can give you. I have a personal bias towards C++, but I’ve done plenty of work in Java and it captures the same OOP essence that C++ does.

    I think the doc situation has greatly improved in GNOME and GTK+, but like Sean says, I agree that there needs to be more tutorial-based docs out there. It is handy to have the Doxygen output of the modules, but it does not help you get started. Yes there is other source code out there to look at, but what I’ve found is that very large projects with large code bases contain examples of what I want to do, but it can be a pain to try and pinpoint the code that does a simple thing that you want to do. Maybe that becomes less of an impediment once one becomes more familiar with GObject programming, but for the beginner, which is who we are talking about, it is difficult.

    We need to constantly improve how GNOME and GTK+ do things, never settle for the status-quo. Just because our community is not a business and we don’t make a profit directly from what we do (though some of us do), we need to always push the innovation curve.

Comments are closed.