You didn't notice, but I complete changed the way I look today.

No, it's ok. I put hours, literal hours into looking this good, and you've said nothing about it. But that's fine.

I just thought I would inject a little color into my day. A new, colorful outlook. So yes, it's for me, not you. I probably spend too much time grooming anyway.

This design doesn't look all that fascinating, but it's a great leap forward in Habari's design. This theme uses a few little extra things that won't be generally available to themers until the release of the next Habari version. Let me talk about a few of the exciting bits that are a part of this theme.

I started out with using Yahoo's CSS grid framework for layout. It's nice to offload the CSS to someone else's servers, and to have a kit that is just going to work. I don't have to think overly much about column widths, just apply the class I want and the thing works for me. It's nice and simple.

I added the Cufón javascript library for rendering custom fonts for my headers, which you might notice use a non-standard font. The technique is pretty simple and falls back pretty well.

The more fascinating aspects of this design include the new Habari area and block features. These are kind of like WordPress widgets and Drupal blocks, but significantly improved. All of the things I've ever hated about those other systems are corrected in this one, at least from the API end -- the UI side is yet to be completed. Nonetheless, the components of Habari's core that drive block output are complete enough to use in output rendering, which they are currently doing marvelously.

The only thing I wanted to do with this theme that I had yet to do was change the way the comment form was generated. If Habari could produce a form for new comments that was built using its FormUI class, then plugins could enhance that form (adding captcha, changing required fields, etc) without having to use crazy buffering or inserting hooks all over the form output. I was hoping this part would be done, but having the rest of the theme complete I didn't want to wait, so I just used a standard comment form.

There are some other parts of the old theme missing that I will eventually bring back using blocks. But I want to get some of the UI stuff done for blocks first. Then these features will be accessible to anyone.

“I am trying to port a WordPress theme over to Habari the only way I know how. Step 1- Make mess. Step 2- Flail around making mess worse. Step 3- Somehow clean up mess miraculously. Step 4- Make another mess and repeat process.”

This kind of thing is an indictment of what Habari is all about. our community has been struggling for some time to produce themes as easily as some other publishing systems. Since there are a lot of themers coming from WordPress looking into Habari, they're looking for similar features in Habari's theming system that aren't quite ripe for use. There are actually a lot of places in Habari's theming system that could use some work.

One of the places that people get confused a lot coming from WordPress is with the "more" functionality. This functionality in Habari is provided by the Format system as controlled by the theme. The reason this is associated with the theme is because some themes will want to display a specific amount of information in certain places. For example, when displaying your home page, the first post may show the first three full paragraphs, but the subsequent listing of posts may only show the first sentence or two. With Habari's formatting system, this is possible. But more importantly, this preference would only be for that theme -- if you switched to a theme that wanted to lay out your posts differently, you would almost certainly not want to use those lengths of truncation. The interesting part is that there's a weird mix of flexibility versus coherency.

Another thing that is evolving in Habari theming is what I like to refer to as "WordPress versus Drupal theme styles". By this, I don't mean that Habari will be able to use themes from either of those systems. What I'm referring to is the style of construction whereby those themes are built.

For example, WordPress themes are built such that every template file is designed to output virtually a full page. Each template includes a header, footer, and the content. For displaying a single post, there is one template. For displaying many posts in a list, there is a different template.

By contrast, Drupal has a single page template that has a kind of hollow body for content. The content area is filled with the type of content that fills a request. So if you request a single post, the same template is used to generate the wrapper, but the template that renders a single post is used to render that post's content, and it is inserted into the hollow space in the wrapper. Likewise, if you request a listing of posts, each list item is rendered using a template based on the type of item it is, and the accumulation of these is output into the wrapper.

These styles of rendering are two completely different mindsets. Habari supports both.

Even with the potential for goodness in the Habari theme system, there's still a lot more ground to cover. What we should really do is build some functions into the theme system that make it as easy to work with as some of the WordPress "template tags". I'm not suggesting that we move away from the OOP approach and go functional. I am suggesting that we provide a more complete basket of template-building tools, including more primitives for output.

At the same time, we need to expand and revise support for things that we already do in a strange way. For example, the pagination functions are just odd. There isn't a clear path for expanding on them, and I think they're sometimes faulty. These things should be themeable, so that theme authors can easily make the pagination look like whatever they want.

Also, there are some things that are completely missing. I'm hoping that for version 0.7, we can add some impressive new features like content areas and blocks. A block would be a chunk of content that can be placed, and an area would be a place in a theme pre-determined for the placement of blocks. Blocks could be provided by plugins or the core system, and would be configurable in the theme settings for the theme. They could be used to display all of the standard stuff: Tag clouds, blogrolls, "about me", Flickr badges, etc. And the blocks themselves would be themeable, so if you had a plugin that provided a block with a basic template, you could make it fit into your theme better by providing a custom template explicitly for that block.

There are many other theme-building enhancements that we should consider for 0.7, and making theming easier is a good focus for the next release of Habari. Making it possible to more easily translate themes from other systems will make it easier for theme developers to produce a Habari version of their themes at the same time as their WordPress or Drupal versions.

At Drupalcon, there was a recurring theme of "do-ocracy". Simply explained, a "Do-ocracy" is Drupal's version of a meritocracy. Well, it's not even so much Drupal's version, as how people perceive the way that Drupal works, or how they choose to explain what a meritocracy is. Being involved with Habari and our own brand of meritocracy, I'm glad that they've come up with their own ridiculous term to explain how their project works.

As part of the definition of meritocracy on Wikipedia, you have this:

In a meritocracy, society rewards (by wealth, position, and social status) those who show talent and competence as demonstrated by past actions or by competition.

That's the ideal scenario. But what the folks presenting do-ocracies at Drupalcon are advocating is something slightly different. They're giving wealth, position, and social status (or whatever the open source equivalent is) to people who simply "do", not by people who show talent and competence. That is, your work needs to be of no merit, you simply need to do it. That's not right.

Shouldn't there be some implication that a meritocracy involves contributions of some merit? I expect that the Drupal project would choose to award additional project rights and responsibilities based not solely on volume of work, but on its usefulness or importance to the community. Some will point out that this treads a somewhat dangerous road.

The main reason this is controversial is that there needs to be someone or a group that decides what has merit. Who is to say that one person's 35-page dissertation on the virtue of the l() function has more or less merit than a patch that enables OpenID logins? And how do you even start making those comparisons of worth?

I think that's where the cop-out is that leads to this do-ocracy. I think people see that difficulty and are unable or unwilling, most likely because they don't want to subject themselves to the resulting community abuse from their decisions, to decide what things have merit. Instead they simply give credit to anyone who can "do". So what's wrong with that?

The result of the do-ocracy is at least twofold. First, the people who do a lot, and I'm talking volumes, get more credit, regardless of the quality of their work. One might think that if you wrote a resource full of errors and misconceptions that it would be shunned. But in a do-ocracy, this should not be the case. Deciding on merit would result in that outcome. Bottom line: People are getting credit for contributing crap.

Second, the level of acceptance of anything done is high. So many people contributing a lot of code results in a lot of code (and documentation, and testing, and... etc.) being accepted into the main project that is not good. Bottom line: The project gets filled up with unvetted crap.

In the case of Habari, where we like to think of ourselves as implementing more of a meritocracy, the value of the contribution is considered before it is accepted. This is my controversial point in my own social group. I personally believe that contributions need to be qualified for acceptance. We should accept all contributions, but there should be no expectation that every contribution has merit. There are some in the community that assume that their contributions should be accepted blindly as in a do-ocracy, and that they should be awarded due credit for simply contributing, even if the quality of the project is reduced by their contribution, the functionality they've provided is not welcome by the community, or their contribution is not in line with the direction of the project as a whole.

The inevitable question is, who decides what has merit? Usually, it's decided by the existing managing members of the project. This is how meritocracies come to be thought of as "old-boy's clubs". If you weren't in at the beginning, then you're already a step behind in getting your contributions accepted. You're being excluded because you're not "in the club". The problem with this thinking is that this is how these organizations are supposed to work, and it's beneficial that they do so.

Think about it. The body of organizers is self-selecting. Why would a management committee elect to include another member who didn't share their philosophical beliefs about the project? They wouldn't! Likewise, they would not accept contributions as having merit that do not also align with the originally established philosophy and direction of the project. Granted, those beliefs would get diluted and permute over time, but there would be such an established culture that new contributions would necessarily have to fit into the consistency established by the early members.

I've exaggerated many things in this post, especially about the Drupal process of accepting contributions, simply to make my point that a do-ocracy is not a meritocracy, and that people who consider meritocracies as working primarily on an unvetted, volume-based submission queue are wholly incorrect.

It was bound to happen to Habari eventually, right? And in the dark recesses of my mind, I'm happy for two reasons. First because at last we merit inspection by "security consultants". Second because we are staffed well enough to have addressed the issue within a reasonable amount of time. But some questions have arisen about how to handle security announcements, and there are distinct sides on the issues.

Spinning out of Control

People are going to publish security notices about your software whether you want them to or not. Sometimes there is altruism at work - people want others to know that something is unsafe. Sometimes it's open malice - people sharing secrets of how to exploit software for their own malicious uses. In either case, as a software author, you can't control what people say about you, and specifically what exploits in your software they expose to the world. So in the end, security exploits result in more spin control than controlling the information.

Obviously, the most powerful thing you can do to spin the news in your favor is to provide an immediate release that addresses the issue. This may be harder to do with smaller teams, since you have so many fronts on which you fight: New features, documentation, support, bug-fixing, and now security-notice tracking. An advantage with open source teams is in the speed with which you can address the issue quickly and reliably, since there can be many people working at once.

Of course, when you have a fix for the issue, you need to tell people that the fix is ready, and that they should use it. I think the announcement, rather than the circumstances around the issue itself, is the point of most contention.

Human Factor

There are a lot of things to consider when crafting the message to go along with your release. I've been given some advice over the past couple of days on how to handle it, and I'm not really pleased with any of it. What people have been suggesting to me is that since anyone can publish a full step-by-step tutorial about how to hack your software on their own site, that there's no reason to avoid doing the same on your own site. I think these people, who must be on the outside, often forget the human factor.

Having a critical release announcement is more than just about the exploit and how to properly deal with it. In most cases, the critical issue affects many live installations of your software. I do not expect that explaining to the bad guys how to exploit someone's install of your software is the best way to engender loyalty to your product. Publishing those instructions in plain view on the product's own site seems unwise for that reason alone, even if those instructions are available in a myriad of places.

The rationale for publishing the instructions is that this will give users the information they need to decide if the critical update is something they need to apply. This rationale is mindbogglingly naive for a couple of reasons.

What Is a Non-Critical Critical Update?

When the developer says that an update is critical, should you believe them? Who knows better than the developer whether an update is critical or not? I would guess nobody does. And if you don't trust the developer, then why are you running their software?

In this age of all-too frequent "critical updates" for popular operating systems, we've become somewhat numb to the word "critical". Still, if you found yourself affected by an exploit that a critical update might have addressed, would you not consider that critical? I think it's unfortunate that critical software updates have become optional; something that you can choose to put off at your own discretion, as if you know better.

It says "critical". Update or suffer the consequences.

I agree that to some extent it's a matter of trust. If you do not trust a developer to label things as critical when they are indeed critical and not trivial, then you might put off updates. It's like a developer crying wolf.

Habari has a system for distinguishing critical updates from bugfixes and feature releases. Because we're pre-1.0, we haven't had a lot of opportunity to do bugfix releases, so users might see all of our releases as critical and not realize that we would actually distinguish them if there was a reason to do so. It just happens that we're doing all of our significant bugfixes along with feature releases, so you only really currently see critical and feature releases. Don't mistake that for us thinking that every future release is critical!

Isn't there a weird psychology where people will upgrade immediately for a feature they want, but not for a critical "takes your server down and eats your first-born" software update that's simple to perform. Unreal.

I'm a User and I Know What I'm Talking About, I Think

The other problem with giving users all of the information is that they most likely have no idea what to do with it.

This recent critical issue with Habari was a XSS issue. If you know what a Cross-Site Scripting issue is (and I'm not even sure that technically it was that, or maybe it was a specific subset of XSS -- I digress) and how to exploit them, then you don't need me to explain it. You can easily visit the open source code browser and see what code we changed to see how you could affect the XSS.

On the other hand, if you have no idea what XSS is, then the only thing you'd take away from an explanation would likely be "XSS is bad, and I should upgrade", which is easily conveyed by "You are encouraged to apply this critical security update immediately."

In either case, there is no need to lay out specifics about the issue, and there's always the mailing list or IRC if you are interested in what the issue was and can't figure it out on your own.

When you combine this with the thought of being prudent about posting the details of the software exploit on the same site where the software is distributed, perhaps you will come to the same conclusion as me -- you really shouldn't provide too many details on the main site feed. I'm personally of the opinion that common users will appreciate more that malicious users can't as easily find (and what would be easier than having those details right on the software's home page?!) the way to exploit their sites than they will that they have full detailed instructions for performing the exploit themselves. Why on Earth would they do that anyway?

What Are You Hiding?

I'm not saying that security updates should be hidden. I think people hear me saying the above and interpret it as me wanting to hide something that is in plain view elsewhere on various security clearinghouses. That's not what I mean at all.

In fact, I think it would behoove us to report our own issues to those clearinghouses as they occur. People watch those lists who are intelligent and have experience in dealing with and testing those issues. We'd be grateful for their help.

Nonetheless, I think that some restraint should be shown in regard to spilling the beans on security issues directly to the primary forum for any software. I don't know of any major software vendor that exposes step-by-step security exploits to their home page. Habari shouldn't do this, either.

A balanced approach is warranted, one where we tell users that they really must upgrade. With security upgrades, we should never say, "You might choose to do this if you feel like it." No, you really must. Your site exploited could potentially affect me or anyone else, if used for spamming, for example. Be a good citizen.

The balance should be that there is enough information in the announcement to send curious developers who need to know (Really? I'm curious who these people are.) to the mailing lists or source code repositories for the information they need.

And so, Habari 0.5.2...

All that said, Habari's recent security flaw isn't so awful. There is potential for data loss, which is one of the criteria we've outlined for an immediate release. But it's only if a malicious user figures out how to use the exploit in a certain way, and only if they trick you into using it. Still, the potential is there, so there's a fix.

If you haven't updated to 0.5.2, you really should. I hope that real Habari users perceive our response as proactive, and if they have concerns with how we've handled security updates in the past, they step forward and voice their concerns on our users' mailing list, where developers listen to users' needs.

Alex and I have been going back and forth in comments over the areas of our interest that overlap. In his recent post, he asks, "how long can organic communities self-moderate?"

I admit that I haven't read the Starfish and the Spider, although I did just one-click it into my Kindle, so it's doomed to suffer my analysis. Nevertheless, I had some comments about how leaderless organizations can thrive, particularly in open source communities, of which I happen to be a part of a couple.

Obviously, one of my passions is working with Habari and the people that have come together around that common goal. When we started, there were just four of us, each with various levels of ability and availability. I think you can pretty well call that "leaderless", since we all worked in tandem, and any small change any one person made was easily detected and reviewed by the other three. But as the project has grown, I think there is some kind of tragic irony in that the size of the operation inevitably leads toward a need for at least an informal management structure.

Of course, any of the Habari folks reading would rightfully start screaming at my last statement. The cornerstone of our philosophy is that no animal is more equal than any other. Still, without naming myself supreme ruler of the project, I think there remains a practical aspect to several individuals having responsibility for making things work and controlling the direction development takes.

What I've always hoped with Habari is that the community would fracture, but in a good way, and that the different aspects of the system would be able to communicate with each other in a way that is productive for the whole. An example of this came up today regarding our published documentation.

We've been using TiddlyWiki for our distributed documentation - the manual - which is supplied with the source of the software, separate from the online wiki. Basically, the large online docs have been distilled into a neat little dynamic wiki manual that comes with the software. A few folks who are less technically inclined decided to make documentation their project, and upon reviewing what we had, concluded that the manual was nice but not internally consistent, because it simply pulls parts of the larger wiki. As a result, they have started rewriting the manual as a single cogent file.

Following pointing out this effort on IRC today, I was asked by the person who originally suggested TiddlyWiki for the manual as to why we were dropping TiddlyWiki. My response to him was basically that some folks had decided to own it, and what they were doing was probably better for the project in the long run, and how could I not support that? And I think he agreed with my reasoning. But also, a personal reason - one that might or might not have been implied - was that I didn't really want to have anything to do with the manual.

I long ago realized that I simply can't keep the whole project in my mental scope any more. Back when it was just four guys, I could keep track of every change. Now there are 25 PMC members, and many, many more contributors and users that supply insights and patches with a regular flow. I can't possibly track it all in a way that makes my own contributions worthwhile. So I've decided that if people come along that want to manage a part of the project, they present their ideas well, show some vision I can get behind, and lead other people to follow them there -- I am behind that effort. And those are the people we're looking to promote to the PMC as leaders anyway.

To that end, we've been working out a way of handling when splinter groups want to take on specific tasks like these. We call them "working groups". The concept may be familiar. We started out with some formal guidelines that explain how the groups must be formed and to whom they report, and many of these processes are followed and documented, but personally I think that even as informal groups these units work fine.

The key feature is that there is always reporting back to the main group. They make plans and present them, and the main group has the opportunity to provide more insight, to join, or to dissent. Although the working groups may go off on their own to implement the plan, they don't do everything in secret or behind a gate. Anyone has the ability to shift in or out of a working group as his interest dictates.

This has been working well for documentation as well as code. Some of our larger initiatives have started out as branches created by others who want to work on a specific task together. The larger group provides some oversight, but the working group is mostly autonomous until the code is submitted for merging. Then others review the code as necessary.

I suppose it's easy to quantify the project in terms of output, but longevity has a lot to do with the social formula too.

Completely separate from the users of WordPress, the community of developers for WordPress used to spend quite a lot of time talking on IRC. At some point, because this relationship was not encouraged, the heart of the system died. Now on the WordPress IRC channel, some developers might idle, but it's mostly a desolate place where people come to ask questions that echo into the oblivion, unanswered.

I assume that the social structure for WordPress has moved elsewhere. Perhaps it's within Automattic itself, or in the halls of the many competent WordPress consulting companies that have formed. But it has changed over time.

I'm hoping that we've made some decisions early on that will affect how Habari lives and works long-term. We may individually have plans for making commercial moves with Habari in the future - not Habari itself but services around it - but the social network (not Facebook, but a network of real people) we're trying to build will hopefully stay strong until the project is obsolete.

Being a worldwide community, we rely on leaders even in different timezones. When I sleep someone is leading the community. Even when I'm around, I'm not always "present", and other people fill in. Part of that is related to how the project gives people more control, more involvement. Part is that the people actually care to do it. When the people who are involved don't care any more, they should move on. I hope that we can keep adding people who care enough to keep things going as much as I do.

I'm not really sure that answers any specific questions, but it's how things are, and how we've managed to survive this long, and hopefully what will keep us moving.

I've just finished a science fiction book by Vernor Vinge called "A Deepness in the Sky", and one of the themes of the book is technological collapse; how civilizations can only live so long and evolve so technically before they implode. The trading race that travels and trades between these civilizations sees everything and deals with everyone. Along the way, they record this knowledge and the knowledge makes them great and lasting. By adhering to a set of social rules and general beliefs, they are able to outlast their customer civilizations. It reminds me quite a lot of what I think organic communities need to survive, not so much that a strict process is followed, but that the entire race of people shares a belief that powers their way of life.