The life and times of open source communities

Content

• The roots of the open source community
• The cathedral and the bazaar
• The tragedy of the commons
• Open source governance and decision making
• Commercial enterprises and open source communities
• The importance of open source to the IT industry

The roots of the open source community

Let’s start with a formal definition of open-source communities. According to Brian Proffitt writing for TechRadar:

Open source communities are semi-organized collections of contributors to a project, typically software. These communities bring people with shared interests together to collaboratively build something, which can be shared with anyone inside or outside of the community. And, almost always, open source projects are the results of distributed communities.

It’s hard to pin down where the first open source community originated. While voluntary work to contribute to software has probably been around since computer research first started, we can point to a couple of threads in the history of open-source development.

Take Richard M. Stallman, for example. The story goes that one of the first instances of open source collaboration came out of the need to find a way for researchers to be alerted when a printer jam is causing their printing to queue up.

The researchers wrote the necessary code and it worked, but the researchers were sent back to square one with printer jams when a new printer was shipped with proprietary, closed-source code which they couldn’t get access to.

This planted a seed, and over time Stallman noticed more instances of how proprietary software with closed licenses prevented progress. He decided to launch the GNU Project in response, which is still a critical cornerstone of open source software thanks in part to the GNU General Public License (GPL).

Stallman’s story is one of the first steps into the development of open source as a community movement. It illustrates how the need for insight, control, and democracy around source code inspired the formation of a community. Stallman’s goal was to create a full operating system, but it was up to another member of a growing open source community to make that a reality.

Another pivotal moment is the rise of Linux which was started by Linus Torvalds in 1991 as a personal project. Wikipedia has a great article on the history of Linux, but suffice to say that Linus built on the efforts of other community members – including using the GNU C Compiler – to develop the Linux kernel.

We all know how successful the Linux project has become as Linux-based operating systems now drive critical workloads around the world. Linux is still free and still supported by an open-source community of volunteers – with releases containing millions of lines of code.

Our two examples point to two of the cornerstones of the open source community. First, software should be free and open to empower anyone to contribute and build towards something bigger.

It also points to the power of a community to achieve something greater than would be the case if individuals were to attempt it – or if it was attempted within the more limiting confines of commercial software development.

The cathedral and the bazaar

Communities coming together for a common purpose have a long history. One way of looking at this type of arrangement is via a concept called communities of practice (CoPs), which is essentially what many open source communities are.

CoPs are organized groups where people come together to work towards a similar goal. A CoP can form deliberately as a planned action – or evolve naturally, as people realize that they have common goals and decide to cooperate. These groups involve the sharing of information and skills, as well as sharing the workload – ensuring that efforts are not duplicated.

It’s all voluntary – but it can all be a tad chaotic. Intuitively, one would think that a more carefully planned approach to software development would be more successful, but instead, there are strong indications that the open, less disorganized approach of open source is delivering incredible results.

That’s what Eric Steven Raymond hinted at in his book, The Cathedral and the Bazaar. The writer pointed to two models of writing software. First, the cathedral model where during development it’s only a restricted group of people who have access to the source code and who contribute to the development process – even if the source code is available after release. The cathedral model is planned and controlled – akin to building software in a commercial setting.

But there’s a second model, the bazaar. The bazaar is a much more chaotic model where releases are issued often, where the development process is open to contributions from anyone. Essentially, development happens on the internet in full view of everyone. The argument is that, despite this chaotic method, its openness can mean that the bazaar model can produce results faster – as long as controls are in place.

For example, Raymond noted that bug review is much easier when a lot of eyeballs are looking at code – whereas in the cathedral model, the process of finding bugs is significantly more difficult.

The tragedy of the commons

In many ways, open-source software development via community efforts is an excellent way to produce capable, quality code even across very large projects. But as always in life there are pros and cons to the approach.

As we pointed out in the last section, the bazaar method of producing code only works in the place of the right controls. Why do we need these controls? Well, it brings us to our second metaphor: the tragedy of the commons.

A known concept in economics, the tragedy of the commons points to the fact that people will not always act in the collective good – instead, by acting in self-interest they often end up acting contrary to the common good of the community. That can happen in the open source community too.

On the one hand, one of the biggest benefits of open-source software is that any single individual can contribute to open-source code – adding, customizing, or changing the code. But that can lead to problems with open-source projects as individuals push their individual agendas – without taking into account the common good of the open-source project.

This self-interest includes financial gain, but it can also mean that projects are simply pulled in directions that don’t benefit the wider open source community. Or, the project simply dies off because at an individual level there is little interest – even if there is value at the community level.

So, while the “wisdom of the crowd” can bring enormous benefits, the individual members of the open source community can sometimes act as stumbling blocks.

Open source governance and decision making

Clearly, to get the best out of the good goodwill behind open-source software projects, a solid governance and decision-making regime need to be in place to manage individual behavior for the greater good.

There are different strategies for leadership in the open source community. Some could be entirely democratic, but on the other hand, Linus Torvalds has acted very successfully as the “benevolent dictator” behind Linux.

Every open source project is different and the governance structure adopted will be determined by both the nature of the project, the shape and size of the group that contributes, and of course the overall goals of the project.

In broad, points that the leaders of an open source community should consider include a decision-making structure, a fixed process around how new maintainers are added, and deciding on a build system that is fit for the goals of the project.

Intellectual property matters too – including the open source license, whether it’s GNU GPL or the MIT License for example. The ownership of the internet domain should be decided too, while any trademarks also need to be accounted for in a fair manner.

One important aspect to consider is the tightness of control over a project. As Eric Raymond suggests with his bazaar analogy, the relative lack of control is what makes the open source model so successful. Yet, with no control whatsoever, open-source development is at risk of succumbing to the tragedy of the commons.

Commercial enterprises and open source communities

Open source initiatives can accomplish incredible things – which can quickly invite attention from commercial vendors. The sums involved can be huge – consider IBM’s $34bn purchase of Red Hat, and Microsoft’s $7.5bn investment in GitHub, for example.

An argument can also be made that open source projects will only truly achieve critical mass and enterprise penetration once a commercial software company steps in to provide enterprise-grade levels of support. After all, professional developers working in the enterprise environment will require the presence of enterprise-grade support before they’re able to integrate an open-source solution into their workload.

Either way, open source communities have complex and sometimes testing relationships with commercial vendors which is understandable, given the obvious contrast of contributions made free of charge thanks to community members against the for-profit motive of commercially driven organizations.

Nonetheless there are several models that successfully blend open source prerogatives with commercial requirements. It could entail outright sponsorship of projects – but commercial enterprises can also support open source initiatives through funding, by donating equipment, or by donating the time of their employees – allowing staff members time to work on open source code, for example.

A modest commercial investment can significantly boost the efforts of the open source community. In turn, organizations get to deploy highly capable open-source code that match their requirements. Of course, open source governance matters here: without strong independent direction, commercial goals can easily override the goals of the open source project.

The importance of open source to the IT industry

Information technology is a science, and sciences consistently benefit from openness, experimentation, and collaboration because these three qualities foster innovation. By consequence, it is easy to see why open source communities benefit the information technology industry.

The innovations are driven by open-source development and commonly find their way into enterprise software solutions. For example, the Linux kernel powers a major proportion of applications servers, while OpenSSL supports secure communications for the majority of HTTPS-enabled web servers.

With the right governance, open source projects have an incredible ability to drive innovation by harnessing the collective brainpower of expert developers located across the world in a reasonably co-ordinate manner. Commercial support can lubricate the process by bridging the motivational gap.

Open-source software often acts as better alternatives to commercial solutions, and in some cases, open-source code is so good that it becomes essentially the only sensible solution.

It’s hard to predict exactly what would have happened to the pace of technological development had open source communities not grown to the size that they are now, but it wouldn’t be unfair to suggest that the open source model accelerated the pace of technological development – and will continue to do so in the future.