Hierarchy in Open Source

Governance in an open source community always varies from project to project. Typically it's along the lines of a meritocracy, where community members' participations are weighted by the quality of each respective member's contributions, but not always.

But one thing a community should not be is completely governed by the management hierarchy of any companies that sponsor that project.

I know what you're thinking. You're thinking that this kind of statement might be a bit hypocritical coming from someone who works at Red Hat, a company that is built on open source technologies and a very strong participant in free and open source projects around the world. Surely we have managers and employees here have hierarchical positions that match the maintainer and contributor structure of the projects in which we are heavily involved.

Well, sometimes that is the case. But a lot of times, it is not. Many of the projects with which we work have other companies' employees and independent contributors and they have their own responsibilities within the projects that don't mirror their "positions" in the corporate world.

And that's really the way it should be.

The reason I bring this up is that every once in a while, within and without Red Hat, I will hear a conversation that goes something like this:

    "I think we should do this [for Project X]."

    "Really? How would we do that?"

    "Well, we could [followed by excellent lengthy technical explanation]."

    "That's amazing! You should do that!"

And then, the reply that kills me:

    "Well, it's not really my place."

Cue head exploding.

Now, I realize that some of this might be the ol' "What? Me work?" syndrome, but I have heard enough versions of this conversation to know that this is more than just a bunch of unmotivated people. They genuinely don't think that, because of their position in whatever organization they work, that they have the "authority" needed to make large contributions to the project.

This is a tricky problem to solve, because adjusting from corporate hierarchical thinking to project meritocratal isn't easy. You want project hierarchy to be freeflowing based on merit, but you don't want mass anarchy in the workplace, either.

The most important responsibility lies with managers, really, to empower their employees to understand that taking initiative and even the lead on aspects of an open source project is not prohibited, and in fact should be encouraged. Allowing developers and other project participants play to their strengths not only strengthens the project and its community, but will ultimately make better employees in the process.