News is surfacing all over the WordPress community and beyond of a fledgling, open-source based weblog/CMS project named Habari. Seemingly started by a small group well-known within the WordPress community it aims to be in direct competition and has been started out of certain frustrations with its elder and dominantly established platform.

I can both understand and sympathise with those frustrations. WordPress is a great piece of software and will be very hard to knock from its perch but it is going through the stage that all innovative software and indeed small companies go through that experience huge and unplanned for growth with the addition, as I have discussed before, of a certain arrogance at parent company Automattic. Avoiding the pitfalls that WordPress is experiencing is no easy task and decisions made by the Habari team now will inevitably come back to haunt them in the future.

Having myself been involved with both start-up companies and a clean slate within which to engineer new software applications, I know that those first few weeks and months are an exciting time, the ideas and the adrenaline flowing, exhausted fingers rattling the keyboard full of desire to get it all coded before the dream starts to evaporate. It is the most productive time in any software project but it is also the most dangerous.

The key to it of course is planning, which also, in my experience, tends to be the part that programmers in particular tend to disdain as it immediately starts to shackle their imagination. But if a project like Habari is to achieve success and, more importantly, sustained success, time spent at the beginning planning for the future is an imperative – before the project has actual users to worry about and before the project moves from the bedrooms and studies of two or three key people into the public domain and the inevitable conference and board room.

A week or so spent watching the WordPress support forum and subscribing to the various mailing lists is almost a lesson in futility. The same questions get repeated over and over again on the forums and the same suggestions get raised over and over again on the mailing lists. Leaving aside the sometimes arrogant dismissal of outsiders by the Automattic team, much of the problem with WordPress is the very fact that it is a juggernaut. Even a small change request that might be seen as a great benefit to the many is hard to accommodate because of the havoc it can wreak on the user-base. But often you can’t help thinking that many of those same requests actually make so much sense they should have been in the core product since the beginning.

The suspicion, of course, is that WordPress was started in the same way that so many projects are, by a couple of people with a vision and an itch to get it coded, never expecting that it would be the huge success that it has become. And seriously never realising the pressures that thousands of users can bring to bare when something goes wrong or when necessary changes can’t be made because of initial design limitations. In short, there was no plan for success.

I both applaud and welcome the Habari project. I will be one of the first to download an early cut when it becomes available and I look forward to watching it’s progress over the coming months. I suspect that it will be a bigger undertaking than anyone on the team yet anticipates but I wish them every success. The goals they have set themselves are admirable and I hope they achieve them. And while I understand that it’s both hard and a nuisance at this stage of the game, I implore the team to think long and hard about the future. A short-cut or compromise taken at the beginning for expediency more often than not turns into the nightmare that cannot be undone two years down the road.

For what it’s worth, here are a few of my main gripes with the WordPress world, leaving aside any actual software and usability issues. It is my contention that these points also need to be taken on board by any competitor:

• Installation: WordPress boasts a simple and quick install and, if you know what you are doing, it is. The reality is that most people don’t know what they are doing and a large number of them screw it up and then clutter the support forum. A proper, simple and guided installation process is a must.
• Upgrades: Again the WordPress method of upgrading is as bizarre as the lack of cohesive instructions on how to do it. With every release or even small update the recommended approach is to wipe out all files and upload a completely new set. This worries a lot of users and many, once again, get it wrong or worse, ignore security fixes and don’t upgrade at all. The lack of hand-holding through this difficult process – for most users – is a severe lack of sensitivity to the fact that the vast majority of users don’t even know what ftp is. Automatic or semi-automatic upgrades must be a goal from the early stages.
• Upgrade Details: This is a big and contentious issue. Trying to find out exactly what has been changed with any update, even big major releases, is like trying to pry information out of government agencies. Ask, and they shout ‘look at Trac’ which to the vast majority of users is, of course, gobbledygook! Transparency and information is a must to foster a good development community – plus it removes the unwanted surprises from users.
• Documentation: The WordPress Codex is large and expanding all the time and I applaud the efforts of those who contribute to it. The problem is that it’s an unqualified mess. It sprawls uncontrolled with no sense of structure or cohesion and the search facility is pretty worthless. The codex should be the first stop for problem solving but I suspect many people look, don’t find it easily and give up or go to the forum – usually to ask the same questions that come up daily! Easy to navigate, simply written but extensive documentation is an absolute must. Good documentation will keep the users questions at bay. And decent and comprehensive development documentation will go a long way to making a fledgling system a success.
• Support Forum: The WordPress forum does it’s job but because of the insistence on using lightweight sister product bbPress it leaves a lot to be desired – mainly in the search arena. Trying to find previous answers is a depressing ordeal yet the first thing the forum volunteers yell is ’search, search, search’. We would if it worked. So the tip here is use decent software that is up to the job.
• Themes and Plugins: Of course being able to build third party themes and to extend the base system through plugins are major strengths and I doubt any competitor would get out of the starting gate without offering this level of functionality. The problem is that WordPress takes no responsibility for the safety, quality and reliability of either. Whilst I understand that would be an awesome task to undertake, they do appear to endorse certain plugins by allowing them to be listed on the Codex. But anyone can add a plugin to the Codex – even a harmful, rogue one. I have always believed that WordPress should ‘own’ the central repository of plugins and themes and allow the user-base to endorse them.

Of course, to suggest that the Habari team have all these things in place from day one is a pipe dream. But I do implore the team to careful consideration early on and plan for the infrastructure they will need down the road because playing catch-up later rarely seems to work.

And then, of course, there is the raising of the cash to pay for it all…

For more information relating to this news you can visit key team members: Chris J.Davis, Khaled Abou Alfa, and Michael Heilemann at their respective homes.