Open Source Myths and Half-Truths: Part 2

Let's continue our analysis of the top myths and half-truths about open source. Part 1 is available at https://hackernoon.com/open-source-myths-and-half-truths-part-1-rur3e9x

Open source can be a space for experimentation. Part of the magic of open source is lowering the barrier to entry. Anyone can start a new project and list it online and it can have a real chance of success without any marketing campaigns or distribution costs. If it’s listed in the right place then developers can find it and if it addresses a real need then it can be adopted and improved even if it’s rough around the edges.

This lowering of the barriers to entry is easy to see on Github. It’s easy to search for projects and most have a top-level README that tells you how to install it. When the installation method is standardised too then the end user can very quickly find and experiment with projects. This is great for encouraging new projects to get started. But it can lead to lots of half-baked or half-finished projects.

This phenomenon is so common in the JavaScript world that there’s a joke about it, from kavan at devRant:

So open source really can be chaotic. But it can also be a space where standards are forged.

Standards can emerge in different ways. A common way is that a technology becomes so widely adopted that its approach and interface becomes the expected way to address the need. One of the clearest examples of this is Docker. There are other technologies for containerisation but Docker is so popular that it sets our expectations about what containers should do and how we should interact with them.

This means any container technology either needs to provide similar interfaces to Docker or overcome the barrier of user expectations. Other examples of this standardisation by popularity are Git, WordPress and the Kubernetes project.

Standardisation by popularity is not exclusive to open source. You could point to standardisation through popularity with paid products like the Microsoft Office Suite, GitHub or Salesforce. What is key for this to happen is that the product must become very widespread and must fit its need with minimum friction.

Open source projects are particularly well placed to achieve this as their use is not limited to the subsection of the market that can afford to pay for them and they can respond well to user feedback. Open source can gain traction with big companies too as it can reduce fears of being held over a barrel by a single vendor who may push prices up (vendor lock-in).

The grand Bazaar of open source projects includes many that are an early and experimental stage of development, others that fill a particular niche within their sector and others that have become dominant. This is how standards can co-exist with chaos.

Standardisaiton can also come about by collaborations. We can find competing tools coming together to form a common approach. The Apache Hadoop project has seen collaboration from many big companies - among them Cloudera and Hortonworks who were competing to sell Hadoop offerings and have now merged. This merger was in part possible because even as Cloudera and Hortonworks were competing, both were building on a common foundation of Apache Hadoop.

As we’ve touched on already, the Kubernetes project saw collaboration early on from Google and Red Hat and has since seen very widespread adoption and contribution. Another example is Microsoft’s decision to work on top of Google’s open source Chromium browser base code. We can also find more conscious efforts to create standards fostered by non-partisan foundations, such as the IEEE’s Standards Association or the Cloud Native Computing Foundation’s role in OpenTelemetry and CloudEvents.

For software products there can often be very strong network effects - cases where the more adopters there are, the move value that can be derived from the product (e.g. more people you can share the file format with). Open source can promote interoperability by making interfaces clear and making it easier for tools to work together. So there are strong forces pulling open source towards standardisation as well as chaos.

Big foundations, standards committees and collaborations between big players are highly influential. But it would also be misleading to underplay the messiness of the Bazaar. It is not true that standards will always organically form around the best ways to do things. The JavaScript community has a running joke around this, thanks to Francois-Xavier Darveau and iamdeveloper:

Sometimes you get competing products because different tools fill different niches. Consider the wide array of databases available for different purposes. The range of use cases for databases is so different that it is hard to imagine a single database satisfying the range of use cases without trade-offs. This has has enabled a range open source databases to thrive.

Another case of a range of niches is programming languages. There are many niche languages with specific use cases. However, there are also competing general purpose programming languages and here we see the phenomenon of standards proliferation:

(Comic from xkcd.)

Sometimes this happens for commercial reasons. For example, Java and C# are both general purpose programming languages with many similarities. But they have their own ecosystems and integrations with commercial offerings. It matters that C# is backed by Microsoft and Java by Oracle (formerly Sun).

Tool proliferation can become a self-perpetuating process. When there’s a zoo of tools in a market without a clear winner then it can be tempting for new players to enter. Especially if the barriers to entry are low, as we’ve seen they can be with open source.

To an extent this kind of proliferation probably needs to happen in a new field. There needs to be experimentation to see what will work best and that means putting products out there and gauging market response. This can be messy and if the range of use cases is itself complex or not well understood by users then the messiness may not get resolved.

Open source can deliver a valuable recruitment advantage. But it offers a limited advantage if not exercised effectively. There’s definitely a benefit to being a major contributor to an open source project with a big reputation. There’s definitely a benefit to embracing, using and contributing to open source projects in your company projects. But there’s a detectable difference between participating in the wider open source ecosystem and making a show of doing some open source for recruitment reasons.

Something I’ve personally noticed is some companies open sourcing projects that are too tied up with their company’s internal architecture for a community to really gather around them. To me open source projects are more powerful when the first page can communicate who the intended users are and how the project aims to help them.

It is great that companies are celebrating open source and there are some very positive examples. Trivago chose to sponsor the open source project webpack and it’s nice how they phrased their post about this. They explained why they use webpack, why they like it and why they chose to support the project through sponsorship. Then they say:

In my view it would be fine to support an open source project with the intention of getting some reputation and recruitment benefit. My point here is just that the message behind sponsorship is more powerful if the sponsor can explain why the project is important to them and what their relationship is to the project. (I should say I’ve no association with trivago or webpack.)

Developers should also be aware that open source contributions alone are unlikely to make a big difference to a CV. In my experience you only really make an impact with interviewers when you’ve got a story to tell and that story resonates with the interviewer. Open source contributions can be useful if they’re part of a story but if it’s just line items on a CV then interviewers can just pass over these things.

I also think it’s ok to say you’re a big fan of open source even if you don’t have a lot of contributions. Being an informed user of open source is also something to be celebrated as informed users are a big part of how companies get value from open source and also a big part of how open source communities thrive.   

The world of open source is now a complex one. Open source changed the world and it’s now the default way of driving innovation. But along the way open source changed too. The early misconceptions about it still sometimes lead late organizations to miss out on diving into the open source ecosystem. 

Open source forms the backbone of the software industry today and as long as you see how open source is now interwoven with commerce then you can benefit from it greatly. The ecosystem continues to get stronger, benefiting both the industry and society as a whole.

Many thanks to Dan Jeffries for his valuable contributions to this article.

For more on the business strategies behind open source see

and