A community of technology community managers, leaders, and builders.

Governance styles


#1

I thought it could be useful to kick off a discussion about governance. There are many different styles and methods of how communities can be led and coordinated, and the majority of my own personal experience has been with the Ubuntu community.

In Ubuntu we have two primary leadership boards:

  • Community Council - this board manages and defines overall community policy and procedures.
  • Technical Board - this board manages technical policy in the project.

Both boards are volunteer led (Canonical don’t require seats for employees other than Mark Shuttleworth, the founder), and have serves the project generally pretty well.

There are also more domain specific boards that report to the Community Council such as the IRC and Forum councils.

This form of delegated governance has been a pretty effective method of independently managin community process and functions while also not bottlenecking decisions in the platform (decisions about features/technical choices are made by developers, not by governors, and rightly so).

There are of course other methods of governance such as dictatorship, leadersless governance, and concensus based leadership, but I have always found this delegated model has worked best.

I don’t want to to assume this is the best method in all cases though, so I am keen to hear other folks’ thoughts and experiences with different governence models.

Feedback welcome!


#2

I’m also very interested in this topic. Our project has been around 10 years now … with no formal governance structure, but then again, growing very slowly. But we’re at the point now as our growth is much faster where we know we need something.

However, many people seem to be very wary of the apparent “bureaucracy” that things like councils, boards, commitees, etc. may represent. They want the ability to “get things done” without decision making processes being in the way.

So I’m curious if any other projects who have adopted governance models late in the game have encountered these types of reactions or fears … and more importantly, how those concerns were overcome. Looking forward to hearing more.


#3

I think beaurocracy is definitely a risk with any governance model.

My view on this is the same as applied to any processes in a community: approach each process from the perspective of how we can make things as efficient as possible, and reduce any unneccessary steps.

I think one of the problems with some governance processes is that people feel they need to have extra steps or precautions in place to provide for any and all possible outcomes. I would instead recommend that you optimize the governance board for the most likely and logical requirements and focus there more.

There is one critical risk with setting up formalized governance though: changing and refining how the governance works can be difficult in communities with radically different views of how the community should run. As an example, if you have a community that has two possible directions to move forward in, and your governance board is split between these two perspectives, people can get entrenched, much like traditional politics.

As such, a key feature in good governance is having the ability to make changes and improvements without kicking off an overly complicated procedure for said changes. If you require a proposal, RFC, voting period, final assessment, and secondary assessment board for every change, people are going to get pissed off. :slight_smile:

Overall though, I think the true antidote to worries of beaurocratic processes is making processes efficient. Demonstrate simplicity and the naysayers will be convinced.


#4

Good timing, we’re working on governance and organization structure in two different groups I’m involved with in the Clojure world. I’m curious to hear about what has and hasn’t worked out for folks since we’re still in research mode. It’s hard to gather this type of information just by looking at the final bylaws, etc. listed on organizations websites since we don’t get to see the decision tree that led to those documents. Definitely interested in discussing this next month.


#5

Hi Michael,

Subgroups always works well as a way to scale - you want to aim for loosely connected networks of people with mavens who inter-connect, with enough centralization of information and resources to enable the projects to operate without too much overhead, but not so independently that they end up floating away.

The key is to maintain a strong project identity, but to allow and encourage sub-identities to exist inside the project where people meet and work in smaller groups. You can influence what constitutes a subgroup and try to channel efforts in a productive direction, of course - and watch out for less healthy subgroups forming (for example, in a community project, when you have subgroups forming around corporate allegiance, that can be unhealthy).

Dave.


#6

Hi @dneary. I tend to agree with this, but it has yet to be proven in our project to any significant degree. However, this is probably the approach we will end up using as we grow. Essentially a “bottom-up” vs. “top-down” approach.


#7

Glad the timing is working out. :slight_smile:

What are you looking to achieve with your governance? Maybe people here can provide some tips. :slight_smile:


#8

I think this is a key point, but ultimately tough in practice.

A good example of this is Ubuntu LoCo Teams (advocacy groups). Way back when when LoCo teams were formed, it was agreed there would be two types of team:

  • Approved - these are teams that are recognized as delivering significant and sustained work. They are entrusted with more resources.
  • Non Approved - these are any other team that has not yet demonstrated itself.

To become an approved team the team must meet a set of guidelines, one of which being that they are are suitably categorized in their location. So, for example, the policy was and is that most teams should cover a set geographic area.

Of course this varies. For smaller countries the LoCo team is expected to cover the full country (e.g. Ubuntu UK). For larger countries (e.g. US) the teams are divided up by state (e.g. Ubuntu California). It was and continued to be looked down-upon to have multiple teams within a set geographical locale (e.g. Ubuntu Northern California and Ubuntu Sourthern California).

While this served the primary governance function of neatly dividing up teams, it has generated more hoops to jump through when people just want to hang out as a team.

My thinking has changed here. I think teams should just get together and do cool stuff, whether that is Ubuntu California, Ubuntu San Jose, or Ubuntu “My Group Of Friends”; all are groups designed to spread the word.

Of course, this is tough to implement and isn’t there yet with Ubuntu, but I just wanted to share this cautionary tale. :slight_smile:


#9

I think it’s a matter of how you think about leadership. Sure you can define leadership as making the decision but my personal experience is that it’s actually more about helping people to nurture their interest and to solve conflicts. Leadership is the oil in the “those who do, decide”-machine, not the operator.

I guess that’s because most of the people in a healthy FOSS project are there to collaborate, not to be told what to do. Sometimes though they need someone they can summon to solve conflicts of the personal or technical nature that they can’t work out by themselves. And way more often, in my experience, people need someone that provides them with advise or resources.

If your community thinks about and handles leadership this way, added “bureaucracy” doesn’t really matter anymore.


#10

Mozilla uses a Module Ownership Governance Structure which is a form of meritocracy since Module Owners and Peers are working on the areas of the project they own and drive.


#11

Indeed, depending on branding, technology, likely community participants (and to a degree, the corporate culture where most of those participants work!), and the actual shared goals of your community, there are a lot of different “best” governance models.

I’ve documented the Apache process at a high level here:

http://www.apache.org/foundation/governance/

Essentially the ASF has a small core set of invariant rules (Apache License, Apache Foo project branding, +1/-1 voting and committer/PMC governance by merit, core infra services run by the ASF), a whole bunch of best practices, and a whole lot of wildly varying projects. So when you talk about “how Apache does X”, you’re really talking about how 150+ different top level projects (TLP) do it.

The essence to contrast with your Ubuntu description above is that the ASF has a Board elected by the Members that appoints corporate/executive VPs to set core policies and run branding, legal, infra, etc. operations for the Foundation (as a corporation) as a whole.

Then, we have 150 TLP Project Management Committees (PMCs) that each independently govern their own project’s direction and community management. From the ASF level, there is zero top-down technical direction: projects are completely free to manage technical affairs themselves, and the ASF is happy to even host competing technologies or projects. So the ASF board is a little like your Community Council, and each individual PMC is kind of like its own Technical board.

Separately, as a 501C3 public charity, the primary mission of the ASF is to produce software for the public good. From that core principle, we also mandate that individual Apache projects be governed independently of undue commercial influence: our goal is to give away software at no cost for everyone. So this is a really important essay to read to understand the Apache Way:

http://community.apache.org/projectIndependence.html


#12

Indeed, for many organizations this is the key question: who owns the brand? That is, what specific individual or legal organization actually owns the trademarks that define the brand that the outside world perceives as “that Bar Project”?

Overall we’ve come a long way with getting the world to understand licensing differences and what that means to users/downstream; understanding the difference between open source and open core; and how community vs. corporate led projects work. But the next question (at the high level) is getting people to understand how branding works in this context.

Take Node.js for example. Permissive licenses, they’re working with community, great technology and people. But Joyent owns the trademark. So on the community side people can try to make changes or lead the project, but outside of the geek world, most other organizations see Joyent as in charge of the Node.js project, because they own the trademark.

That’s not necessarily a bad thing. But it is something that people - especially community management types and open source contributors - need to understand and make clear. We all get excited about the latest technology, and we all have an idea of who’s really on the inside at various companies. But the rest of the world - both individual users and especially corporate users (i.e. other vendors who might have a lot of IP or engineers to contribute to our projects if they were interested) sees the public brand and the trademarks (and news reports, and analysts, and…) about our projects. So we need to be clear about the brand ownership of various projects.

That’s one of the reasons contributors come to Apache, and other 501C3 organizations: the ASF itself owns all Apache project trademarks, and as an organization the ASF itself will defend it’s projects marks, and ensure that Apache projects allowed to continue as independently governed projects, always free of charge, and always welcome to new contributions.


Thanks to for being the kind sponsor for this forum!