I read a post by Jacob Santos in which he lists a few reasons why he will not switch to Habari.
First, let me say that I’m glad you have reasons for your decision, and that you’ve chosen something you believe in. I think a lot of people pick their tools because it’s what the next guy uses, without really thinking about whether its best. Now… Let me try to change your mind. ;)
- Given that Habari does a bit more to organize things, I think it’s fair to find a few more directories. If you look in detail at Habari’s directory structure you’ll see that even though there are more directories, they all make sense when you know what they’re for. /system is for core files. /user is for your files. /3rdparty is for things you’ve installed that other people have written.
In /system, /system/admin contains the administration files (analogous to WordPress’ “wp-admin” directory), and /system/classes contains all of the core class files (analogous to WordPress’ “wp-includes” directory). Habari has additional directories in the system for the installer (so you can easily remove it), locales (so the translation files are easily found), schemas (since Habari supports multiple database engines), and core themes and plugins.
What’s nice is that with the system/user segregation, you can upgrade just by copying over your existing installation. Your stuff is safe in a directory that Habari has marked as off-limits for itself.
- Starting from the ground up does not make you better, no. But it does give you the benefit of hindsight. Being that many of us were WordPress developers for a long time, we know where the softspots are. We know what could have been done better. By no means is Habari perfect, but we’re trying hard not to make the same mistakes.
And yes, while the WordPress community continues to contribute to WordPress, the Habari community continues to contribute to Habari. One thing that’s very similar in how Habari works today to how WordPress worked back in the 1.0-1.2 era is that we all support each other. It’s part of Habari’s mandate. I don’t get that feeling from WordPress any more, or even before I stopped contributing to WordPress personally.
Keep in mind that WordPress is not the only software whose knowledge we’re benefiting from. We recently had a thread in the mailing list comparing sections of the admins of different products, including Serendipity and Movable Type.
- Another of our prime directives when starting the project was to include adequate documentation, not just in what’s available online, but within the system itself. We include a manual with every Habari install that works even if the software isn’t fully configured and running. The manual is culled from the best bits of user-contributed documentation to the wiki.
I’m not currently satisfied with the documentation Habari provides. I think we can do much better, and I’ve recently started down a path to get help in achieving goals I have for that improvement. Nevertheless, I’m really happy that you see the effort we put into that aspect of our project.
-
PDO has been a great boon to our development. There are still some areas that we need to improve in database access, particularly in our cross-platform support. Why don’t you come help influence how this goes down?
-
Habari certainly does not restrict you to a single class for plugins. It may be true that most of the existing plugins for Habari are only in a single class, you have many options other than that for creating plugins. Plugin hooks can also be manually registered, just like in WordPress. (If you need instruction, email me, hit me up on IRC, spam our list – I’ll put the docs in our wiki personally if need be.) The only restriction is that you must have one class that implements the Plugin interface for providing information to Habari about the plugin itself (author name, URL, system requirements, stuff like that – not hooks implemented). That is, it must implement the info() function. Beyond that, you can include whatever other classes and files you want to make your plugin as complex as you like.
-
I have never seen a WordPress Unit Test. My WordPress SVN checkout has zero. My Habari SVN checkout has a handful. This is not to say that we couldn’t do better or organize them. If you want unit tests, we will include them. We’re not afraid of doing that. Submit some.
-
Novices to coding are always going to have more difficulty digging their hands into object-oriented code. The result of doing so is a benefit that you seem to recognize. Having to support the procedural codebase if WordPress ever implements an object-oriented backend is another albatross they can bear in addition to the PHP 4.x support.
-
The difference between Habari and WordPress in terms of inline documentation is that Habari commits require documentation. It’s part of Habari’s code standards. We also publish and keep up do date our own PHPDocumentor output, which is simple to do, but at least demonstrates that we care that the documentation is being produced. Any complaint you had about Habari inline documentation being difficult to produce could be said similarly for WordPress, although with more than 15 committers available to review, accept, and apply documentation patches, Habari could probably get the job done more quickly. And if you keep on top of these patches, make it your niche in Habari, you could very well merit yourself commit access of your own.
And that leads me to the one big point about Habari that you glossed over: Habari is community first.
We started this thing because we stopped feeling welcome or appreciated in WordPress, or at least we weren’t getting out of it what we were looking for from our contributions. We wanted to write good code and share it with each other and the world. Writing code for Habari makes me feel good. Helping other people write code that works with Habari makes me feel good.
We value every contribution. It’s not just the coders that are lauded in our operation. People who write documentation get full access to our project. The folks who help us support our users are fully recognized, with equal rights for deciding the project direction as any other committing user. And even if you haven’t been fully recognized, we still listen to the community when it has a strong opinion.
Our community is fully open. The only thing that happens behind closed doors is electing new committing members. Everything else - coding, documenting, even the design of our admin - happens in the open. While participating in the interaction as any member of the community, you get to improve your own skills and learn from people who have been doing this professionally for years. As I said, we’re not just coders. We’re designers, authors, database and system administrators, and even some expert everyday users.
So maybe WordPress has a larger following, and maybe it’s code isn’t as mangled as all that. Even if WordPress was better in every way you point out, I would still hang my hat on Habari because I know where the value is. We all share this specific set of ideals, and that’s what makes the project special. Plus, it’s great software.
Thanks anyway for giving Habari a try, and I hope you at least continue to keep an eye on our project since we have many exciting things planned for 2008. If I’ve intrigued you at all, come be involved!
