Nearly 15 years since the term "open source" was first applied, the trends driving the open source movement are not the same. Back then, price advantage, direct differentiation on licensing versus proprietary software, adoption-led marketing by innovative entrepreneurs, and market reaction against an ever more abusive monopolist were key factors shaping the direction of open source.
Today's open source movement is more mature, and the trends underlining it are more nuanced and widely engaged. The revolution has had a meaningful impact, and to treat open source as if it is still about saving a few bucks on a software license or socking it to Microsoft is to misunderstand how far the open source movement has come.
The following five trends are key drivers of today's open source communities and projects. From governance to emerging revenue models, they paint a picture of an industry evolving to see the value of the freedoms at the heart of the open source movement.
Fifteen years into the movement, it's clear that no single form of open source governance is ideal. While many successful open source projects share characteristics in the abstract, every approach has its pitfalls and every community faces governance challenges. That stated, two themes summarize the recurring strengths of today's most successful open source projects.
First, while they may appear to be democracies, almost all are not. In nearly every case, the right to have a binding voice in determining outcomes - by voting or as part of a formal consensus - is granted to a limited number of community participants on the basis of merit associated with contribution of some kind. This results in a strong, relatively stable core leadership comprising the most favored leaders.
If the project is truly open, anyone can become a recognized contributor if they demonstrate merit, but in the end, "open, meritocratic oligarchy" is more apt than "democracy" in describing the way many open source communities operate: led by a stable group of recognized leaders, whose actions have demonstrated fitness to lead, yet who remain replaceable at any time should others prove more suitable. This characteristic has been clear throughout the history of open source.
A second common theme has become a trend in the past few years. As corporate engagement in open source has become stronger, projects have realized their common ground needs a place of its own, resulting in the rise of independent legal entities that act as containers for open source communities.
Usually labeled "foundations" regardless of their actual legal form, these nonprofit legal entities offer multiple benefits, including:
- A host for managing fiscal and other shared resources such as trademarks and shared copyrights
- An employer for staff serving the community and project
- A guarantor and enabler for governance
- An infrastructure provider
- A liability firewall for community participants
These benefits individually reassure different parts of the community, but having them collected into an independent nonprofit frees participants from being unduly concerned about aspects that don't relate to them directly. Consequently, forming a foundation is usually noncontroversial because everyone can see a benefit.
Of course, starting a foundation does not resolve community relationship issues. If there's dysfunction, such as a crisis of trust between community members, merely incorporating won't likely solve it. Addressing community relationship and trust issues before incorporating is key, otherwise these issues are likely to be wired into the foundation's structure and bylaws, perpetuated indefinitely.
The steady growth of long-term entities such as the Apache Software Foundation and the Eclipse Foundation, the introduction of foundations for large projects such as OpenStack and LibreOffice, and the existence of general-purpose foundations such as OW2 and OuterCurve provide ample evidence of the increasing importance of foundations in driving open source forward.
All of these foundations cultivate trust in the stability of the activities they represent and encourage corporate participation. We will see more of them.
Another key driver of today's open source movement is the sheer volume of available licensing choices and how choice of open source license is changing, thanks to increased participation from corporate organisations that recognize the importance of community.
All software automatically benefits from copyright protection for its author, giving her control over who can make copies of the source code or derivatives, including extracts of source and compiled binaries. Since the executable version of software has to be copied onto a computer to be used and into memory to be executed, it's necessary to have a license from the copyright holder for any use of the software.
In the earliest days of open source, there were broadly two choices for licensing copyright. People sharing Bill Joy's pragmatic do-what-you-want outlook picked licenses like the one used on the Unix Berkeley System Distribution (BSD) he pioneered. Others sharing Richard Stallman's view that software freedom demands social engineering picked the General Public License he devised for his GNU Project - so called because it is a license benefiting the general public.
The adoption of these ideas by businesses was a key motivation for creating the Open Source Definition as a tool for categorizing licenses as open source. In 1998 it was clear that others wanted to replicate the experience of the Mozilla project and declare their work "free" while frequently disregarding the need to deliver software freedom, much as many businesses in today's food industry seek to use the term "organic" without delivering on the holism behind the term. To combat this, the Open Source Initative was formed to promote the term "open source" to signal truly "free" software. From that point, only licenses granting anyone freedom to use, study, modify, and distribute the software would be approved by OSI as representing.
Businesses wishing to avoid using the GPL tended to follow the example of the Mozilla project and created their own license. As a result, over 60 new licenses were approved by OSI in the first few years of the open source era. But this proliferation has come with a cost. Open source licenses often don't mix; when you make your own, you condemn your project to isolation. Creating a new license like this is a problem that arises from a fundamental misunderstanding of the role of the license in open source, treating it as a traditional bilateral legal agreement. Instead, an open source license is a multilateral agreement, "the constitution for the community," as Eben Moglen once put it.
In recent years, new projects have been much more aware of the role of the license in enabling community formation and function. The result has been a trend toward liberal licenses such as theApache License or the BSD/MIT licenses, thereby eliminating perceived barriers to participation for corporate contributors. OpenStack, for example, uses liberal licensing.
Yet even projects that use the liberal BSD Unix license have at times railed against corporations who use their work without contribution, suggesting there's a role for copyleft, too. Most communities are offended when a profitable consumer of their work is all take and no give. This sense of justice will likely push the needle that has swung full-scale from GPL to BSD back to the middle ground, best represented by the recently revised Mozilla Public License, MPLv2.
MPLv2 is explicitly compatible with the GPL, and it contains no clauses that prevent mingling with liberal licenses, aligning it with the sensibilities of most of today's open source communities. It does include a weak copyleft requirement that changes to files managed by the project must be published, but it allows developers complete freedom to use the compiled binaries any way they want, including mixing them with non-open-source code to create proprietary products.
The legal system is having an increasing effect on today's open source movement in the form of software patents, a stark contrast from 15 years ago.
A form of social contract between inventors and society, patents exchange a temporary monopoly of a practical invention for the publication of that invention so that the public at large - "the commons" - can benefit from it.
Patents protect implementations of ideas, not ideas themselves. But over time, clever drafting by legal experts has pushed the envelope for what can be patented, and in the software industry, a loophole that allows ideas to be associated with a physical object and thus rendered patentable has yet to be addressed by legislators. While software can only formally be protected by copyright, verbal constructs attaching software or algorithms to general-purpose computers have allowed patents on software to increasingly be granted.
Worse, software patents make no allowance for the reality that, unlike the creation of physical objects, two programmers in two unconnected places may in fact devise the same method to solve the same problem without copying one another. Thus, for proprietary and open source software alike, patents represent a threat. At any time, a well-resourced corporation wishing to chill competition can challenge another entity of any size. There's really nothing an individual developer can do to be protected from software patents, although Debian provides worthwhile advice.
Counterclaims can sometimes protect an organisation from a patent aggressor, but an increasing number of patent aggressors are entities that make patent threats to force licensing. Against such companies, there is no recourse for countersuits, as the aggressor has no products that might infringe patents in your own portfolio. Consequently, the best defenses for developers have become:
- Building patent pools to defend against corporate aggressors
- Buying portfolios to take patents out of circulation
- Building tools to establish prior art and engage in defensive publication
- Proactively litigating and securing cross-licensing from competitors
Much of the problem is one of threat, the vast majority of which never reach the press, let alone the courts. The most lucrative patent shakedowns are conducted secretly, starting with massive private threats accompanied by an offer to license in exchange for a share of revenue and a guarantee of secrecy. This is a significant revenue stream for big corporations such as IBM and Microsoft. Apparently, IBM makes close to half a billion dollars annually from this technique.
None of this was a serious problem 15 years ago. Today, open source is evolving in the context of such patent scenarios. Software patents are a major motivation for foundations and license evolution. Foundations offer a "liability firewall" that works both ways, protecting patent-holding corporations from community claims on their patents and providing a venue for sheltering from patent attacks. Modern open source licenses such as GPLv3 and MPLv2 offer a "patent peace," granting licenses to contributors' patents in exchange for an agreement not to litigate.
Dealing with software patents is probably easier in the context of open source because there are many eyes to look for prior art, there are many targets for attack so that aggressors are drawn into the open sooner, and there are more minds available to work around patent claims when they are detected. Software patents are thus likely to continue to be a key driver for the evolution of open source, both as communities deal with them and as corporations exploit the benefits of open source foundations and licenses.
Built predominantly on open source software, cloud computing has evolved to be a significant driving force in today's open source movement.
Cloud computing has many meanings. It can refer to shared storage accessible via a network, an API to a remote application, a remotely managed VM running a stack of server software, or an application reached via a Web or client app.
Whatever the form, cloud computing's varying instances have shared consequences. First, cloud solutions must be deployed flexibly, especially in load-balancing situations where multiple temporary instances may be required instantaneously. As a result, most proprietary packages, which use complex, metric-based pricing under the assumption that every installation means equal-value use, are unaffordable in cloud applications.
Open source software, on the other hand, is unshackled from the need to obtain or track licenses. It can also be modified to fit your needs. As a consequence, open source software is hugely preferred for delivering the cloud. Moreover, the low cost of getting started with open source software in the cloud means that startup companies overwhelmingly use open source components for the nondifferentiating parts of their business.
As a result, the wide range of organisations using open source in the cloud has increased pressure to create nonprofit foundations to host shared code. Also, because no copy of any significant derivative of the code is passed to a third party, GPL-licensed software does not trigger its copyleft clause when run in the cloud. As a result, licensing approaches are either being strengthened to include cloud deployment as a trigger - the AGPL does this - or developers are seeing that, because the GPL does not force contribution, it's better to lower the barriers to corporate engagement and opt for permissive licensing.
The rise of cloud computing is also fueling new business models for open source. As an example, theservices offered by CloudBees to enterprise developers are largely built using open source software. However, they're hard for a competitor to replicate because the full operational source (including operations scripts) is not supplied and the experience and skills to replicate it are costly enough to give CloudBees a competitive lead.
Witness the rise of cloud-focused open source communities, such as OpenStack, and you can see how central the cloud is to today's open source movement.
The historic revenue model around open source software has been to monetize consulting, support, and services around software delivered free of charge. The rise of data-centric and data-driven organisations is changing this.
In today's market, the largest base for open source software - companies like Google, Facebook, and Twitter - derive value from the way their users or customers access software online, rather than by charging for access to the software. They gather massive amounts of data about user activity and process it to drive their actual business. Thus, what differentiates their business is not the software itself, but the way it is configured, deployed, and combined with other software to manage and extract value from data on an epic scale.
For these businesses, tight control over software is no longer critical to their profit. It's no detriment to their business for customers and even competitors to have many of the same software components they are using. As a consequence, many of these entities experiment both by open-sourcing internally developed code and using open source code created by other entities, including competitors, in core business functions.
As more businesses move toward business models where the mere software they use does not differentiate them, we can expect to see further growth in open source: more projects released, more businesses engaging in open source communities, more pressure for patents to be remediated and licenses to be chosen wisely.
Open source future
The open source movement has evolved significantly since OSI was launched 15 years ago. Yet in many ways, the factors driving open source use and adoption are simply heirs of the original drivers of open source: the four software freedoms and their guarantee through open source licensing.
As long as we keep focus on those freedoms to use, study, modify, and distribute the source, we'll keep finding new ways that software freedom drives benefit to the individual, to business, and to society as a whole. The forces driving open source will continue to change; their origins in software freedom won't.
Follow CIO on
Download CIO for your tablet here.
Click here to subscribe to CIO.
Sign up to receive free CIO newsletters.
Send news tips to email@example.com
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.