Sharing Nicely

This is part II in an open ended series on useful lessons that P2PU can learn from open source software communities. I am looking specifically at issues around governance, and culture.

Governance

As open communities grow, governance becomes a (fascinating) challenge. If you want to scale, and P2PU does want to scale, you need more people to feel ownership and take responsibility. That can be scary for the people who started the project, because how do you retain focus as more people with more (and different?) ideas arrive, and how do you preserve a sense of common values and culture?

I spent some time investigating how open source communities deal with issues of governance to see if we can learn from their experience. There is a great video on poisonous people in open source communities, which touches on a lot of issues that are relevant to governance of P2PU, although I think it’s better to frame the topic in a positive way. Rather than fighting against poisonous participants, it’s really about creating a healthy open source community. The video is long, but worth watching if you have an hour over lunch or so: http://sites.google.com/site/io/how-open-source-projects-survive-poisonous-people

The difference between decisions and discussion

It’s ok to have different levels of responsibilities, but communication has to be transparent and open. People often think the essence of open source is that anyone can do anything. That is far from true. Open source projects generally have clearly defined levels of quality control and responsibility, and processes how participants can gain such responsibility. Usually, only a small group of developers has the right to “commit” new code into the core application. Other developers can submit their proposals for new or improved code, but these suggestions are reviewed before they become part of the application. Usually the developers who already have commit rights can grant similar rights to more people, effectively promoting them based on their contributions to the project.

While the core group is trusted to make decisions on behalf of the community, all discussions and deliberations that these decisions are based on, happen in the open and anyone can in fact add their voice and opinion. This is fundamentally different from traditional organization, where typically the people who make the decisions discuss them amongst each other, and then announce certain developments to the wider community. In open source projects these discussions are open to all. This provides a constant check on the decisions of the code committers, because there is no room to hide bad decisions, and it turns the role of accountability on its head. In open source, the ones who have special responsibility become accountable to the community, rather than the other way around. The only discussion that remains private, is the one focused on promoting new people to higher levels of responsibility – in order to avoid embarrassment to the individuals.

There are some important differences between software and P2PU. We don’t have the focus on a single artifact (the software code) that everyone works on, and which has to function together. The closest thing we have to software code are courses, which are typically designed by one or a few individuals, and which don’t rely on each other to function as a whole. One way we could map the concept of a core group of “committers” would be in the form of course shepherds. Only trusted community members, who have earned this extra responsibility can “commit” a new course to P2PU. I can see lots of complications with an approach like that for P2PU, but it is an avenue worth exploring.

A lesson from open source that is easier to implement right now is the opening up of discussion and deliberation. Currently, P2PU has three tiers of conversations: the founders discuss organizational questions that are mostly focused on keeping the P2PU machine running so that the community can do what they would like to do. This includes things like organizing the next workshop, the need for a non-profit organization (or not), etc.. Increasingly the main conversations are migrating from that small group to what we call the P2PU gang mailing list, which brings together people who have made a significant contribution (organized a course, helped us with licensing issues, advised on technology, etc.). We currently rely on recommendations from this core group to add new people to the list. And finally there is the broader P2PU community that would include all of the above, but also participants in courses, and potentially outsiders. We don’t currently have a space for this wide open conversation, but it is something we are building into our new web-site.

General rough consensus works

Another misconception about decision-making in open source is that all decisions happen by voting. In fact, one quote from the video that really stood out, was “If you see a community that is voting all the time, something is very wrong”. During our Berlin workshop we adopted something called the “(emerging) general rough consensus”. In all group discussion we had one note keeper, who would at the end of the discussion, list all the points that the group seemed to have consensus on. Disagreement was encouraged and if one person flagged an issue as needing further discussion then we either discussed it more or noted that no general rough consensus could be found. It sounds complicated, but worked like a charm.

Unfortunately we weren’t the first ones who came up with it. The Internet Engineering Task Force (IETF) has been using a process that is sometimes referred to as rough consensus and running code to guide its deliberations on the technical foundations that keep the Internet running. If it’s good enough for the Internet, it’s good enough for us.

Culture counts

Culture is another important aspect in open source communities, and I took away two key lessons on culture form the video: One, the founders of a project create the initial culture, which ideally becomes self-selecting in the sense that people who share this culture will be attracted and feel welcome in the community, whereas people with different values and ideas will not. And second, it is important to articulate both a clearly defined (and narrow) focus and a few core values as boundaries around your culture, so that you can refer to them when needed.

At P2PU, I think we have been quite successful with the first one. It certainly felt that the community that worked together in Berlin shared a substantive common set of values and culture and was excited by similar ideas for the future of P2PU. There are always individual differences, and that is a good thing, as long as there is enough overall coherence on what we are trying to do.

With respect to the second point of articulating culture and values, I think there are some potential downsides, or rather pitfalls if it is not done carefully. I have experience discussions in the free culture movement, where attempts to define the “movement” led to fragmentation – as people tended to focus on differences, rather than commonalities. Once the conversation is framed in the context of differences, it becomes very difficult to remember that after all, we share most of the important ideas and values. Sometimes it is easier to manifest culture in action and implementation than it is to define it through a discussion. Given those reservations, I think we do need a set of shared values – broad values – that we articulate on our web-site, and Alison has started compiling a draft version of what that could look like.

The video also speak about paying attention to newcomers and that is something we decided to start doing more seriously, both in the form of someone from the community welcoming new members when they create an account. For people interested in organizing a new course, we will offer an orientation — a set of pointers on how to best structure a course for P2PU, and the possibility to speak to someone who has organized a course in the past and is available to answer any questions that might come up.

The last aspect about culture that I want to mention here is the friction between growing very fast and retaining a shared culture. Nadeem who is head of development at Talis explains that take a lot of time to get to know job applicants in order to understand if they fit in with the organizational culture. He argues that it is easier to help developers become more productive, than it is to integrate them into a culture they don’t click with. Which makes me wonder how Google does this. They seem be very good at establishing and retaining a strong corporate culture even during a period of rapid growth of their community.

What started out as a few ideas around governance, mushroomed into a monster blog post. If you read all the way down to here you deserve a special treat. Here is a video about culture that highlights two important lessons: one person is enough to make a difference, and people like to do stuff together.