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.


Playing devil's advocate, I think the idea of a do-ocracy is that if someone submits something crappy, someone else will counter it (eventually) with a superior submission. The original submitter would ideally stick around -- they feel empowered to engage, already -- and learn from the quality of the latter submission.

People being people, though, I think a do-ocracy is a real invitation to trouble in a project as big as Drupal.

>Why would a management committee elect to include another member who didn't share their philosophical beliefs about the project? They wouldn't!

The technique is called "creative tension", and projects without it often descend down the garden path of interminable process discussion. Non-believers, skeptics, and heretics generate creative tension.

Possibly too much for some projects, not enough for others. But dissent is not sabotage.

Yes, but there is a clear difference between bringing into the group someone who has different ideas about how to accomplish the overriding goal of the group and someone who has a different idea of what the group itself is about.

I posit that Habari is more than just a project for creating the software, but is also indelibly tied to a philosophy about community as its mission. Not accepting and promoting this philosophy is equal to a desire to turn the blogging software into an actuarial record (or something similarly not at all like blogging), therefore not acceptable in a person who would be admitted to the project's primary management committee.

Creative tension is good as long as you assume that everyone is working toward the same goal. You invite someone in with the hope that they'll perpetuate the existing goals, not try to subvert them.

Creative tension should also not be confused with tension as a result of poorly considered contributions.

In your first paragraph, you say you accept different ideas about *how* to accomplish the overriding goal. But the in the second, you promote the methodology to one of the overriding goals of the project.

I don't know how to better sum up the danger I perceive.

Habari positioned as a kind of social meta-experiment sounds grandiose, I suppose, but isn't it digging into ground well-researched by a few hundred thousand projects before?

What I have said specifically is that I won't rush out to join any other Apache-style projects, because they are process-heavy. I'm interested in how that might be trimmed to make the style more effective in this particular project, and I suspect that would make the community itself more "healthy" or whatever as well, but that part isn't really interesting to me. Software is interesting to me.

To me, dissenting from and trying to improve the project's procedural sticking points is *not* tantamount to wanting to make an accounting package out of Habari. But you might want to bring in the accounting guy, too. His craziness could likely help generalize the lower layers of the software in ways that would benefit everyone. If good design is building things that people do unexpected things with, people like this give you special insight into what those unexpected things might be. They make them less unexpected.

You should check out 'Team of Rivals' by Goodwin ?

I argue there's a place for everyone, and that "the process" is about making *that* happen, if it's some kind of social or evolutionary experiment. Rich Bowen seemed to argue something similar on the list a few weeks back & gave me warm fuzzies about the Apache style. What you've written here doesn't do that. Which one do I misread?

I notice I've drug the comments a bit away from the post, so I should probably note: I haven't had trouble getting patches in. I haven't sent up as many as I'd like to. There are technical, not project, reasons it could be a little easier to do that. But as for accepting them, I agree completely with you that merit shouldn't be assumed. In fact, no single patch ever seems to be discussed enough, challenged enough, etc. We agree on that, and I didn't address it at all in my previous comments.

Thanks for letting me flood your blog.

Maybe it's better to have more people with alternate views, but as an extreme example, I simply can't imagine inviting WordPress' active developers to have a voice on the project en masse. This would seem more destructive to the reason Habari exists than beneficial.

For there to be an extreme that you can exclude, there must be a line in the middle somewhere that can divide those who share enough of Habari's ideals to be included from those who would dissent too much and change the nature of the project. I think that's a hard line to draw, but a personal choice that each PMC member should make when weighing their votes to admit new members.

For what it's worth, streamlining the process of project management would be a great boon for Habari. It's certainly not something I would eschew.

Regarding "Team of Rivals", have you seen the response by Dickenson College's Matthew Pinsker? Organizing a Team of Rivals is a strategy. But since there's no rewinding time to find out what Lincoln would have accomplished with a cabinet full of people who also shared his vision, it's hard to say if that tack should always be taken. I'm of the mind that dissent is ok, but there has to be enough similarity in direction that you have some common ground. Let that common ground be the project's raison d'etre.

I know Pinksker's work about the Soldier's Home and c., civil war stuff. I hadn't seen his column. I'm actually less interested in Lincoln as an example that Roosevelt, who's long term in office saw two different teams and gives you some of the comparative rewind you wish for. The first team produced the new deal. The second team produced... Truman. Goodwin's book just happens to be out there and is a single index to a reference, instead of the several volumes of Schlesinger's Roosevelt work.

That part of my comment got eaten along the way. It came after an ampersand & I either mis-edited or it was cut out.

Sorry, commenting on this post is disabled.