*Getting into Getting Things GNOME!*

(Edit: this is an old draft, now published for testing purposes)

This is the beginning of what I hope will become a multi-part journal of my adventure into contributing free software.  I thought I’d share my education, FWIW! 🙂

Part 1: Read The Flipping Manual(s)!

As a user of a great amount of free software, I often wondered what was involved in producing it.  I was aware of the basic process – or at least I thought, but not really much of the details.

Here’s how I kinda reckoned the basic process works:

My take on the basic process of Free/Open Source software projects

  1. Some people (usually one person) would start a project off, following their interest in some way.
  2. He/She would set up somewhere for software code to live (a repository) which would be available to anyone to download.  This, the source of the project’s code, would be what’s often referred to as “upstream”.  It’s where the goodness flows from.
  3. Other people interested in this software could also join up and contribute changes to the code.
  4. At some point, someone involved with a distributor/vendor like Red Hat or Debian would “notice” the project and be interested in packaging up the software.
  5. The upstream software would get duly packaged up and released into the distributor’s/vendor’s “downstream” repository.  Users could then install and use it at-will.

This only really covers the basic of software creation though.  What about bugs?  Even the best software has the odd bug or two.  What happens then?

There are two main places for bugs to be recorded:

  1. On a downstream bug reporting/management system.
  2. On an upstream bug reporting/management system.

Typically, users of the distributor’s packaged version of the software will report bugs with it on the distributor’s (downstream) system.  Why not on the upstream one?  Mainly because a distro (distribution) will contain an older version of the software that may, upstream, now be fixed of that bug.

When a distro user reports a bug, he/she is reporting against the distribution’s version of that software, not against that software in general.

Doesn’t this create a duplication of bug reports?

In a nutshell, yes.  But it’s better that the same bug is reported twice, than not at all.  Quite often duplicates relating to the same issue are recorded, even on the same system.  They are simply marked as such, with one bug record being the “master”, to which the others are link for reference.

Getting involved upstream

The project I chose to get involved with is Getting Things Gnome! – a Getting Things Done-inspired task manager application for the GNOME desktop.

My motivations to get involved were:

  • I like the GTD methodology – it helps bring focus and organisation to my working day;
  • I want to learn how to program in Python – a well respected and widely utilised programming language;
  • I want to see the gtg tool develop so I can use it more effectively; and
  • I want to contribute something back to the free/open source software community.


Expressing (and progressing) an interest

The first thing to do was to express my interest with a project leader.  From doing this, I received very supportive and constructive emails relating to ways in which I could contribute which suited both the project and me.  (a hat-tip to Izidor Matušov for enormous support and coaching in the early days).

Secondly, after receiving such great support, the thing I soon realised is that the responsibility to check things out really rests with me.  I want to be involved, so I should be the person reading the mailing list posts, reading related blog posts, reading the web site, reading the manual for hackers… You get the idea.  If you’re considering joining a software project, you need to read a lot to learn what it’s all about!

Finally, be prepared.  Prepare your computer to work in the best way possible.  Prepare your mind to be opened up to learning new programming techniques.  And prepare your attitude – you will be rewarded and pleasantly surprised by the capability and maturity of others who are already contributing to the project.

Getting involved in free/open source software is educating, inspiring, liberating and, most importantly … (I hope he doesn’t mind me stealing this line from his first email), “Don’t forget, hacking opensource should be about having fun!”

And it is.

Have your say!