Spread the news

So it’s official: I’m leaving WordPress behind. I’m involved with the development of Habari, the next-generation blogging solution. One might wonder why we’re re-inventing the wheel. Someone recently quipped that we’re past the wheel, and are now working on the hovercar! Nonetheless, an explanation of what Habari offers should help explain why I’m involved.

Another important aspect is that Habari is owned by the community. No one person has full authority over it. The people who use it and work on it are the ones who should – and will – make decisions about Habari development. Additionally, community members should be given the power to take charge of their areas of expertise. If someone is passionate about documentation, they ought not have to work through someone else’s restrictions in order to make the docs successful.

One of the very first decisions when planning Habari was to make it a fully object oriented system, and leverage the powerful features of PHP objects. This has resulted in some wonderfully efficient code, and so far the system is remarkably fast. Object oriented programming allows us to streamline the development of user-created plugins; allows us to integrate a unified error handling system; and vastly simplifies the construction of our Application Programming Interface.

Another early goal of Habari was database independence. There exist enough database abstraction libraries that locking oneself into a single database really does seem a poor design decision these days. By using PHP version 5, we gain access to the PHP Data Objects (PDO), which is the PHP-native database independence solution. We currently have MySQL and SQLite working, and are eager to find contributors with PostgreSQL experience. Preliminary conversations suggest that Oracle support wouldn’t be too hard, either, surprisingly enough. Another very real benefit to using PHP5 + PDO is that we gain the use of prepared statements for all database interactions. This drastically reduces the likelihood of a SQL injection attack against your blog. We’re considering using stored procedures, too, as both a means to improve performance as well as to improve database independence.

We plan to integrate links to the manual into the Habari administrative interface, so that you may get help about specific parts of each screen with a single click. The manual will be part of your Habari installation, so if you can get to your site you can read the manual. Users should be able to access the documentation without relying on our possibly flaky servers to store the manual they need.

Developers – and would-be developers – should also be provided with meaningful documentation. We’re fully documenting (via PHPdoc) the source code to Habari, and plan to include thorough instructions as to how the system operates: initialization, request processing, theme and plugin dispatching, and more. This is a fundamental part of the Habari distribution, and not left to the kindness of volunteers after the fact. New methods will be documented when they’re included in a new release, not after someone figures it out on behalf of everyone else.

Another important aspect of documentation is meaningful changelogs, listing real changes to the product since the last release. Distributors and integrators rely on changelogs to see what’s happened. Developers rely on changelogs to be made aware of fundamental changes to systems they might be using or extending.

With all these people having access to check in new code, it’s a very real possibility that someone might try to intentionally foul things up. If someone were to flake out and try to actively harm the project by deleting files or polluting contents, the other project members could simply roll back to a previous version before the attack and keep going. If someone checks in something by mistake, or implements something broken outside of their area of expertise, it can be dealt with relatively easily.

This is important for several reasons. First, we each have our own areas of interest and expertise, so by getting more people involved directly we speed up the development of all areas of the code. Second, more people are available to deal with problem situations. Third, the project as a whole doesn’t slow down if a few of the developers are offline for extended periods of time. Finally, more developers improves our “bus factor”: it takes more people getting hit by more buses to interrupt the project.

I’m thrilled with the response to Habari so far. Owen’s posted some more info about Habari, as well as a collection of links to some other posts about it. The IRC channel is becoming surprisingly busy. I know eventually all the enthusiasm will taper off, and tough decisions will need to be made; but for right now the sky’s the limit!

Needless to say, I’m very excited about Habari!