When I started this project (when it was still a single desktop application for home financial management), I hoped that it might attract a community of users and developers.

Writing a software product that has quality is no small task. Anyone can lash together some code quickly, slap it up on SourceForge and hope – and many people do, leading to what David Heinemeier Hansson describes as “two people playing with it for five minutes” (See previous post, with quotes from David taken from the FLOSS Weekly Podcast #79 – http://twit.tv/floss)

Creating well-designed, aesthetic software, that meets the users’ needs, with all the features they have come to expect from modern desktop applications, plus excellent documentation, community infrastructure (website, forums, mailing lists, etc.) that’s translated and localised to their language and locale and having a coherent architecture that passes intensive quality metrics – is a lot of work for one developer.

I admit I have given no thought to internationalisation or localisation, at present. I will dedicate a release cycle or two to it later – I hope that the project will be of interest to developers who have more experience of these issues than I do, and who speak languages other than British English.

As noted in earlier posts, the goals of the project have diversified into providing a general-purpose embedded-database-backed desktop application framework. I hope that this might be of broader use to more users and developers than the narrower opportunities afforded by simply a financial application.

All the development to date has been stored and built on a server on a private network – as I open up the project, these facilities will have to move to public hosting facilities. Again, SourceForge and the like offer attractive facilities to developers here, but are not at all usable by end users (See How to successfully compete with Open Source software by Patrick McKenzie for a critical view of SourceForge as being unsuitable for end users.).

I’m currently using Subversion as a version control mechanism; this has been great so far, but the central repository on the private network is a bottleneck to my preferred style of working: rapid commits of discrete pieces of work. I do the majority of work on the project on the train, only connected sporadically via GPRS/HSUPA modem. Since the private network is not accessible remotely, I can’t commit when I’m travelling. All items I’ve been working on during commuting are in my working copy, and require sorting out into discrete commits. Sometimes there are overlaps between items, and if I were to open this to the community, it would make code review of independent pieces of work difficult. Not having the entire history available whilst working disconnectedly is also less than ideal. So before opening up, I’ll convert the projects to a distributed version control system – I’ve already chosen Mercurial: Git is not a consideration since its developers do not seem overly concerned about cross-platform issues; Bazaar was a contender, however Mercurial passed the “Has an O’Reilly Book” quality test. (Mercurial: The Definitive Guide.) I don’t know how easy it would be to set up my own repository hosted on my own public server, so I’ll enquire about hosting the code on BitBucket.

Another small barrier to entry for other developers is the domain from where it is available. I have a perception that people might be less likely to contribute to a project that seems like it only belongs to ‘a guy in his bedroom’: The gumbley.me.uk domain and uk.me.gumbley Java package I have been using to date is like a private house: you may come in if invited. A community hall is open to all, more welcoming. Therefore, a “proper” domain has been obtained – which, in accordance with my preference for polishing until ready, will be revealed later. Suffice to say that I intend to develop it as a community website, made highly accessible primarily to potential users of the software, as they shouldn’t have to wade through a developer-centric design. I’m using Drupal to manage it – a thoroughly fantastic CMS; I recommend it highly. There will also be a grand renaming of the Java package structure of all the projects prior to hosting on BitBucket.

The build infrastructure is more than just source code control: I’ll need:

  • a continuous integration server (are there any publically hosted Hudson servers?)
  • a Maven repository (I am aware of Sonatype’s OSS repository, and will be enquiring about this – there are a few artifacts I’m using that are not available from the central repository, and a few I have deployed in odd ways on my private repository – these issues will have to be addressed first).

I have been reading two excellent books on the community aspects of developing Open Source software: Karl Fogel’s Producing Open Source Software, and Jono Bacon’s Art of Community. I’d thoroughly recommend these to anyone contemplating an Open Source project – especially if they want it to have any longevity. Another series of articles that will help the Open Source craftsman are by Kirill Grouchnikov, and may be found at Pushing Pixels: Party of One: Surviving a Hobby Open Source Project. (Note that I disagree with Kirill’s point about documentation: “If your documentation does not have an immediate answer – it’s your fault. In fact, the documentation is a chicken and egg problem – if your library needs documentation, it’s unfortunately your fault as well.” – I believe documentation to be an essential part of software, especially frameworks, languages and libraries: how many people would be Ruby programmers now, if Programming Ruby had not been published?

The list of technical things I have to provide have ballooned following their advice: bug tracker, mailing lists backed by forums for nontechnical users, IRC (could be difficult, given my semi-connected, only-on-the-train-and-frequently-going-through-tunnels mode of working).

There are also the political / governance aspects that must also be addressed.

There’s a lot to do – and at the moment, only me to do it. No wonder then, that only 15% of projects identified by Kirill in his articles achieve viability.