As a not-too-technical person, my experience with the Ubuntu community has been somewhat rocky. The few non-technical projects – Documentation, Marketing, Translation – do not get very much attention compared to the technical tasks, and those involved are nowhere as well organized as the technical teams. As fellow non-technical Ubuntu contributor Matthew Revell noted:
When trying to find a project to which I could contribute documentation, I found that I was welcome but:
a. no one really knew how to use my skills
b. the onus was on me to navigate my way round the project to find where I’d fit in
c. I was thrown in at the deep end.
Mitchell Baker, “Chief Lizard Wrangler” of the Mozilla project, has had to deal with this as well, coming to Open Source with a lawyer background. And as more non-technical people join the Mozilla Foundation, she has had to consider how these people can get to work well with the development community. The main issue is that there is no established path to meritocracy for non-technical roles:
Open source has been around for decades, and there is a significant group of engineers who participate as volunteers, and a significant group whose work involves open source projects. We know what the set of activities are that lead to acceptance and leadership. That’s no so clearly the case for the set of other activities.
She argues that the crux of the matter is trust:
Integrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.
people are effective when they are known and respected. This is the basis of shared values, community cohesiveness and continuity. It’s one of the tenets of open source software development that I believe must permeate everything we do. Our challenge is to use this approach in places where engineering “chops” aren’t a sufficient and may not be a particularly necessary criteria.
GNOME Board member Dave Neary has raised this issue in the GNOME community, and reaches much the same conclusion:
When Mitchell says that we need trust on both sides, it’s because when someone who isn’t technical asks a techie to do something for them, often the reaction is either “who do they think they are?” or “I know better”, or “show me the code”.
We need to have some way to get the first non-technical contributors heavily involved in things like release co-ordination and marketing to get that meritocracy bootstrapped. We need to trust that new people coming into those roles are capable, and trust them, until they prove otherwise 😉
He also points to the proposed Code of Conduct, inspired by Ubuntu, as a way to ensure an friendly environment that will encourage new contributors to join the community. But another challenge is to simply make non-technical people aware that they can contribute
In Ubuntu, Ubuntu Membership Process does not require technical contributions, thus stating that any contribution to Ubuntu will be valued equally. And hopefully extending the necessary trust to help developers and non-developers to work together.
But once that membership is granted, it becomes difficult to further meritocratize within non-technical contributors, whereas technical contributors can go on to apply to become an Ubuntu developer with appropriate upload rights as well as the somewhat arbitrarily administered Karma points.
As it is, upload rights and karma points are no way to distinguish between good and bad marketing or community support contributors, and it is debatable when it comes to translation and documentation contributors. And as more non-technical roles within the community appear, the situation will not improve.
The fact is that social trust in Open Source communities is earned through merit and participation, and as Ubuntu grows, this trust may be strained. I think Dave Neary’s suggestion of further integrating the non-technical contributors in the main technical processes such as specification and release planning will be essential to this. And that will require these processes to be both transparent and open, as well as considering the various non-technical teams’ relation to these main processes.
At the moment I’m drafting a document that is to be shipped with the system documentation as part of the next Ubuntu release. The goal is to make a reference guide for new or would-be community members on how to get involved in the Ubuntu community. But it is also meant to be an introduction to the tools and communication channels within the community, I hope that it will help new contributors to get an easy overview of the community structure and of how the various teams – technical and non-technical both – interact.
At the same time, I’m learning loads of stuff on community procedures, which is great for my fieldwork as well!