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.

At any given moment, I have a set of open problems in my life. On my good days, I’m working on the most important one, aiming to solve it as quickly as possible. Otherwise, my most important problem is that I’m not working on my most important problem!

From time to time, I manage to solve a problem, and can remove it from the list. As a side effect, my #2 problem “gets a promotion” and becomes #1 (thanks to Jerry Weinberg for this analogy).

The problem at the top of the list, by virtue of being a focal point, can easily seem bigger than it is. As humans, we normalize our point of view based on what is happening to us. If we apply conventional productivity wisdom and focus exclusively on our most important task, that task consumes all of our attention. Being constantly in this state can be very productive, but also create a problem orientation. I experience this as a feeling that I am constantly surrounded by problems and never “catch up”.

At times like this (if I’m aware and realize that it’s happening), these are some of the things that help me recenter myself:

• Devote some attention to reviewing what I’ve accomplished recently, to remind myself of progress
• Ask myself if my #1 problem is actually urgent, or if I’m just on a roll. If it’s not urgent, consider taking a break from problem-solving and work on something else important for a while
• Give away some problems that I’m holding onto but don’t need to own
• Remind myself that this feeling as a side effect of where I focus my attention, and I can therefore influence it
• Laugh

For some time now, I’ve been using a LinkSys NSLU2 as a file server for my home network. It’s very small, has no moving parts, and uses relatively little electricity. Combined with a large USB-attached hard disk, it has worked very nicely overall. My only issue has been that it is somewhat underpowered: with a 266MHz CPU and only 32M of RAM, it just wasn’t as responsive as I would like.

This weekend, I finally got around to replacing it with a newer unit based on the Babbage 2 design, with an 800MHz CPU and 512M of RAM. This should be much faster, and let me run more services than just Samba and rsync.

The only trouble was, the console interface on the new system is VGA and USB. I have a VGA monitor at home, but I don’t have a keyboard. I used to be the sort of person who had cabinets full of spare computer parts at home. Before my transatlantic relocation, I lightened my load substantially, and have only one small box now. This box did not contain a USB keyboard, and our only computers at home are laptops and netbooks.

Fortunately, the unit had a build of Ubuntu installed on its internal flash, configured to log in automatically to a graphical desktop. Using a dust-covered USB mouse I found in the bottom of the parts box, I copied and pasted letters from the gnome-terminal help files to install openssh-server, so that I could login over the network and finish setting it up.

It has now replaced the NSLU2 and is much snappier.