Why Habari?
Last night we celebrated Passover with Carina's folks, and her uncle Tim. This was my first Seder, and it was a very interesting experience. Tim did a great job explaining everything, and answering all of my questions. I've never really done much with respect to Jewish holidays, so it was a very educational evening.
On the way home, Tayler started asking me about Habari. Both of the girls have heard me speaking of it to Carina in weeks past, but neither showed much interest. Saturday, though, Tayler learned I was working on my April Fool's Joke, and became very curious about Habari; so her questions last night didn't really take me by surprise.
Tayler was interested to know why I was working on Habari. I explained that when I first started using WordPress, there was a very vibrant community of people working together to solve problems. It was an exciting time, and there was a lot of creativity being shared and encouraged. I really liked that. As time went on, I explained, the guy in charge of WordPress started a company, and he became less and less interested in other people's ideas. He only seemed to like the ideas he came up with. So, Chris, Rich, Owen and I all agreed to start working on Habari, so that we could get back to that spirit of collaboration and openness.
Tayler then asked "Is Habari better than WordPress?" I answered honestly: not yet, because it's so new, and WordPress has been around for a couple of years. But I'm confident that Habari will get better for several reasons. First, the way we're making Habari is -- we think -- more flexible than the way WordPress was built. Time will tell whether we're right. Second, we think we're much more accommodating of other people's ideas: we want people to participate and share their ideas, and we know that we're not the only ones with good ideas.
At this point, Tayler interrupted to say "I don't think the guy in charge of WordPress is very creative." This is such a typical example of the twins' thought process: she was really asking a question, but stated it in a declarative manner. I gently rebuked her: No, I don't think that at all. I don't know enough about the guy to know whether he's creative or not. He has some good ideas, but I just don't agree with the way he operates.
I continued to explain that WordPress, because it's being partly driven by a company now, is less open to new participants and their potential contributions. With Habari, we genuinely want people to share their ideas with us, and we ultimately want to allow those people to add their new ideas on their own, without requiring us to do it for them. I detailed briefly the way in which our committer base has grown in the last couple of months, because people with good ideas have been invited to help us work directly on the code. Tyler joined in the conversation at this point, and exclaimed that she wanted to help with Habari! After a moment's pause she hung her head and said sadly "But I'm too little." I had to stifle a giggle: she was so cute. "It's not that you're too little, Tyler. It's just that you don't know how to program in PHP!"
The discussion continued on for quite some time, reaching the ultimate conclusion that both the girls want to use Habari instead of WordPress. I'm delighted that they're so interested in my hobby, and it really reinvigorates me to have a couple of people close to me really supporting my efforts.
In-Series and WP-DB-Backup Updates
My In-Series plugin is being taken over by a new developer, and has a new home at http://remstate.com/projects/in-series/. If you use In-Series, you should update your bookmarks and download the latest version.
Il Filosofo has released a new version of WP-DB Backup, as well. This version updates for the new scheduling functionality in the forthcoming WordPress 2.1 release. If you're a WP-DB Backup user, please be sure to update your bookmarks in order to keep up with Il Filosofo, since I'm no longer working on this plugin.
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.
Community
Community is the cornerstone of Habari development. It was community that brought the four of us together, and we're keeping community squarely in mind as we approach decisions and plan features. We recognize that only through collaboration will Habari succeed: each participant brings with him or her their own unique skills and passions. This diversity of talent and ability is an important aspect of Habari's community.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.
Innovation
Habari is about innovation. There's a lot of great things being done with internet technologies, and we are very interested in integrating them into the way we blog. Things like OpenID, CoComment, and the Atom Publishing Protocol are all very useful innovations. We've been frustrated by the difficulty in integrating these -- and more -- into WordPress. Some of the roadblocks to integration into WordPress were technical, while others were clearly non-technical. We hope to remove both kinds of roadblocks and make Habari the most cutting-edge blogging system available.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.
Documentation
As much as we're striving to make a system that's friendly and intuitive, we recognize that not all people have the same background as we do; and as such what's intuitive to us might not be intuitive to a first-time blogger. Documentation is of paramount importance to the Habari project. End-user documentation and developer documentation will both be included in the download.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.
Experimentation
Habari is not afraid to experiment with new ideas. The Subversion repository ensures that nothing is ever truly deleted. If someone eagerly checks in a new idea that proves to be either poorly implemented, or maybe just not such a great idea after all, the revision control system makes it easy to correct the situation and move on. We hope to support developer branches for their own work outside of the core trunk.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.
Development Model
I met DrBacchus several years ago, and it's been fascinating to listen to him speak about the Apache development process. The meritocracy of the Apache Software Foundation is such that regular participation results in increased permission within the project. This is the model we've decided to adopt for Habari: frequent contributors are given access to submit new stuff directly, because they've proven themselves capable.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.
Spread the news
We've been working on Habari since October, 2006. I'm tickled that many of the suggestions on "What the new kid on the block needs to get right" had been discussed long before we ever announced the project. With the influx of interest and enthusiasm, there's been a lot of attention on the installation process. Hopefully we can dedicate as much energy to the upgrade process as well.
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!
WP-DB-Backup under new management
Il Filosofo was the first to contact me about picking up maintenance of wp-db-backup, so the backup plugin will live on! If you'd like to help Il Filosofo, or if you just want to send feature requests, contact him directly, please!
Matt clarifies the security issues, which is to say that there are no known security issues with wp-db-backup at this time.
Ryan complains about the plugin, saying "That was the third security fix for wp-db-backup since it was introduced to core. It is unmaintained, and I'm tired of fielding the email it generates." I must not be privvy to the first two security announcements about my plugin -- maybe they're posted for public review on a whiteboard at the Automattic compound somewhere. As for dropping it because they're tired of the email it generates, boy it must be nice to weild supreme executive power like that. Heavens know there were plenty of questions I was sick of answering on the support forums -- a sentiment shared by all of the support forum volunteers, I'd wager -- but never did I have the luxury of simply removing the problem.
There were some very nice comments on my Autocrattic post, and some very well-thought-out opinions were put forward. Thanks for the kind words, the support, and the temperance of calm reason.
Autocrattic
Matt removes my wp-db-backup plugin from the default WordPress package. No trac ticket suggesting this course of action, no seeking feedback from testers or hackers, and no public discussion of his actions prior to executing them. The backup plugin was very highly recommended by a lot of people on the hackers list for inclusion with the default download.
I continue to get trackbacks about how it has saved folks' sites. I see my plugin listed in many "top ten plugins" lists. I honestly don't care whether my plugin is bundled by default or not. It's Matt's unilateral decision making that raises my ire so much. He's written time and again about what users want when justifying things he wants to ram into the core, but then happily ignores popular opinion for his own undocumented, unpublished, goals.
I take particular umbrage with Matt's claim that it "has been a source of security probs". I was only ever made aware of one security issue, which I published immediately here, as well as on the WordPress support forums. If one security issue means the plugin should be removed from the core, then the core of WordPress itself should be excluded from the core, since it's had far more security vulnerabilities in its lifetime. Doug Stewart claims "it's been a security nightmare", but offers nothing to back up that claim. Nor have I received any emails from him, Matt, or anyone else about these security problems, even before I stopped officially supporting my plugins.
Matt says, rightly, "There is nothing stopping you from continuing to use the plugin". Sure, I still host the plugin version here, even though I have no intention of updating it to work with any future versions of WordPress. The kicker, though, is Matt's final comment "I just don't think it's appropriate to bundle with core anymore." And that alone is sufficient grounds for him to take action, community be damned.
Don't let yourself be fooled: although the code to WordPress is available for download and personal modification, there's very little chance of anyone other than Automattic making substantial contributions to the product. It's "open source" in name only.
Matt suggests folks should use the new fangled XML import/export feature, instead of the backup plugin. This isn't the first time Matt has removed someone's contributions to be replaced by something he cooked up. I haven't used the import/export feature yet (because I gave up following WordPress development), but I do wonder about its utility in comparison to the backup. Export and backup are two different things.
If anyone wants to take ownership of the wp-db-backup plugin, feel free to contact me. I'll happily facilitate anything I can if you want to pick up where I left off. I'll also politely ask Autocrattic to grant you write access to the wp-plugins.org repository, though be warned that it took almost a month to get subscribe2 updated for its new maintainer.
