Recently, I have been reflecting on, discussing and writing about open source. After the publication of an article on the Wired web site, one of my colleagues, Kristofer Joseph, came to me and essentially said: “I think there is something about open source that your article does not cover, that is important and that people often miss”. Of course, Kristofer had my full attention with that introduction. So we talked more and Kristofer went on to explain that he felt that the ‘working in the open’ part of the open source culture was either overlooked or not understood. I think he is right so, let’s talk about that. Why open source often means working in the open (it should)? Why is it important?
When you work in an open source project, your code is visible by anyone. Not only your source code, but every single code commits you make and every interaction (comments, issue tracker, mailing list) you have with the community. There is no hiding in open source. Your contributions and interactions paint a living memory of your persona.
You have to show your true color and that is why open source is a meritocracy and not a status based culture. Your work speaks for yourself. That typically makes people raise their standards, strive for excellence and I am convinced that the open collaboration explains a large part of the open source software’s success.
Get early and constant feedback
If you work in the open, you can interact with people as you develop your code. In a way, it is related to the lean start-up model that is geared towards early customer feedback that allows quick iteration and course correction. Transposed to an open source project, working in the open is letting you be lean: your customers, people who might use your project, can see an on-going project, try early versions of the software and comment. You can also reach out to them to ask for opinions, preferences or guidance. You can experiment fairly quickly and validate or invalidate hypothesis you have.
A great example of early and constant feedback is the work that Kristofer and his team do on the Topcoat project. By working in the open, we have made a lot of design choices and course correction, thanks to the feedback we got from our bleeding edge users.
But working in the open has its traps. As Kristofer mentioned, it is not always understood.
Working in the open means good and bad work in progress is shared
People not familiar with open source sometimes have the expectation that it should be like a product from a commercial company. So if I get code from the project, and if it is not perfect, then there is disappointment.
This is where open source projects are usually careful at setting expectations and try to guide their users, making it clear where to get a stable build, versus a development version or a beta build. For example, you can get nightly builds of WebKit and by the design of that version of the project, it is clear it is work in progress.
The best open source projects use continuous integration to get natural quality assurance on their code for building, testing, coverage and performance regressions, which helps maintain high standards even for in-progress work.
Working in the open means that you can implement your own wishes!
Another thing which sometimes happens is that people would expect that they can interact with an open source project like they do with a vendor. If there is a feature that I want, then I should demand that it be added. It works a bit differently in open source.
Of course, projects typically welcome suggestions or requests for features. That is part of getting feedback and guidance from the users. But if you really want something to happen on your schedule, the best approach is to actually contribute to the project and start engaging and contributing to the effort. A lot of individuals and companies do that routinely with a lot of success, for example around the Eclipse open source project.
So, why work in the open? Not just for open source!
Working in the open makes your project run like a start-up trying to get constant feedback, reacting to demand quickly and adjusting course as needed. It makes you and your team raise your standards. It means that you have to set expectations properly too, but that is ok. And it also allows you to welcome contributions to your project, making it more valuable than you could on your own. So Kristofer is right, this is all important!
A final, important point: working in the open can also be done for non ‘open-source’ projects. It is an approach you can take for internal project and even very large companies such as SAP have been able to implement that successfully, as Dirk Riehle described in his research.