I have a tiny little skull, and I am currently bored out of it. I am sat in Orlando International Airport with Sooz, indulged in the most tepid of pastimes – the flight delay. My plight has been bettered by a comfy chair, an Internet connection and a laptop running Ubuntu. Life is far better than it could have been…

With said Internet connection and Ubuntu laptop I started reading my backlog of blog feeds and news. Lots is going as usual, but I am particularly enamoured to see that Melissa’s work with Ubuntu mentoring is going well. I have always been a firm believer that community is like a randomised pattern of dots, and part of the work is in drawing connections between those dots and making sense out of the chaos. From the outset I always wanted to improve the communication between different teams, and part of this process was to involve mentoring, peer inspiration and the development of best practise. The Ubuntu community already has some solid practise and governance in place, but there is still so much scope. Part of the issue has been that in many ways Ubuntu has been a victim of its own success, and I want to better scale some of these areas.

One thing the Ubuntu community doesn’t lack is enthusiasm, and enthusiasm is key to making free software that changes peoples lives. People get their tickers ticking by vastly different things, and while a Python backtrace will get some people in the mood for lovin’, community practise and methods gets other people equally fired up. We need all these different disciplines, but we also need the connections between those randomised dots to make sense. We need people to be able to communicate well together easily.

Unfortunately, governance is not something the Open Source community has been particularly good at. Sure, there are indeed some good examples, but in many cases governance falls into the following two scenarios:

  • No governance – hey, we are free software dudes, and we will not be ruled by rules. Fight the power…fight the power…
  • Rule-tastic – we need rules, legislation, processes, boards, voting, forms, background checking, more forms, and a variety of other bureaucratic diversions.

Typically, advocates of either scenario will be snobbish at the other side, and in reality both are not ideal solutions to the problem. Each of these methods takes an extreme perspective on the problem of organising, enthusing and empowering volunteer communities – they are as diverse as the extreme liberal and conservative political camps, and in most situations, neither is admirable.

I am an advocate of sensible procedures that are well thought out. All communities need some form of culture and organisation, but I believe that like the US constitution, every amendment and every rule needs to be as rigorously thought out and rationalised as possible. The dissection of community structure is often psychologically similar to perspectives on interaction and software design. Many software developers will want to do certain things because it makes them more professional or impressive in the eyes of their peers. This often results in more time tinkering with these things than writing code. Likewise, when it comes to community structure, many communities believe they need boards of members, constitutions, councils and other such structure because it makes them a real community. When quizzed on the purpose of these structures, the respondents often cite rare edge case issues that could be solved diplomatically. Structure and rules will not solve all issues, diplomacy and discussion does.

My point here is that community is organic, and efforts to develop these community structures can often be harmful to the community. Here I am mainly referring to new, fresh communities that are crying out for new contributors. In many scenarios these small seedlings are driven by motivated people with big ideas, and part of these ideas is having a a big and professional community structure that is similar to bigger projects. In almost all situations I recommend that you leave this community structure for a while and just do something first. This is eerily reminiscent to resource setup. Many people who start new projects spend most of their time getting SVN, mailing lists, IRC channels, bots, IDEs, logging facilities and other such things in place before they have written a single line of code. I believe this is counter-productive. Write some code, do something cool, and then get all of this mediocrity in place – instead of concentrating on these issues, concentrate on making cool software. If you build it, they will come – even if you don’t have a complete development platform and culture in place.

Once again, this is about balance. It is about getting the line drawn correctly between overkill and underkill (yes, I know its probably not a word 😛 ). My aim in life is to get this balance right and to help other people strike the right balance too.

Share This
%d bloggers like this: