Operations and other mysteries

Andrew Cowie is a long time Linux engineer and Open Source advocate, repentant Java developer, Haskell aficionado, and GNOME hacker!

Professionally Andrew has consulted in IT operations, business leadership, and tries to help people remove the bottlenecks in their processes so they can run their technology more effectively


Twitter @afcowie

Google Plus +Andrew Cowie

Email 0x5CB48AEA

RSS Feed /andrew

java-gnome 4.0.15 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar.

java-gnome 4.0.15 (16 Mar 2010)

Radio things

This has mostly been a bug fix cycle with numerous internal quality improvements being made. A few developer visible API additions have been made, summarized below.

Unified radio handling

There are a number of controls in GTK that exhibit the “radio” behaviour of being in a group of which only one can be selected: RadioButton, RadioMenuItem, RadioToolButton and RadioAction. We originally had a class called RadioButtonGroup which was used when constructing RadioButtons to indicate which group they were a member of. In introducing overage of the other radio types, Guillaume Mazoyer implemented a generic grouping class called RadioGroup which is now used for all the radio types.

XDG utility functions

A number of utility functions (aka static methods) were added to Glib allowing you to access the various user and systems directories as specified by the XDG specification. These are Glib.getUserConfigDir(), Glib.getUserDataDir() and friends.

Miscellaneous improvements

Better control of positioning when popping up context menus; you can specify co-ordinates when calling Menu’s popup().

The no-arg “convenience” packing methods we invented for HBox and VBox were causing more trouble than they were worth because people we not understanding the implications of the “default” packing values. So these are deprecated; the full four-argument packStart() and packEnd() have been present for a long time and are to be used in preference.

Serkan Kaba spent a bit of time working with the text version of the ComboBox API. Apparently no one had needed removeText() so he added that.

A number of improvements to the coverage of GDK’s event masks were merged. This is work originally by Vreixo Formoso necessary to support the Widget.MotionNotifyEvent signal, though it has use in other applications. Widget now has addEvents() and setEvents() to this end.

Finally, Guillaume needed to handle selections in IconViews. The API is similiar to that in TreeView, but doesn’t use the same TreeSelection helper class; the methods are directly on IconView. Boo for asymmetry. Anyway, we’ve exposed isSelected() on both TreeSelection and IconView so you can find out if a given TreePath is currently selected.

Better initialization checking

Logic checking that the library has been properly initialized has been refactored, making it harder to accidentally misuse java-gnome when getting started [or when starting a new program after you’ve been using the library for years and forgotten the basics :)].

Last but not least, a number of bug fixes; one in Enchant was developer-visible; Enchant.requestDictionary() now returns null like it claimed to if you request an unknown dictionary. Nice catch, Serkan.

All the source files have the full (ie traditional) GPL v2 header text now; the files comprising the library as used at run-time have GPL headers text + the Classpath Exception text. Needed to be done. Makes for a large diff this release, but makes the Ohloh‘s page for java-gnome happy too :).

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.



Lovely Inconsolata

Federico writes that he’s recently discovered Raph Levien’s Inconsolata font and really liking it.

I likewise discovered Inconsolata not too long ago (it was packaged in Gentoo and I was really pleased to discover it also available in Debian), and have been using it as the constant-width font in Quill and Parchment for program listings in technical writing.

Parchment output showing Inconsolata font used for program code

We all tend to get obsessive about things we like, and so of course I tried it as a terminal console font. Interestingly, after a brief consideration, I decided not to use it for terminals and gedit and such. Deja Vu Sans Mono is still the king for that, especially if you’re using Deja Vu Sans and Deja Vu Serif for the rest of your UI; it means that the visual consistency across your desktop is really awesome.

gnome-apperance-properties Fonts tab, picking Deja Vu fonts

Inconsolata doesn’t have anything even remotely close to the kind of Unicode coverage you need in your full-time constant-width font, and when fontconfig does a fallback it looks awful because Inconsolata’s metrics are so different from others. That’s all ok; Inconsolata is meant for program listings, and looks incredible on paper.

Anyway, Federico noted that bold didn’t work when specified as a FontDescription, it doesn’t come up bold me either when I tried to do so via a bold PangoAttribute. But if you use Wouter’s Specimen, it shows up fine (on an Ubuntu box, anyway):

gnome-specimen showing Inconsolata font medium and bold

So there’s a bug in our stack somewhere.



Or not. I just reread the JavaDoc for the FontDescription constructor, and lo and behold relearned what I wrote there in the first place. To get bold Inconsolata you just need to use a ',' in the right place:

    desc = new FontDescription("Inconsolata, Bold 8.0");

and my Cairo drawing code on screen in a XlibSurface shows bold. Great.

But nothing is ever simple. I ran the same drawing code out through to a PdfSurface, and no bold. What the hell? There’s a bug in our stack somewhere. {sigh}

In my original post, I misattributed Specimen… it’s written by our very excellent Wouter Bolsterlee, uws on IRC. Sorry!

java-gnome 4.0.14 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources from Bazaar.

java-gnome 4.0.14 (16 Dec 2009)

You have to compose in order to enchant

Access to Enchant spell checking API

Coverage of the Enchant spell checking facade (which was already an implicit dependency arising from our GtkSpell coverage) is now included in java-gnome. It’s a lovely library with a simple to use API which in turn fronts for various back end spelling providers.

More detailed input handling

GTK’s handling of complex input methods is extraordinarily powerful, and of course present by default in the Entry and TextView text entry Widgets. If you’re doing your own text based work, however, you might need to capture the results of an input method being used to compose characters or words. InputMethod.Commit is where the result of a compose sequence is captured and delivered to the application.

We’ve also made numerous improvements down in GDK where events are processed; as a Java library we represent many naked low-level native entities with strongly-typed classes, and have improved our coverage here, notably with new Cursor constants representing the common use cases of changing the pointer.

Improved text rendering

Other minor improvements are present across the text rendering stack, notably with the ability to introspect where a Pango Layout has made its line breaks when wrapping via LayoutLine’s getStartIndex() and getLength() methods.

Guillaume Mazoyer finished up a work by Serkan Kaba resulting in us having coverage of the special LinkButton subclass of Button which can be used to present clickable URLs.

You can now create custom PaperSize objects, which is handy if you need to use Cairo to output PDF documents with a non-standard paper format.

Other changes

You can now use gdk-pixbuf to query an image on disk for its dimensions via Pixbuf getFileInfo() function calls.

There were of course miscellaneous improvements to various long established core classes, mostly fixing typos.

We now have the methods necessary to have ImageMenuItems actually show images (there’s a GNOME bug whereby suddenly icons are not showing in menus. So you need to either explicitly tell an ImageMenuItem that it should always show its image, or use the global Settings to say that Menus and Buttons should always have their icons showing).

The internal initialization sequence has been tweaked to ensure that GLib’s threads are initialized before anything else. This means java-gnome apps will work if glib 2.22.3 is installed; this is a workaround for bug 603774.

Headless testing

For a long time we’ve had to be careful in our test suite not to do anything that would cause a Window to appear or otherwise popup while the tests were running. But some for some test cases this is unavoidable, especially if the main loop needs to cycle. We now run the java-gnome test suite within a virtual X server (ie Xvfb), and as a result distros packaging the library can run the test suite on their headless build servers if they wish. There’s a new base class for java-gnome TestCases needing to run in this environment.

Looking ahead

What’s ahead for java-gnome? That’s always a good question. At this point java-gnome provides a comprehensive API for development of user interfaces suitable for the GNOME desktop, and it’s incredibly rewarding to see people using the library for their own programs.

Development of java-gnome has continued pretty steadily, driven by people finding they need additional features from some of the underlying GNOME and FreeDesktop libraries we already expose. As a community we also work to fine-tune the performance and quality of the library through continuous improvement of the code base and its algorithms. There are also people quietly working on experimental coverage of more unusual libraries such as GStreamer and Clutter which is pretty exciting to see.

Anyone using java-gnome are always welcome to join us in #java-gnome to ask questions or just hang out! So happy hacking, and see you soon.

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.



Get your icons back

We recently upgraded a number of systems, and after a few days the (previously happy GNOME users) started to notice the dialog buttons were all lacking their icons. How did that break? At first I assumed it was a bug in Canonical’s then pending Linux release, “Karmic”. But the problem didn’t go away, and suddenly I noticed a fair bit of email and bug traffic about the issue.

It turns out that someone removed the icons on purpose!

It didn’t attract that much attention at the time, but this setting was changed by the small group who maintain GNOME Control Center. They claimed that text-only interfaces were better. Hm. That doesn’t seem right, but interesting choice on their part. Fine. So you start hunting around in System -> Preferences to find the place where you can return your GNOME desktop to normal.

There isn’t one.

The usability of icons

In the GNOME community, we’ve gone to immense effort over the years to get people to use the proper stock GTK icons in menus and buttons so that the user experience is consistent across applications. They’re a significant cue that aids navigation. Meanwhile non-GNOME applications poorly ported from other platforms often violate this consistency (Eclipse {cough}). So suddenly lacking icons the entire desktop looked ghetto.

The whole debate about what the user experience should be was an interesting one, but it seems a user experience change of this magnitude qualifies as just the sort of thing we don’t do to the huge communities of people using our Desktop during a stable release series. We have GTK 3.0 and “GNOME 3.0″ coming up, and surely those would have been the appropriate contexts to propose such change, and the right place to trial landing it.

The part that really puzzles me, though, is that after the people who made this change were (politely) asked if they could point to the usability research that makes them think that text only menus are better, they (politely) replied with reference to a respected source in HMI design, Jared Spool. Reading that page it indeed says that text only is better than icon only. But right before that, however, he indicates that the combination of icons-and-text is more usable than text-only, with the further emphasis being that consistent positioning (ordering in menus) of those illustrative aides being what really what matters. Which seems to make it strange that text-only was just rammed down users’ throats.

Find out what’s broken and fix it

That they changed something is NOT the issue; at the end of the day it’s the people who do the work and write the software who set the agenda. But something this widespread seems like it ought to have been discussed on the usability and accessibility lists. And that’s the problem; there’s no mechanism requiring that.

It’s not the GNOME Control Center hacker’s fault that this became such a sore point for the rest of us; they were in a position to change something they wanted to change and so they did so. That’s just another day in Open Source land. But in GNOME there’s nothing that enforces the GNOME Human Interface Guidelnes. If a change like this had been proposed as a change to the HIG and if following the HIG was mandatory then clearly people would have had a good focused discussion about user experience, we could have come to a consensus (or “Usability Team” could have made a decision), the HIG documents would have been patched as a part of that, and then we could all get with the program.

The GNOME “Release Team” puts new module proposals through hell to be accepted as a part of GNOME, with endless discussions about what the user experience will be. Libraries underneath the desktop work incredibly hard to maintain API and ABI compatibility across releases. We try to remember that corporate IT departments just want gentle improvement between their upgrade decisions, rather than having to deal with a wrecking ball every six months. So we all know the importance of not screwing the user around.

But unless we find a way to apply the same rigour to maintaining UI standards like we do to managing the internal technical aspects of our platform, it seems we’re doomed to keep breaking the consistency of our users’ experience (and more to the point, jerking the chain of all the people who work hard to install and support the systems that our users run). How to do that while still enabling people to innovate is the hard part, but surely requiring people to follow the HIG and making that document the heart of user experience debate would be a step in the right direction.

Meanwhile, lets fix your desktop:

Workaround: users

The Control Center hackers removed the “Interface” tab from gnome-appearance-properties which is a shame since it would have been a lovely place for the user to say whether or not they wish icons in their menus and buttons.

It was pointed out that this is all still controllable by the user… by changing GConf settings. I think most of us would agree that is the very definition of what normal users aren’t expected to be doing.

The GConf keys are:




So to fix your desktop to be consistent with previous GNOME releases, you need to run:

$ gconftool-2 --type bool --set /desktop/gnome/interface/buttons_have_icons true
$ gconftool-2 --type bool --set /desktop/gnome/interface/menus_have_icons true

You’ll definitely need to repair your system like this if you’re working in applications such as Inkscape that have huge numbers of items in their menus; they become really difficult to tell apart if you don’t have the pictorial aides to help you identify the action you’re looking for.

Workaround: code

It turns out GtkImageMenuItem has a new property "always-show-image" for really important icons, ie where “the menu item would be useless or hard to use without it”. The idea is that application programmers using GTK manually need to call this for all the menu items where the icons is really important and you actually want the icon shown in the menu item (Given that you have to go some trouble to construct a GtkImageMenuItem rather than just a normal GtkMenuItem, I would have thought that that emphasis would have been a given. Alas). I just added a setter to java-gnome:

    quit = new ImageMenuItem(Stock.QUIT);

There are also GtkSettings "gtk-menu-images" and "gtk-button-images" which can be used to set the property globally in an application programatically or via .gtkrc:


Judging by the howls of protest, not too many people had noticed the importance of these properties, and so no one was setting it in their code. Assuming that the new default is likely to stand in the GNOME >= 2.28 era, then indeed we’ll all have to be doing this a lot.

Setting defaults

Thinking about this from the perspective of a bindings hacker and sometimes application developer, it all makes me realize the importance of exposing setters for properties, and calling setters even when the value you are setting is the default. It’s tempting to think “oh, I don’t need to call that method, it’s set by default”, but as episodes like this demonstrate, relying on defaults isn’t very reliable.


Getting a core dump

Sometimes things crash. This is the normal order of things, even if we like to pretend that Linux is so much better than its proprietary competitors. When a native library crashes underneath a java-gnome program, however, this isn’t so much fun, because the actual process which crashed is a Java Virtual Machine.

Usually I see with crashes because of something I’ve done wrong in binding an underlying GNOME library from java-gnome. So I bisect & printf() my way down until I can find the thing that causes it, read the docs, and hopefully figure it out.

Recently, however, I’ve been getting crashes somewhere deep in libpangoft when my the app is first loading or worse just sitting there and I’m not doing anything more onerous than moving the cursor around a TextView. This is still likely due to something I’ve done wrong in my code or in the bindings layer, but when it’s not happening deterministically or on demand it’s hard to even begin to analyze the problem.

The OpenJDK HotSpot VM (formerly the Sun HotSpot VM) has a pretty good SIGSEGV handler; it does its best to show you what the C library call was that died, and what the Java and C call stacks were leading up to the crash. You may have seen them around as hs_err_pid10733.log and such [I wish it would just spew that out to stderr instead of troubling to write a file, but anyway].

Strangely, the only line I’m getting when reading the crash report is:

C  [libpangoft2-1.0.so.0+0x17687]

no other stack frames. Which is a bit strange, and decidedly unhelpful. So I’m going to need to try a bit harder to get a backtrace, it seems.

Getting a native C stack trace of a Java program with GDB

Much as I otherwise feel GDB is the most horrendous user interface in the history of civilization (ok, maybe second only to GPG’s command line interface), it does do one thing extraordinarily well and that’s stack backtraces of crashed programs. These days one normally runs one’s program in gdb, induces it to crash, and then runs bt:

$ gdb ./program
(gdb) run
SIGSEGV caught
(gdb) bt

And you get your stack trace.

That’s a bit of a pain with a Java “program” because as mentioned the process running is a Java Virtual Machine (and because invoking java is … almost as bad as GPG’s command line interface):

$ java ... gobbledygook ... package.Class arguments

Usually people put their invocation line in a shell script along with various environment setup and so on:¹

$ ./script arguments

and off they go. The complication is that’s not really easy to use with GDB, since you need to invoke gdb on the binary executable (the JVM) and then, once GDB is finally up, tell it to “run” that executable with a bunch of arguments. Which means you’re back to the gory mess:

$ gdb java
(gdb) run ... gobbledygook ... package.Class arguments
SIGSEGV caught
(gdb) thread apply all bt

which is incredibly tedious for casual use.

But the old fashioned 1980s way of using a debugger is to get a “core dump” of memory into a file called core and to run GDB on that. Just set your shell to core dump, then go back to running your program as normal:

$ ulimit -c unlimited
$ ./script arguments
Aborted (core dumped)
$ gdb java core
(gdb) thread apply all bt

and our stack traces will spill out in great gory detail. Hooray!

Incidentally, if you want to play with GDB and see what a HotSpot JVM is up to, then you need to induce it to crash; one way to do this is to send it a signal, say SIGSEGV or SIGBUS

$ kill -11 10733

Yeay, Open

The real point here is that with Sun having open sourced Java and it’s HotSpot VM implementation, we can now build Java ourselves and include debugging symbols [on Debian Linux, for example, install package openjdk-6-dbg along with the symbols for the various libraries in the GNOME stack, libgtk2.0-0-dbg and so on]. This means, at long last, we can actually run Java under GDB — something we weren’t able to do when Java was proprietary — and get lovely backtraces when it thunders in.

Yeay for crashes.


¹ Which is why people put this invocation into a shell script, which makes it even harder to debug because you’ve got to run ps axww or whatever to try and get the full command line used to run the program. {sigh}, but fixing this will have to wait for another day.

² Bernd Eckenfels suggests avoiding SIGSEGV as apparently he believes this is caught in some places and rethrown as NullPointerException. I’ve never observed that, but I thought I’d mention his advice to use SIGBUS instead.


  • Josh Triplett wrote mentioning that he likes to use SIGQUIT to get his C applications to core dump, since you can trivially generate that signal from the console with Ctrl+. What he didn’t know was that Sun’s Java VM has always had a handler for SIGQUIT which prints a stack trace for each currently running Java thread (which is useful when trying to debug deadlock issues, but it’s the Java-side call stack only, not the native frames).

  • Mark Wielaard mentioned a nice trick to attach to a crashing hotspot JVM to work around any core file limitations:

    java -XX:OnError="gdb - %p" <arguments>

  • He and James Henstridge also note that having the “live, but almost dead program” around sometimes makes things a little easier on the debugger (as opposed to relying on a core dump). James suggests computers are fast, and just running all your [problem child] programs in gdb all the time. Fair enough, although in my case with such a hard to reproduce crash, I think I’ll wait on a core dump.

  • Mark let me know that on Fedora you can get debug symbols for any package you are trying to inspect. If you do debuginfo-install java-1.6.0-openjdk (in this case) it will pull in every dependent debuginfo package also! He also notes that this crash in question might actually be a Pango problem, and cites this Fedora bug.

java-gnome 4.0.13 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources, of course!

java-gnome 4.0.13 (27 Aug 2009)

Unicode. It’s bigger than you think.

This is a bug fix release to address a serious weakness in Java’s handling of Unicode characters.

Unicode handling

It turns out that Java’s chars are not pure Unicode codepoints. Most people know that Java String objects are arrays of Java chars, but in aggregate they are encoded in UTF-16 in order to deal with the fact that there are Unicode characters whose index is higher than 0xFFFF and which need more than two bytes to identify them. It’s a problem that an application developer has to deal with if they’re using high-range “supplementary” Unicode characters, but wasn’t something that would break java-gnome…

Except it turns out that the Java VM does not do UTF-8 translation properly. It has a hard wired limitation preventing it from writing out UTF-8 sequences longer than 3 bytes. Who knows what crack they were smoking when they decided that one. But things like TextView / TextBuffer work in characters, so we need characters. (actually, they work in UTF-8 bytes, but the offsets in our public API are the characters variants).

Luckily, we can get at the raw UTF-16 arrays backing Strings, and so in combination with GLib’s character set conversion functions, we’ve been able to redo our string handling internally so as to have correct treatment of Unicode codepoints. Lots of testing.

This surgery was almost entirely internal; Strings returned by java-gnome methods are of course still Java String objects.

New coverage

This release also features the work of Guillaume Mazoyer exposing some of the new features available in Entry Widgets, including displaying icons and showing progress bars in the background. This compliments other minor enhancements to various miscellaneous classes.

With this release, java-gnome now requires GTK 2.16 or newer.

This release is already packaged for Gentoo and Ubuntu, which is sweet.

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.



Where the weather is fine

One of the strange things about being a stranger here is trying to figure out what the weather forecasts mean.

For one thing, they usually say it’s going to be:



To me, that implies “hardly a cloud in the sky, bright and sunny, and warm. Head for the beach, yo!”. But it doesn’t seem to mean that here.

My Dad in Toronto a specialist in amateur weather data gathering. Yes, that means what you think, but he’s also a volunteer team coordinator in the provincial emergency management and disaster response organization, so I don’t mind him getting all excited about dark and stormy clouds. But Dad, could you maybe please just keep your eyes on the road instead of looking for the tornado anvils? Thanks dude! You’re a star. Now get me to the airport. I’ve got a plane to catch. Preferably before the tornado gets here.

So I’m always getting messages like “Good morning Andrew! According to crystal-ball-forecasting.com here, it’s a fine day for you today!” Well, thanks for checking, but he means “nice” and no, it’s not nice today, actually.

Since Dad is a weather nut, I’ve been paying closer than normal attention to the forecasts here. And there’s something strange going on: the weather forecasts don’t ever seem to have anything to do with the weather. I think the problem is that Crystal Ball Forecasting Inc get their data from the Australian Government’s Bureau of Meteorology, who appropriately enough seem to use a crystal ball for their weather forecasting. Don’t believe me? I shall now demonstrate.

The quoted portions are from the Bureau of Meteorology’s morning forecast on the day given, usually leaving out the part about what the wind was expected to be. Copyright © 2008-2009 Commonwealth of Australia in right of Her Majesty the Queen. The comments are from my emails conveying the weather forecast to my Dad on those days.

23 Sep 2008

Forecast for Wednesday:

“Cloudy. Isolated showers or drizzle but fine for the most part.”

What the hell is that supposed to mean? “Fine”? What are they smoking?

1 Nov 2008

How’s this for a weather forecast for Saturday night:

“Overcast with the chance of a shower, otherwise fine.”

So do I need a rain jacket or not?

10 Mar 2009

“Chance of a shower or two, more likely during the morning and then again at night. A cloudy morning, but sunny breaks developing during the day.”

Of course, it was bright and sunny all day.

3 May 2009

The forecast today:

Partly cloudy near the coast with a few showers, clearing later. Mostly fine with lengthy sunny periods in the west.

I would have taken that to mean it’s raining out west, except that would imply it was raining over the city’s water supply catchment area, which never happens. So they were probably right about it not raining there after all.

26 May 2009

The weather:

“Fine and mostly sunny until a shower or two develops”


2 Jun 2009

As at 07:30, the forecast for the day is:

“Cloudy with a few showers, and periods of light rain developing.”

I’m glad you clarified that.

19 Jun 2009

“A few showers. Cloudy periods. Morning fog patches.”

Since it is nice and sunny out, I think I’ll go out for a coffee in the park now.

15 Jul 2009

“Cloud increasing and a shower or two developing in the afternoon with the chance of a thunderstorm and small hail.”

Which is clearly why it is sunny out right now at the cafe where I’m sitting.

I gave them the benefit of the doubt, though: it does “change” here sometimes, so I most certainly brought my raincoat with me this afternoon when I went a wandering. Nothing to do with the Bureau of Meteorology; that’s simply a Murphy’s Law thing.

That evening

“A shower or two, with a chance of tsunami. Light to moderate south to southwest wind.”

Which admittedly is nothing to joke about, but given their track record…

4 Jul 2009

For once the official forecast was quite dull. So I improvised:

“Lengthy sunny periods, except for heavy morning showers, afternoon fog patches, chance of an evening thunderstorm. Possible snow overnight.”

Dad missed my note saying that I was joking; he simply commented “seems par for the course”.


There is a happy ending to this story, though: I finally found out what “fine” meant!

Apparently they’re trying to say:

“It won’t rain today”.

Pardon me for being underwhelmed.



James Andrewartha wrote in suggesting a page of terms used by BOM, including “fine”. Thanks! Doesn’t excuse the fact they’re still using the word differently than the rest of the English speaking world, though :)

One year and more

One of the things that saddens me is just how long it takes to write good code.

Havoc Pennington wrote a classic essay almost a decade ago about working on open source software. A lot has changed in 10 years, but his advice has surprising endurance:

Don’t start by launching your own project… it’s more educational to read and learn from other people’s code.

If you haven’t lurked and participated in a free software project, you won’t know how things are done and you’ll have an awful time trying to run your own…

If you do start a project, the all-important thing is to write code. You have to code enough to make the app useful pretty much by yourself; this can be months or years of lonely work…

When it comes down to it, writing a free application is a huge amount of work. If you’re writing your own, schedule 10-20 hours per week, at least… And schedule those 10-20 hours every week, for the foreseeable future. If you can’t commit this much time — don’t even bother starting the project. If you can’t write code, ditto.

It takes about a year

It takes about a year to write a serious application. A year! Sure, it’s easy to knock off a proof-of-concept or a mockup, but once you get down to the business of making all the internals actually work, ensuring it is well tested, and making it build for other people it all just becomes a long grind.

And frankly, that year is just to get far enough to know whether the thing is going to fly or not. It takes somewhere between two and three years to get a serious application to the point where it’s polished and well-rounded enough where other people are able to use it.

And as Havoc points out, then if your app becomes widely adopted you’re in for years and years of continued involvement.

Why on earth do we do it?

Writing software, writing poetry

This week a friend introduced me to Jacket Magazine, a poetry and literature periodical. Tons of cool & eclectic stuff. It’s published entirely online, and is clearly a labour of love. Early on the founder & editor, John Tranter, wrote an essay for the about page. The piece mostly focuses on the economics of periodical production and how the internet has opened revolutionary possibilities for the distribution of literature. Hot topics today, right? Not bad for a piece written in 1999.

The best part, though, was when he tried to describe his motivation:

The main cost is my time; which means I don’t get much poetry written these days. … it takes up most of my waking life. Why do I do it? Jacket is hard work, and I like hard work. I enjoy editing the poems and articles and taking photos of people and designing the pages, and I even enjoy writing the HTML that underlies the pages. Jacket exercises all my various talents – and it’s fun.

It has also enlarged my circle of friends by a factor of about ten. And I feel I’ve enabled a lot of writers to find a wider international audience for their work, especially younger poets. I received a lot of generous support and assistance when I was a young writer, and it’s good to be able to give something back.

10 years later, he and his contributors are still at it. Beautiful.

I’m not a poet, but the compulsive dedication that he talks about resonates.

I am ashamed to admit that of the five or so major software projects I have initiated since I returned to writing open source in 2002, only two of them have made it past the “1 year” proof-of-concept point, and only one of them has reached the “usable by real people” stage — indeed it has taken over 3 years, and that project is a library, not even an end-user application!

This emphasizes a point that the agile development community have been making for a while now — you have to get to the point of your app being usable by {you, your customer, whoever} as unbelievably fast as you can. If you’re not able to enjoy the fruits of your hard work, then you’ll likely reach the point where you’ve put tons of effort in and it’s still a demo harness that you can’t actually use for what you wanted to use it for. Live and learn.

Or maybe not :)

I’m at it again; I’ve got another one brewing, and it’s passed the 1 year mark. The competing pressures are almost overwhelming. One the one hand is the excitement that it’s starting to come together, and that drives me forward. But at other times there is intense frustration when I discover yet another bug and when it feels that the thing is no closer to being usable (by me, let alone anyone else) than it was months and months ago. Sometimes you just want to let it all go.

And I have no doubt that it will be at least two more years before it reaches the level of polish and general usefulness that is merely the starting point for other people to consider using this program.

What in God’s name am I doing spending time on this?


I was trying to explain all this to someone in a bar a few weeks back, and she asked that very same question.

Are you doing it to make money?

Well, no.

Then why are you doing it?

Well, the coding I do has paid off, at least sort of. Most of my software architecture work is consulting to large companies, but all the experimentation and new ideas that drive those engagements comes from my open source work. And some of my clients have found me through my public hacking.

Oh, so, it’s a promotional activity?

Well, I suppose it ends up that way, but that’s not why I’m doing it. It takes too much time to justify that way. Perhaps in the long term people will use my software and think well of me for having written it. Probably not, though; likely they’ll just bitch about how it doesn’t do this or that that they think it should. Doesn’t matter, I’m not really doing it for them.

Who are you doing it for?


For three years!

Hm, yeah, probably longer.

So you’re not going to make any money out of this, you aren’t building your reputation with people who hire you, and you may not ever finish it. Why are you doing it?

and I finally found an answer that made sense. The right answer:

Because it needs doing.

Needless to say that was pretty much the end of that flirtation. Apparently non-materialism isn’t sexy. :)

Doesn’t change the fact that it really is the reason we do it. It needs doing.

As for the thing I’m working on? The feeling of accomplishment that comes when I show people screenshots of my work is undeniable. The code inside’s not bad, not bad at all. And I’m actually dogfooding with it now (ok, ok, almost). I think this one is going to fly.

At last.


java-gnome 4.0.12 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources, of course!

java-gnome 4.0.12 (24 Jul 2009)

Being Uniquely Notified while Spelling the Sources you are Viewing is good for the soul.

In addition to ongoing improvement in our coverage of the GTK widget toolkit, the next release of java-gnome begins to realize our vision to offer coverage of the broad suite of libraries making up the GNOME desktop.

New Coverage

The TextView text editing Widget has received two significant capability boosts. With the work of Stefan Schweizer, we now have coverage of the powerful GtkSourceView library with its impressive built-in multi [programming] language source highlighting features.

And with the contribution of GtkSpell coverage by Serkan Kaba, we can now offer spell checking in TextViews as well.

Two other GNOME libraries feature in this release. Serkan also contributed excellent coverage of LibNotify, enabling an application to create and send popups to be displayed by the desktop notification mechanism.

And, we expose LibUnique, which offers DBus-powered machinery enabling a developer to ensure only one instance of their application is running.

Continuing improvement

Lots of minor changes and enhancements throughout the core GTK libraries. Highlights include improved mouse button handling, filtering when choosing files, and further refinement to Pixbuf. Thanks to Peter Mossveld, Kenneth Prugh, Vreixo Formoso, Serkan Kaba.

Finally, thanks to Guillaume Mazoyer we now have coverage of EntryCompletion, the feature of Entry Widgets whereby available possible completions are offered to the based on characters the user has typed so far.

Looking ahead

There are a number of people working on various branches — some small feature extensions, and some major coverage additions that add signifant capabilies – but which haven’t quite made it to the point where they can be merged into java-gnome. We’ll see how these pieces of work fare in the coming months, but nevertheless the Java bindings for GNOME have reached a significant level of maturity and we are pleased to see people starting to use them for serious application work.

This release is already packaged for Gentoo and Ubuntu, which is sweet.

You can download java-gnome’s sources from ftp.gnome.org_, or easily checkout a branch from_ ‘mainline:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.



Material on this site copyright © 2002-2014 Operational Dynamics Consulting Pty Ltd, unless otherwise noted. All rights reserved. Not for redistribution or attribution without permission in writing. All times UTC

We make this service available to our staff and colleagues in order to promote the discourse of ideas especially as relates to the development of Open Source worldwide. Blog entries on this site, however, are the musings of the authors as individuals and do not represent the views of Operational Dynamics