Today, it is clear—any software development platform that is not open source faces a sustainability crisis.
And yet, most of the largest software businesses built over the last few decades are still fundamentally dependent on a closed source, proprietary licensing business model.
A handful of incumbent software powerhouses have seen the writing on the wall and are attempting to execute the high-wire act of transitioning to open source models. Seeking to stem an ongoing decline of its traditional lines of business and carve out a spot in the new order, IBM is purchasing open source stalwart Red Hat for $34 billion, in the largest software acquisition in history (a true bet-the-farm bid, with the purchase price amounting to almost a third of IBM’s market capitalization at the time it was announced).
But what about the rest of today’s largest enterprise information technology vendors—and consumers—that are failing to adapt?
How should we, as an industry, prepare for the inevitable decline of the enormous legacy businesses that fail to navigate the open source transition? Their employees, customers, and shareholders face a precipitous fate. Whether these businesses fail quickly or slowly, they risk dragging under every customer that doesn’t have a plan to manage its transition to the era of open source development.
Closed source application platforms are in an unstoppable tailspin. It’s time to pull the ripcord.
To chart the best path forward, it’s critical for businesses that depend on third-party software to understand the failures that have condemned closed source application platforms to the dustbin of history, the corresponding advantages of modern community-led open source, and how to make the transition from one to the other.
The 5 failures that doomed closed source platforms
Just reading the headlines demonstrates why application developers are abandoning closed source platforms in droves:
Failure 1: Loss of strategic control
Relying on third-party closed source software means ceding control of your own destiny.
In the recent mobile enterprise certificate kerfuffle, even the mighty Facebook and Google were subject to having their internal mobile applications instantly disabled by Apple on a whim, with zero notice. If the most powerful technology companies in the world can’t guard against this, what hope does an average business have?
Failure 2: Security exposure
In the closed-source software model, there is typically no way to know what’s going into the software that’s delivered to you, and in turn being incorporated into your own applications.
The result? Closed-source products have faced myriad software supply chain attacks, whether originating from employee insider threats or external attackers.
Failure 3: Unknown deployment lifetime
When the software your build your applications on is closed source, the vendor can end-of-life your application without consulting you. There is little you can do, other than hope that a situation like this never happens.
As illustrated by Adobe’s retirement of Flash, with closed-source application platforms you’re fully exposed to the whims and realities of someone else’s business.
Failure 4: Friction and overhead
As applications get more complex and interconnected, it’s no longer feasible to go through extensive sales processes and negotiations just to experiment with each of the many software components you consider using to build your apps.
One of the key reasons open source works so well is that it keeps the overhead associated with working with your software to a minimum. Any technologist who has wrestled with proprietary graphics drivers on Linux can explain how one proprietary component can wreck the fluidity of open source.
Failure 5: Licensing cost
When the copyright to the software your applications depend on is controlled by a single party, you’re susceptible to arbitrary price increases at any time.
Even if it’s released under an open source license today, if the copyright is held by a single commercial entity that dominates its development, future versions could still be relicensed under punitive terms, once you’ve already built it into your applications—a pernicious bait-and-switch!
Given these fundamental structural challenges of closed source, it’s obvious why application developers have sought out open alternatives.
The 5 advantages of community-led open source
Fortunately, all is not lost. The dramatic rise of community-led open source in application development results from clear advantages it provides over the prior generation of closed source.
What is “community-led” open source?
Open source community leader Wes McKinney describes it well, observing that industry or corporate-led open source projects are typically started and sustained by a single company or consortium, while community-led projects arise organically out of a broader community of stakeholders including individuals, businesses, universities, governments, and others. That means community-led open source projects are much more decentralized in terms of control and influence, making them more resilient.
As an example, because the Linux kernel is maintained by a diverse community of contributors, it’s less susceptible to the influence of any one actor than a vendor-controlled project.
Advantages of using community-led open source software in your applications, as compared to proprietary closed source software or even corporate-led open source, include:
Advantage 1: Full strategic control
As a user of a healthy community-led open source project, you have full control to use the software in accordance with its open source license terms.
It doesn’t matter if you are building a software-powered device, software-as-a-service, or an application that you deploy on your own hardware or a public cloud. In any of these cases, you can rely on the permissions granted by the open source license, once and forever.
Advantage 2: Security transparency
Because all of the source code is available, both you and the broader community of users can inspect and review the software continually to search for—and resolve—new and existing security vulnerabilities.
Even high-profile open source projects such as Kubernetes and Docker regularly see end users discover and raise critical security vulnerabilities through transparent responsible disclosure processes, shining sunlight on the inevitable defects that arise with any software. If your application relies on closed source software, you’re largely at the mercy of a single vendor to identify security issues. Given today’s reality of state-sponsored attacks on private companies, that’s just not good enough.
Advantage 3: Unlimited deployment lifetime
Since community-led open source projects are open-ended, their deployment lifetime is unlimited, so your application isn’t subject to the whims of your software suppliers.
For example, when Apple acquired FoundationDB, it alarmed many of the software’s commercial users when it abruptly stopped distributing the database software. Fortunately, in that case, FoundationDB was later reborn as an open source project with a goal of becoming community-led. Many closed source projects aren’t as lucky.
Advantage 4: Low friction adoption
With community-led open source, getting started is typically as easy a few keystrokes to install a package from a community-maintained open source repository: npm install packagename and you’re off to the races.
With closed source, step one is often a negotiation. Even if you can download a trial version of a closed-source proprietary product, you’ll almost always be tied to a vendor-specific license agreement with potentially unbounded restrictions and obligations that are inherited by your own application (and you’ll have your attorney review that legal text before clicking the button, right?).
Advantage 5: Clear licensing and cost expectations
When the code is released under a clear open source license and the key intellectual property (including copyrights and related trademarks) is controlled by a more diverse community of contributors, you know what you’re signing up for today—and in the future.
With community-led open source, if you’re not happy with one commercial services provider, you have other options to pursue, without abandoning the underlying software you depend on entirely.
Across these dimensions, community-led open source sounds great—and it is! That explains why it’s taking over the world of application development, and why closed source application platforms are in freefall.
But community-led open source by itself isn’t perfect. We can make it even better!
How can you get the best of both worlds?
Today, navigating from legacy closed source application platforms to modern community-led open source isn’t a trivial matter. In fact, while closed source software is on the decline, there are some redeeming qualities that professional application developers came to expect in the prior era that many projects in community-led open source haven’t fully replicated yet.
For your development team to be successful using community-led open source projects in a commercial context, you’ll probably still need the following:
A service-level agreement: a promise, backed by an organization you have a contractual relationship with, to respond to your inquiries on an agreed-upon timeline.
Legal assurances: legal guarantees about the provenance of the software and indemnification against intellectual property claims caused by its use in your applications.
Support and maintenance: an organization you can pay to be accountable to keep the software you depend on working well, resolve defects, and address urgent security issues.
Interestingly, while these assurances have traditionally been available mainly for proprietary products, none of these assurances actually require the underlying software to be closed source—suggesting the opportunity to recreate them for the new world of community-led open source.
Many of the most successful commercial vendors in the open source world, like MongoDB, Red Hat, and others, saw the opportunity to provide these sorts of services years ago, and the success of those companies is proof of an urgent need.
In the broader application development software context, similar offerings are now emerging. Help is on the way.
While most of these new models focus on a single open source technology or community, the majority of projects used in typical applications simply don’t have enough critical mass on their own to support an independent company. There is a clear opportunity to bridge the gap for both users and creators of open source by applying a different business model—specifically, the managed marketplace, which is familiar from modern consumer applications such as Lyft and Airbnb, but largely a novelty in the world of B2B software. By sharing pooled commercial infrastructure in an online marketplace, both consumers and creators of open source project come out ahead.
The result: better, more sustainable options for those who rely on software to build their businesses. And our digital society.
Because of its many advantages, community-led open source has already gone a long way toward replacing proprietary closed-source software as the tool of choice for application developers. Now, with the emergence of new commercial models for open source, developers can truly enjoy the best of both worlds—and write the epitaph for closed source application platforms once and for all. 💀
Top comments (8)
I think open source is great and it is great when people have the ability to manage an open source library/application/tool. I've only written a few small open source libraries but I have read of many people with larger libraries being overwhelmed with how much work there can be and/or pressure from the community. While the specific causes of that is its own topic for discussion, I think it can lead to similar issues that you've mentioned for closed source.
Closed source or open source, if you become reliant on a library or tool that does reach an end-of-life/support, you can become stuck quickly. While you might have the source code, you end up in the same circumstance maintaining something directly yourself that you wouldn't have otherwise intended. You are better off with the source code but you aren't out of the woods so-to-speak.
It might not be just open source software that we need but more open standards and greater interoperability between related software. This would remove friction when changing between tools etc though depending on the tool, this could be a logistical nightmare or completely impossible.
And you know what they say about standards...
Besides that though, I did want to talk about the example you had for "Failure 1: Loss of strategic control" as I feel it unfairly makes Apple look like the bad guy here. While they did remove the apps from Google and Facebook, your articles did note that both companies violated the terms of service.
Closed platforms like Apple's App Store are a different beast of issues altogether. I'm far from an Apple salesman but I figure besides the "premium" branding of Apple, they probably want to associate trust. Allowing Apple to manage it is meant to allow us to more easily accept/trust what can safely be installed without a threat.
A code base can be entirely open source but still be a closed platform from a certain point of view. Take this site for example, the entire code base is open source (which is fantastic) but technically is a closed platform. Sure I can post articles and comment but I don't run this site and if I violate the terms and conditions, I could be kicked out (same as your example with Apple/Facebook/Google). I might be able to launch an exact duplicate of the site because the code is open source but it isn't really the same. I might have a great blogging site but I won't have anyone to read my posts - the site's audience/reach is that "proprietary" feature.
Even if open source took over everything, I think closed platforms have to exist.
Some great points, James! Building on your point about loss of strategic control, when developers select true community-led open source components for their applications, they know they can at least rely on the elements of the Open Source Definition, including:
That last bullet is what distinguishes from the Apple case I reference, specifically.
I'm still not sure that last bullet really fits with that Apple example. They didn't discriminate, the rules that were originally agreed to were breached.
Taking that point to an extreme would be something like: any rules that need to be agreed to is a form of discrimination to any parties not wanting to agree to them.
I'm not saying Apple can't or hasn't at other times specifically discriminated against anyone, just that the example with Facebook and Google was the fault of Facebook and Google.
For example, I would say Apple is discriminating if they specifically didn't want Facebook or Google on their platforms at all even if they didn't violate the terms of service. At that point, it is abusing market power to avoid competition.
Regardless of how I see this situation with Apple/Facebook/Google, this situation is also not unique to that and its "closedness". The same situation could be seen with Mozilla with add-ons for Firefox (they control the main distribution process) yet Mozilla is both an affiliate of OSI and pushes open source heavily. You have to agree to Mozilla's terms and conditions to submit an add-on as well as go through the review process.
"When the software your build your applications on is closed source, the vendor can end-of-life your application without consulting you. " and when it is open source the people who maintain it can lose interest and you have the same problem.
I have lost count of the number of times I have come back to an application only to discover the libraries used are no longer being updated.
Totally agree, Chris. A key challenge is to create the right incentives to encourage ongoing maintenance of open source projects of all kinds (especially libraries), and align that with the interests of the teams using those projects. We're working on that at Tidelift if you're interested in one approach.
Great article. I'll bookmark it and show it to people who still consider using closed source software for their critical mission…
Really great post!
DEV is in a different category of commercial open source, but a lot of this logic led to our choices. Open source software improves over time. Closed source software decays.
The universe is complex and there is no ultimately answer to all problems. This is also applies for Open source. You can bring 5 or 10 arguments for open source. There is also 1 Mio again it.