A quote from Owen:

…Habari is object-oriented. Habari supports database independence. Habari uses an MVC model to separate templates from logic. Habari supports multiple template engines. Habari has a database schema that was designed for efficiency from day 1. Habari has a different kind of community supporting it, one where people who show the ability, willingness, and responsibility to act within the community get the power to do so. This is the iceberg tip.

via Chris J Davis

Today is the big day. HabariCon 2008 is happening in a few hours (I should get to bed!) in at the lovely iPony facility. I'm even giving one of the presentations later this morning. It's very exciting, but I'm quite nervous having never given this sort of presentation before. Mostly I'm looking forward to meeting more of the community face to face. I think that this conference will be a big step forward for Habari.
Solidifying roles of members of the Habari Community and mapping the road forward is high on the list of goals we hope to accomplish. I'd like to thank everyone who's been putting this together for making the first HabariCon a major success already.

Habari has a policy that themes and plugins do not include links to designers' and developers' sites. This policy is one that hopes to prevent spam, linkfarm, or other links that make your Habari site an income source for someone else without your approval. However, I feel that one of the major rewards of Open Source development is the "Hey! This is awesome! Thanks." you get when you do good work. To that end, I've made the "Credit Due" plugin for Habari. What it does is gather the author information from the active theme, and any active plugins on a Habari site and makes them available for display within your theme. You can see it in action in my sidebar under "Credits".

I've contributed it to the Habari Community, so you can view it's page on the Habari Wiki and download it there. Bugs can be filed on the Habari-Extras trac.

Let me know what you think!

Habari 0.4 is out, now with (among a lot of other cool stuff) media silos that allow you to easily interact with things like Flickr

Fan-freakin-tastic.

Tomorrow is the first official Habari Bug Hunt. If you're interested in helping code, test code, write documentation, proof-read documentation or otherwise contributing to the project, stop by #habari on freenode.net on IRC tomorrow and see what's up. If you're interested in learning more about Habari and how or community functions, this would be a great chance to stop in and say hi.

There is a lot of discussion happening on the Habari mailing list about the design of the Administration interface. And it's the kind of thing that we're going to have to watch carefully to prevent it from getting ugly. With all the progress we've made, this is one of the first major tests of the strenght of the Habari Community. My own experience in theater has shown me that design is complicated, and the more designers you have working on something, the harder that gets. At some point, when working with other designers, someone's concepts are going to have to be subordinate to another's. If you're putting on a production, and the scenic designer is designing a setting in modern New York City, while the costume designer is basing their designs on 1940's Europe, and the sound designer is using 1970's protest music as their base, you're going to get a mess on the stage. This is why, in theater, it's usually the director who provides the over-arching vision, and a production manager is responsible for coordinating the elements and keeping lines of communication open.

But even so, while it's easy to say "We're going to need X amount of lumber to build this platform." Chosing the shade of blue to paint that platform is something that everyone can have a different idea about without anyone being "wrong".

In Habari we face the same issue. We can agree that a particular bit of code works or doesn't work. And it's usually easy to quantify what's "better" in the code. Does it use less memory? Fewer lines? Is it more secure? Easier to use in multiple places? But things like the width of the text entry fields can have a different answer for every user. In the case of Habari, we've also eliminated one of the simplest ways to resolve these issues. We don't have a person who is "in charge" who can simply say "Do it this way." We don't have a "director" and we like it that way. But this is when removing that centralized authority creates difficulty for the project. We must come up with a model that will allow us to come to a community consensus as to what Habari will look like. Because there is no "best" when you're dealing with something that is primarily subjective, a "veto on technical merits" isn't an option. The common element between where we are in Habari, and what I've learned from theater, is that it's an issue of communication. Designers, coders and users speak different languages and there's always the risk of things being lost in translation. Building common vocabulary is where we need to start if we're going to succeed. We have to take a large number of ideas and somehow create something that is visually appealing, user friendly, innovative and comfortable all at the same time, and we must somehow do this without sacrificing our primary principal of community inclusion.

This is our first big test. I don't know how we'll work through this, but I think we will all benefit from the lessons we're going to learn about how to design by community without ending up with something that looks like it was designed by a comittee.