I have become slightly besotted with everything to do with Thomas Freidman since watching a video of him talking at MIT about his then recently launched book “The World is Flat“. The video is made available as a part of MIT’s OpenCourseWare program and is embedded here for your viewing pleasure.
It’s an hour and a bit long, and a very enjoyable hour and a bit it is. Freidman is funny, smart and insightful.
In the process of explaining some of the ‘flattening’ influences on the world, Freidman interviews Brian Behlendorf, the father of Apache, the first and most successful Open Source software package; the one IBM adopted instead of developing their own. I was particularly taken by it as I had recently been talking to a senior marketing guy at one of the big FMCGs about the issues of embracing an ‘open source’ approach to working with his marketing team. While he could see all of the benefits of collaboration, innovation, free thought and so on, he still had concerns. This is one of the largest companies in the world; they need consistency and discipline dammnit. Oh, and collaboration, innovation etc.
What Behlendorf says about the way the original Open Source community organsies itself is very telling; that the tension between Open Source and organisational coherence is one of our own construction. Reading the Behlendorf interview it is clear that these guys aren’t anarchists; they’re scientists. So they’re just looking for the most efficient way of using collective skills to produce software (for which we could substitute any collaborative corwdsourced product such as the FMCGs marketing program). And I think its something that is frequently misunderstood; Open Source is not a social experiment; its a science experiment. As such there are all kinds of controls and checks and balances on place to ensure its efficent operation.
I think its important to remind ourselves of this because there is a tendecy amongst social media / technology fan boys to describe Open Source as a kind of magical socialogical phenomena. And as a result, organisations are (rightly) scared off from exploring it. But I believe that’s because they’re being sold something that’s not true to or as elegant as the orgaisational structure of the original Open Source community that coalesced around the Apache server.
“Most software development involves a source code repository and is managed by tools such as the Concurrent Versions System,” he (Behlendorf) explained. “So there is a CVS server out there, and I have a CVS program on my computer. It allows me to connect to the server and pull down a copy of the code, so I can start working with it and making modifications. If I think my patch is something I want to share with others, I run a program called Patch, which allows me to create a new file, a compact collection of all the changes. That is called a patch file, and I can give that file to someone else, and they can apply it to their copy of the code to see what impact that patch has. If I have the right privileges to the server [which is restricted to a tightly controlled oversight board], I can then take my patch and commit it to the repository and it will become part of the source code. The CVS server keeps track of everything and who sent in what… So you might have ‘read access’ to the repository but not ‘commit access’ to change things. When someone makes a commit to the repository, that patch file gets e-mailed out to all the other developers, and so you get this peer review system after the fact, and if there is something wrong, you fix the bug.” (Friedman, The World is Flat“, Penguin: 2006, P102).
Ther are three important parts to this model with I think we can apply more broadly;
i) Hierarchy. While all of the participants in the program are free to create and contribute as they please, there are very specific protocols in place that control the addition of their contributions to the final repository. In other words there is an organisational hierarchy (albeit a pretty flat one) that makes final decisions.
ii) An established base line and process. Open Source starts with a source code repository, which serves much the same purpose as brand guidelines, or other internal strictures. Further even than that Behlendorf’s example includes accessing the code with specific tools and in a particular way.
iii) Responsibilities: Being a part of the community comes with a responsibility beyond just ‘making shit up’. Every piece of code is peer reviewed (so there’s that responsibility) and when a bug is identified, the original creator is required to fix the bug. Surely both disincentives to submit buggy code.
What I took from Behlendorf’s description of how the Apache Open Source community works is that we’d be better served starting with the principles of what makes a community work and then within that what makes an Open Source community successful. But with these in place, organisations can then afford to trust their members and set them free to ‘make shit up’ knowing that it will be done responsibly and that it will adhere to the necessary guidelines and processes that enable it to be effectively absorbed.