Drupal's Governance

GovernancePlanet Drupal

This is the third in a series on governance and Drupal in preparation for the Drupalcon Denver Core Conversation on The Future of Drupal Governance. The first article discussed What is Governance and the second How Do Open Source Communities Govern Themselves?. Read all, Governance project on drupal.org, Drupalcon presentation video.

Drupal's governance structure is so lightly defined that when I searched for Drupal governance the primary article I found was this one on drupalmyths.com denying that Drupal's governance is poorly defined. Certainly nothing showed up on drupal.org. Of course, these things can use words other than the formal word "governance", but there really isn't much written about this topic.

Here is my description of Drupal's governance. I am certainly interested in your reaction to it in the comments:

  • Dries as Benevolent Dictator has the right to lead core development and make final decisions about any number of issues, but mostly key core development decisions.
    • He is expected to separate his business interests from "what the community needs".
    • He is not expected to intervene in the vast majority of community issues.
  • Core, contrib, documentation, infrastructure disagreements are handled almost exclusively through a "Do-ocracy" and a "consensus" model. In other words, if you think something is important, you bring it up. If you're willing to work on it, you may have the power to make it happen. But you still have to step over the "consensus" barrier, which means that 1) you have to get somebody else to care about your issue in the first place and 2) you might have to use your persuasive skills to get people to agree about your method.
  • The Drupal Association handles money and Drupalcons. The DA does have formal and explicit governance structures, and takes these very seriously. However, except when it intervenes by choosing to fund a development or similar initiative in the community, it has little impact on the community's day-to-day governance, which is Do-ocracy and Consensus.

Great Things About Drupal's Current Governance

  • In a do-ocracy, you can get things done just because they need to be done. That gives a special pre-emptive power to nearly everyone.
  • It's worked for a long time, and we have a great community.

Problems with Drupal's Current Governance (and risks of not changing it)

  • We often lack a strategic focus in attacking problems (or features). Whatever someone wants to do and has the energy to do (and doesn't get vetoed in the "consensus" process) ends up being what gets done. These tasks unfortunately may not the most strategically important tasks for our community or the Drupal product.
  • Lack of predictability: Because there is not a clear decision-making structure, it's difficult to know whether a given initiative can be successful at any level, even if expert technical resources are applied in adequate quantity.
  • When consensus doesn't come easily, a number of negative outcomes may result:
    • Nothing gets done at all.
    • Feelings are hurt, potential contributors leave the field.
    • Getting something done takes vastly more energy than it should have.
    • The issue can take on the aspect of (in webchick's words) a smoking crater. Smoking craters of destruction are not good for our community. Any of us can list a pile of frustrating issues still mouldering under the smoke of bikeshedding.
  • We have no (almost) structure for properly resolving conflicts. Unlike many of our sister projects, we have absolutely no mechanism for mediating or escalating conflicts to a resolution point. The only thing we have is the big hammer of a Dries decision, which happens very rarely.
  • Prized contributors can waste time and energy on initiatives that never go anywhere or are vetoed by lack of consensus.
  • People we care about can walk away from the community** or from important areas of development just because there is too much heat there.

Risks Of Building More Governance Structures For Drupal

  • Increased formalization (one obvious path) might offend some community members for philosophical reasons.
  • Increased formalization might cause community members to become more passive ("They" are in charge of this, so I don't need to get involved.)
  • What we have has worked so far. Changing it might have unforeseen consequences.

I'm sure you can read between the lines: I think we should deliberately build more explicit governance structures into our community, and that we should do it without bikeshedding :-)

Again, I welcome your comments both here and at the Core Conversation Wednesday, 21 March, at 2:15pm in Denver.

Resources

Original Article: