We'll see | Matt Zimmerman

Introduction

In the course of my work in Canonical and Ubuntu, I hear from a lot of folks who want to start an open software project, or have started one and want to make it work better. Some of them represent companies, while others are working on a volunteer basis. It’s great to see so much interest in this area, and I’m excited to see so many projects wanting to become more open.

The trouble is, people don’t always mean the same thing when they talk about “opening” their project. The focus of this article is to establish a basic model for open collaboration which I hope will be useful in future discussions of this type. In the spirit of openness, rather than creating a document for my own use, I’ve opted to develop this on my blog instead. This is not a how-to document, just a map of the problem space.

I’ll use examples from software projects, because I’m most familiar with that field, but I believe these principles are more broadly applicable.

Open (available)

In order for your project to be open to anyone, they need to be able to find out about it and experience it for themselves.

Being open, in the sense of availability, is about ensuring that the people you want to reach have access to your content. The types of access that people need will vary depending on the content, but the basic principle is enabling people to obtain and use the content in an appropriate way.

For software projects, this means that the code is released under a free software license. This allows all the various denizens of the free software ecosystem to make use of your software as appropriate for their role: developers can inspect and improve it for themselves, packagers can standardize and distribute it, and users can download and run it.

Availability seems to be the most well understood type of openness. Even so, many project leaders still hesitate, and delay availability as long as possible (“until it’s ready”). What’s more, many projects simply stop there, and never explore the other dimensions of openness.

Open (transparent)

The next flavor of openness is about transparency. This means enabling people to find out about what is happening in your project. This means moving beyond the end result (e.g. software), and starting to involve people in the creative process behind it.

In an open software project, this means allowing read access to discussion forums, source code history, bug reports, and so on. It means letting people see into the “sausage factory” where the software is made.

This is much harder than slapping a license on your source code. Not only does it require the infrastructure to store, process and present this information, it also means revealing yourself. Creating products is about simplifying things for its consumers, letting them get on with their work without worrying about how or why the product exists. Successfully opening a project means going beyond this producer/consumer relationship and letting them see inside. This gives people the opportunity to get excited about what’s coming next, and to build on it.

This can be a very difficult adjustment to make. Becoming transparent means letting people see the problems with the project as well as the solutions. This opens up the project and its members to criticism, which they will need to process and even respond to publicly. This is a whole new level of accountability which may be unfamiliar to people working in private industry.

Another challenge of transparency, at least in a corporate scenario, is maintaining confidentiality where necessary. While most discussions and activity should be transparent, customers, partners and management will require that some information remain confidential. Care needs to be taken to ensure that neither transparency nor confidentiality is compromised.

Transparency enables the formation of a true community, made up of more than just consumers. Community members can begin to feel involved in the project, and build relationships with project participants.

Open (for participation)

The third type of openness is open participation. This builds on transparency by creating a feedback loop: people observe activity in your project, react to it, and then actually change its course. The change might be a small one, like helping to improve your work in progress, or a large one, like helping to redefine project goals.

In a software project, this means things like opening up read/write access to the source control repository, design documents, and bug reports.

This type of involvement promotes a sense of shared ownership for everyone involved in the project, not just its founders. It becomes “ours” rather than “yours”. This can be psychologically challenging, as it means giving up full control, and being subject to checks and balances of power. Corporate projects seem to have the most difficulty with this.

A fully participatory project will support open participation in even the highest levels of decision-making, for example through leadership elections which are open to anyone. The community becomes central, rather than auxiliary, and the success of the project will depend on it.

Conclusions

People and organizations who want to truly “go open” need to see this as a journey, one which will require that they change their methods of communication and decision-making, not just how their content is published. The extent to which they are able to fully embrace the open paradigm will determine the potential benefits to the project.