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. 💀

Photo by qinghill on Unsplash