Why I joined GNOME – fixing the clocks

Desktop Summit

Briefly – let me say it was great to talk to everyone I did at the Desktop Summit! I had a lot of fun. And thanks to Openismus for loaning us their offices for a successful introspection hackfest.

Clocks – maybe not so easy

So a little over 10 years ago, I wasn’t really a GNOME contributor. Actually at that time, I was becoming a Debian developer. I was making Debian run better on my (then PowerPC) MacBook, helping Debian/GNOME integration, and then after that moved into upstream GNOME where basically more interesting things happen than packaging (except for installers which sadly we haven’t pulled into GNOME and fixed yet, but that’s another story).

One thing I remember that really resonated with me a lot in 2001 was when Sun Microsystems contributed a Usability study to GNOME (the link there is obsolete, the study now lives here for the curious). Specifically, the section on clocks.

The usability study in general created a big collective realization for the GNOME project that we were basically just doing a lot of stupid and pointless things like having 4+ different clocks. That realization led to a big push for usability and simplicity, and you can find the results in things like Havoc’s preferences page and of course in the GNOME 2.0 release which followed.

A lot of Internet dwellers seem to interpret the cultural aversion in GNOME to excessive settings/preferences as us just being sadists, but what it really means to me is that there are real bugs to fix. And GNOME to me is really about that – people who believe in Free Software, but also making something usable and not buggy. Having a willingness to solve hard problems.

What does this have to do with clocks? Well, you see, it turns out clocks are a bit hard. During the Summit, Dave Airlie was complaining the GNOME 3 clock didn’t show the right time immediately after unsuspending, which honestly is pretty embarassing. Another example is leap seconds. If we can’t get the clock right, we should probably just give up =)

So I fixed it with a quick hack, but in reality there are other situations which the clock display needs to be aware of – for example, if the user changes the time via the Date & Time panel. We could bodge around this in userspace, but it turned out that relatively recently the Linux kernel had gained exactly the API we need. I spent some downtime after the summit working on it, the resulting bug for the curious lives here. One of the nice things with this approach is that when we’re showing an HOUR:MINUTE clock, we no longer need to wake up the display process once a second just to see if the system clock got set from underneath us, which is useful for power saving.

It’s just exactly the kind of thing that GNOME means to me – the tradeoff for us not working on supporting a combinatiorial explosion of options is that we spend our time making the core good. Are there more important issues to fix than the clock? Yes, but it’s a visible one and I was offline while traveling so it was something I could easily do then. Oh and also to continue to prove Linus wrong that no one uses Linux-specific interfaces by using them in GNOME =)

The transition from “them” to “we”

While a lot of large Free Software projects do have some sort of formal “membership” structure (e.g. for GNOME there is the foundation), in reality being part of a project is more about your mindset. It’s easy for anyone to complain from the outside about something – and then the project is “they”.

I think many people, even ones who have been in the FOSS community for a long time, forget that it’s often not that hard to transition to “we”. As long as you can point to some sort of contribution (that could be any of code, marketing, documentation, art), even just periodically. By contributing even in a small way, you make a fundamental shift from “they” to “we”. From consuming to producing.

One common problem though is that of those who do propose changes, is to start out with a controversial change. This is not the right way to do it – while you may succeed, it’s going to be an uphill battle. Start by contributing non-controversial things – in the mindset of many people working on a FOSS project, this builds up karma or goodwill. And it makes it far more likely the people involved in the project will listen to your concerns.

It’s pretty basic stuff really – but easy to forget apparently.