From its early days, the availability of source code was one of the defining characteristics of open source software. Indeed, Brian Behlendorf of the Apache web server project, an early open source software success, favored "source code available software."
Another important aspect related to user rights. Hence, the "free software" terminology that came out of Richard Stallman’s GNU Manifesto and GNU Public License (GPL). As the shorthand went, free was about freedom, not price. Christine Peterson would later coin "open source" as an alternative that avoided the confusion that regularly arose between these two meanings of free. And that’s the term that’s most widely used today.
These and other historical contexts still flavor how many think about open source today. Where open source came from should still inform today’s thinking about open source. But it also shouldn’t overly constrain that thinking.
With that background, here are some things that open source is not, or at least that aren’t central to what open source is and where it’s going.
Open source is not licenses
Licenses as a legal concept remain an important part of open source software’s foundations. But, recent hullabaloo on the topic notwithstanding, licenses are mostly not the central topic that they once were. It’s generally understood that the gamut of licenses from copyleft ones like the GPL family to the various permissionless licenses like the Apache, BSD, and MIT licenses come with various strengths and tradeoffs.
Today’s projects tend to choose licenses based on practical concerns—with a general overall rise in using permissionless licenses for new projects. The proliferation of new open source licenses has also largely subsided given a broad recognition that the Open Source Definition (OSD) is well-covered by existing license options.
(The OSD and the set of approved licenses maintained by the Open Source Initiative (OSI) serve as a generally accepted standard for what constitutes an open source software license. Core principles include free redistribution, providing a means to obtain source code, allowing modifications, and a lack of prohibitions about who can use the software and for what purpose.)
Open source is not a buzzword
Open source software is popular with users for many reasons. They can acquire the software for free and modify it as needed. They can also purchase commercial products that package up open source projects and support them through a life cycle in ways that are needed for many enterprise production deployments.
Many users of open source software also view it as a great way to get access to all of the innovation happening in upstream community projects.
The term "open source" carries a generally positive vibe in other words.
But open source also has a specific definition, according to the aforementioned OSD. So you can’t just slap an open source label on your license and software and call it open source if it is not, in fact, open source. Well, no one can stop you, but they can call you out for it. Proprietary software with an open source label doesn’t confer any of the advantages of an open source approach for either you or your users.
Open source is not viewing code
The ability to obtain and view open source code is inherent to open source’s definition. But viewing isn’t the interesting part.
If I write something and put it up on a public repo under an open source license and call it a day, that’s not a very interesting act. It’s possible that there’s enough value in just the code that someone else will fork the software and do something useful with it.
However, for the most part, if I don’t invite contributions or otherwise make an effort to form a community around the project and codebase, it’s unlikely to gain traction. And, if no one is around to look at the code, does it really matter that it’s possible to do so?
Open source is not a business model
It’s common to hear people talk about "open source business models." I’m going to be just a bit pedantic and argue that there’s no such thing.
It’s not that open source doesn’t intersect with and influence business models. Of course, it does. Most obviously, open source tends to preclude business models that depend in whole—or in significant part—on restricting access to software that has not been purchased in some manner.
Conversely, participation in upstream open source communities can create opportunities that otherwise wouldn’t exist. For example, companies can share the effort of writing common infrastructure software with competitors while focusing on those areas of their business where they think they can add unique value—their secret sauce if you will.
However, thinking of open source itself as a business model is, I would argue, the wrong framing. It draws attention away from thinking about business models in terms of sustainable company objectives and differentiation.
Open source is…
Which brings us to a key aspect of open source, as it’s developed into such an important part of the software landscape.
Open source preserves user freedoms and provides users with the strategic flexibility to shift vendors and technologies to a degree that’s rarely possible with proprietary software. That’s a given.
Open source has also emerged as a great model for collaborative software development.
But taking full advantage of that model requires embracing it and not just adopting some superficial trappings.
Are there challenges associated with creating and executing business models that depend in large part on open source software today? Certainly. But those challenges have always existed even if large cloud providers have arguably dialed up the degree of difficulty. And, truly, building sustainable software businesses has never been easy.
Open source software is increasingly an integral part of most software businesses. That fact introduces some new challenges. But it also opens up new possibilities.
Watch: Gordon Haff and Spender Krum discuss this topic IBM Think 2019
About the author
Gordon Haff is Red Hat technology evangelist, is a frequent and highly acclaimed speaker at customer and industry events, and helps develop strategy across Red Hat’s full portfolio of cloud solutions. He is the co-author of Pots and Vats to Computers and Apps: How Software Learned to Package Itself in addition to numerous other publications. Prior to Red Hat, Gordon wrote hundreds of research notes, was frequently quoted in publications like The New York Times on a wide range of IT topics, and…