The Lair

A few weeks ago, there was a huge buzz around a new blogging software project named Habari. I heard of it then and wandered over to the IRC channel to take a look at the product. The people behind the project were already known to me through other IRC channels and I was quite keen to find out what they had been cooking up.

Other people have already done the introductions and the guiding principles behind Habari. They’ve also partly addressed the FAQ aspect; particularly a generic answer to why we need yet another blogging application in a market that is already rather crowded. Wordpress works, doesn’t it? Why do we need to bother reinventing the blog software wheel?

I run Wordpress on the Lair, as I have done for the last couple of years. It’s not everything I want it to be - but realistically, I don’t know if any blogging application could be that without a lot of custom additions. I’ve also been following Wordpress development (and development of some of the plugins) for a while and I’ve occasionally given back fixes, albeit minor ones. But there’s no reason why blogging software development couldn’t be done differently; or dare I say it, better.

I think it’s more interesting for me to explain why I personally decided to contribute to Habari development.

Technical

Habari represents an opportunity to start from the ground up. The minimum requirements include PHP 5 - all of two years old, but still not as widely in use as the older (and still maintained) PHP 4. That’s part of the official motivations for Habari. But it’s worth restating that the only compatibility Habari needs to really worry about at this point comes from external sources - not from earlier design decisions by previous versions of the software.

From my perspective, Habari represents an opportunity to re-examine the countless design decisions that go into building a piece of software. Conventional wisdoms may be, but frequently aren’t. Questioning the assumptions and preconceived notions that people may have about what they want their blogging software to do is a useful discussion to have at any point - and it might as well happen inside Habari as anywhere else. Habari is a fresh, clean slate, as yet unsullied by the need for backward compatibility.

Also from my perspective, Habari offers me a unique chance to dabble in a PHP5 project. The chance to read code written by people vastly more experienced in PHP (not to mention several gifted programmers) is a fantastic learning opportunity. Add to that the opportunity to have those same people critique and offer tips on my own code and design? Excellent. Oh, I would have eventually switched over to writing PHP5 code, along with the rest of the web programming planet - but Habari offered me the task based incentive to actually sit down and figure out the differences between the way I did it (in PHP4) and how it could be done better (in PHP5). Those are pretty powerful motivators to a person who has always been interested in development and software engineering.

Community

One of the most significant differences in how Habari functions as a community is in the meritocracy model of development. I’ve heard it (often in a snarky sense) being called design by committee, as opposed to the Pythonesque BDFL (Benevolent Dictator For Life) model. Ok, so let’s call what Habari does design by committee - even if it isn’t, really.

Does design by committee really work? So far, I have to say that it has worked for Habari. There are still kinks to be sorted out, of course. But just because there is a committee does not mean that the entire committee gets involved in designing each and every feature. Instead, each person who has a particular interest in a set of features takes the forefront in pushing them through, after consultation. Most importantly, this consultation happens out in the open, in the mailing list. Another benefit of having a wider committer pool is that instead of having one or two people act as a throttle limiter for all the patches and contributions made; more people are encouraged to participate. By participating, they also gain increased access to the project.

For example, I’ve been interested in making sure that objects in Habari [like posts, comments and even users] have the capability to store metadata about themselves. So, with some help and consultation on the mailing list; I came up with a solution, cooked up a patch and then nursemaided it to the point where it went into the core Habari product. I did it with lots of help and a couple of near disasters averted by (other) keen eyes watching the code; but it was very empowering to be able to see the need for a feature, code it up and then see it go into the actual product.

In my opinion, this is one of the biggest strengths of a project which is based on meritocracy. Fewer bottlenecks. Fewer opportunities for patches to languish in oblivion waiting for a reviewer or a committer to stroll up and get it in. A diversity of opinion about the product by a fairly large set of core development team members (not to mention the 200 or so signed up on the mailing list).

And did I mention the tasty mockups produced by the designers?

Habari still has a long long way to go - but there are already a few using the software on public blogs. They’re all crazy people, obviously - we still average 33 commits a week with 150+ file changes, according to my SVN client*. But the immense potential that I see for Habari is found in the formal API, the awesome work towards MVC (Model View Controller) separation by Jay Pipes, early focus on spam prevention and performance and the immense flexibility in rewriting URLs. Oh and I almost forgot that we support multiple (MySQL and SQLite for now) databases out of the box thanks to PDO - and Postgres support is nearly there, if not already complete.

* This is probably too high. I’d think 15-20 commits a week is more realistic, perhaps. There was a massive formatting change which touched almost all the files that is probably skewing the averages.