I’ve been deliberating over when to release the framework for some time. The accepted wisdom in Open Source projects is to “release early, release often”. However, I’d prefer to wait until the code is at a sufficient level of completeness, quality and usability.

I’ve found very few developers in agreement with this; they favour an early release, so that feedback can be given. I’d rather polish it to my own satisfaction first – and not potentially waste some of their time, as the code is in considerable flux.

One voice I heard recently who seems to agree with my stance was David Heinemeier Hansson, creator of Ruby on Rails. David has strong opinions about design, and it shows throughout Rails, which is a wonderful framework (part of this wonderfulness comes through from his choice of Ruby). In an interview with Randal Schwartz on the FLOSS Weekly podcast #79, he says, on the work leading up to the release of Rails:

I didn’t want to put something out there that was going to languish, like a ton of other Open Source projects. If I was going to put something out there, I’d put it out there with enough effort that it’d have a fighting chance to make a difference for people. So, I think for about six months actually, after I had a completely working framework sitting on my hard drive I said ‘screw release early, release often’; I’m going to polish the hell out of this thing. I’m going to write the documentation; I’m going to build up some marketing sort of intensity around it; I’m going to do all of these things that a lot of Open Source projects do not. And as a result of that, they have a tendency to not get very far. I wanted this to have an impact; I wanted this – for my time to be worthwhile. I was not going to put all of this freaking effort into bundling this stuff up that meant two people playing with it for five minutes; I mean, that’s freaking wasted effort. So, it took about another six months of me talking it up, polishing it up, writing documentation, doing all these things before I felt ‘Hey, it’s good enough to release it’.

I’m greatly reassured by this – and if polishing until it’s ready worked with such spectacular success for Rails, then perhaps “release early, release often” is not always the right path to follow.

Other interesting parallels here are that Rails is a framework extracted from an application, as is the MiniMiser framework; Rails allows you to write database applications easily, and this is the intent of the MiniMiser framework, albeit with Java and targetting desktop applications; David is right about Java being verbose; I quite like it for its static typing, and the excellent IDEs and toolchains – I’ve never felt totally happy with the dynamic languages in this regard, although I feel that Bruce Eckel is again right, when he argues for “strong testing, not strong typing”. I just prefer both. And if Java isn’t entirely your thing, then rest assured, I’m trying to enable users of the framework to work in JRuby.

There’s also the issue of control over the project, and singular vision that I agree with. David, again:

In the beginning, I could absolutely control the vision of where this thing was going to go, which is also why, for about at least a year, Rails had one committer – me. There was plenty of people submitting patches, but there was one committer, and I was that, because I wanted to make absolutely sure that this had a clarity of vision; it had a very targetted design. I did not want it to become this sort of mess that in many ways was what drove me away from PHP. [which is] wonderful [in many ways], but consistency of vision and design is not [one of its qualities]. It’s just a grab-bag of so many people injecting their ideas into how this thing is going to be designed. I wanted something that was a ton more streamlined than that. And the only way I knew how to secure that in the beginning was that I was going to be the one making the decisions.

So it’ll be a little while before I’m ready to publish – but the day is definitely approaching.