I just got done listening to the WordPress podcast, and I’m very impressed both with the quality of the production, and the quality of the commentary. That two guys can natter on for an hour, and still be interesting and informative, is pretty impressive.
I’m fascinated, however, by the remarks about Habari. In particular, I have a growing interest in how people measure the success of a project, and this podcast tweaked that interest a little more.
It appears that a lot of people measure the success of a project by things that are utterly unimportant to me. High on this list are:
Install base: Habari can’t be a success because WordPress already has a huge install base, and, starting from scratch, Habari has only 3 users.
Number of themes: There’s only one or two themes.
Number of plugins: WordPress has a lot of plugins and is therefore successful.
These intrigue me, not only because they are completely disjoint from how I measure success, but because the last one is, to me, a clear indication that WordPress does a lot of stuff wrong – at least, after listening to the list of new plugins listed on the podcast.
Yes, it’s neat to have lots of people using our stuff. I imagine that’ll come with time. But it’s not a measurement of success. I got involved in Habari for rather different reasons.
I wanted to work on some cool code. I actually enjoy programming, when the code is elegant, beautiful, and innovative. Habari code is those things, at least now. And it’s fun. If folks end up using it, bonus, but that’s not the measure of success.
Also, I wanted to produce a package that does what I want it to. One of the fundamental principles of Open Source is scratching one’s own itches. If we end up with a product that I can use, that does pretty much what I want it to do, and which I can tweak to do other stuff I want it to do, then it’s successful.
As for themes, that’s a non-issue. Habari will be able to use WordPress themes, so however many themes WordPress has, Habari has ’em to.
Finally, plugins. Well, that’s interesting. One of the plugins that was mentioned on the WordPress podcast allowed you to reorder pages. I don’t even understand what the problem is, let alone why you’d need a plugin to solve the problem. When something hugely obvious, like reordering pages, requires a plugin, this makes me wonder both about the community process (why wasn’t this just a trivial patch to TRUNK, rather than a third-party plugin) and the code (why on earth should it be so hard to reorder pages that it requires a third-party plugin?) Of course, this is likely a bad example, and I’m sure the plugin does useful nifty things that would be impossible otherwise. But there are large numbers of plugins that seemed to me like they should be core behavior. My canonical example is the dashboard. The first thing that I do when I install WordPress is install a dashboard plugin, so that the administration dashboard is actually useful, rather than being a list of RSS feeds of blogs in which I am utterly uninterested. Why I would want a list of blog entries on someone else’s blog as my main administration interface completely escapes me.
Anyways, thanks for the podcast, and for the insightful things you had to say about Habari. We’re having fun, and we’re producing interesting software, so we’re already successful. I find your measuring stick interesting, but I think you’re using the wrong one.