The Goldfish Chronicles

Codehaus manifesto
============

The Codehaus recognizes that some committers, based upon metrics, longevity and appointed management, have greater say on a project than others.
The Codehaus is a place where people are encouraged to get on with code rather than tie their projects up with bureaucracy.
The Codehaus encourages projects to strive for quality and for frequent small releases.
The Codehaus encourages committers to be respectful friends, meet up with each other as often as possible. Face-to-face is superior to email.
The Codehaus stands in favour of diversity (where appropriate) over enforced convergence and homogeneity.
The Codehaus places a high bar on entry for committers. Referral is a common means. A new committer is expected to show strong character elements as well as a talent for code. New committers may be subject to a number of moderated questions or even a chat with Bob The Despot. Maturity and wisdom (possibly in advance of years if a youngster) should be demonstrated.
New committers to an existing project are expected to ease themselves in with small and deferrent commits to start, and greater free-will may be assumed later.
The Codehaus places a high bar on entry for projects. They should be released or near it.
The Codehaus encourages people to be brief in email and to honor internet etiquette. Ten furlongs of text justifying a position is poor form; better would be a (failing) unit test.
In case of disagreement, Bob The Despot is right.

Apache comparison
============

* The ASF believes strongly that all committers on a PMC have equal say. Committers don’t immediately join the PMC in most cases, and members have a greater say than non-members, even if not committers on the project itself.
* The ASF encourages code not bureaucracy, provided there is sufficient oversight to ensure the committers actions are legal.
* +1 to quality and small releases, though this is up to individual projects.
* Public email conversations are preferred to private conversations. Face to face is however used (ApacheCon, Hackathons) and phone conferencing (board meetings).
* The ASF tends towards standardisation across projects, but is only lightly enforced via a preference to use ASF hardware and a limit on the availability of ASF hardware and support volunteers.
* The bar for committer entry is up to individual projects. Member entry is based on member voting/referral.
* Bar for entry for a project is based on understanding of the ASF concepts and system. The Incubator exists to teach this system and to a lesser extent the concepts. Members in general exist to pass on the concepts.
* Email netiquette is left to the individual mailing lists.
* In case of disagreement, the board is right. However the board are democratically elected by the members (though not necessarily from the members).

Woke up this morning with the distinct feeling that I’d used up my gmail.com space *shudder*. Thankfully it was untrue, but still

Thanks to another bug report from Tim Patton, I had some fun today fixing bugs in Norbert (robots.txt parser) and got the 0.3.2 release out. Various parts of the robots.txt rfc’s fineprint.

Here in the “long-tail of open-source”, as I’ve heard it described, getting a bug report can improve your entire day. Not only is someone actively using your code as you sit facing the drudgery of the day, but they’ve found a problem and instead of being angry they’ve written to tell you about it.

The end is in sight on Subversion migrations at Apache as may be seen in the
plan. The next couple of weeks should see the back of the remaining modules broken and then we’ll have a month or so to finish off whatever flotsam is hanging around.

Problem-wise, the only issues I’ve hit so far are either places where CVS had soiled its pants and had slightly messed up ,v files (such as having a branch of XXXX in most files, but in a couple of files it thinks its a tag) and occasional problematic filename encoding. Mostly it’s been about nudging a large set of communities into heading in the same direction; not so much herding cats as guiding cat herders

As the Professor would say: “Good News Everyone!”.

My employers have agreed to fund my trip to the Apache Conference in San Diego in December. My plan is to fly out on the Friday evening so I can enjoy the 2 day hackathon weekend, then I’ll catch a Thursday morning flight back after the speakers are all speakered out and it’s all over.

I’m looking forward to it.

One of my current books at the moment is Damian Conway’s Perl Best Practices. I’ve been trying to play with Python more recently, but this book jumped into my arms from the first moment I saw it at the bookshop. Conway is a great author (his OO Perl book was a great read too), and after only 100 pages this is already the 2nd book any budding Perl programmer should read after Learning Perl.

Even if you’re more experienced with Perl, read this book. I suspect the rest of the book will be as good as the first 100 pages have been, lots of tiny tidbits of Perl information and for those of use who don’t use the various libraries as much as we should, lots of information on the useful libraries that out there.

Plus he slips various Perl 6 libraries that can be used already in.

The MySQL site links to an article from 2004 on Finding an open source programming job.

Brian Aker, director of architecture for MySQL AB says, “I can’t go around hiring leaders from big-name open source projects. They’re all hired. If they don’t have day jobs it’s because they don’t need them.”

Damn. How do I become a leader of a big-name open source project?

Pondering a different scheme for choosing version numbers, I have never been very happy with the style where you slowly release 0.x versions until some special 1.0 day when things are considered to be good and great. It has the following problems:

1. How do you know that you’ve reached 1.0 day? If you’re working to an initial plan or matching a spec, sure, but if you’re just improving and adding features as and when. For Jakarta Commons it means you’ve been released, but for OSJava waiting for 1.0 has never really worked.
2. If you completely redesign the system, ie) change the meaning of 1.0 day, there is no way to reflect that in the version.

My planned version scheme (unsurprisingly) is:

major.minor.bugfix

• major relates to the design of a product and begins at 1
• minor relates to the latest stage of that design and begins at 0
• bugfix relates to any bugfixes made after a release of a minor version, it starts at 0

The important difference is that

1. you start at 1.0.0
2. a major redesign sees you moving from 1.x.x to 2.0.0.

Not hugely interesting I guess, but I figured there might be some good strong negative views out there.