<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

Open source: the rise of the rest

Donald Fischer
by Donald Fischer
on September 6, 2018

Updated on December 26, 2019

Don't miss the latest from Tidelift

Linux, Kubernetes, Kafka, React. These star open source projects attract millions of dollars in venture capital, corporate donations, and in-kind support.

But behind each of these projects—and other star projects like them—is a supporting cast of hundreds of packages that make it all possible.

Consider Angular. Here’s a visualization of packages in the npm package manager that angular-cli depends on:


(Credit to Mike Bostock of Observable for the visualization)

A handful of those packages are actively maintained by engineers on the Angular team (which is great!). All the rest are coming from somewhere else, with uncertain support and maintenance (which is an issue).

The shoulders of the curve

So how many open source packages are used in professional applications, but don't have a team funded to look after them, exactly?

We've done the math based on organizations using the Tidelift dependency analysis, and it's clear that there are tens of thousands of packages used by professional application development teams. The vast majority of those packages don't have any team ensuring their security, legal status, or making formal commitments to ongoing maintenance.

In fact, the frequency of use for open source packages follows a power law distribution, also known as the familiar "long tail."

The packages at the head of this curve are the ones with the VC-funded startups and internet behemoths firmly behind them. They're doing fine, but they represent a very thin slice of the curve.

Conversely, the packages in the tail aren't used as much, so the demand for formal support and maintenance just isn’t there.

But the tens of thousands of packages in the middle, in the "shoulders" of the curve?

Those packages are the ones professional organizations already use across their applications, but don't have a regular support system standing behind them.

How can we address the need to professionally maintain these packages, and reward the creators behind them? That's where we’re focused at Tidelift.

A business model that works for the rest of open source

In the technology startup community, Steve Case has championed the concept of The Rise of the Rest to describe the tech scene happening outside of the three major tech hubs of Silicon Valley, New York City, and Boston.

There’s a parallel story unfolding in our software ecosystems as well. While few high-profile open source packages attract much of the attention—and the bulk of the corresponding financial support—the reality is that there are thousands more packages that are equally important, but fall outside the spotlight.  

That’s a problem for the maintainers who labor to keep those packages well maintained, and also for the users of those packages who can’t always rely on solid, professional maintenance for these lower profile, yet still critical components.

With Tidelift, we’re introducing a new solution to this problem. When professional teams subscribe to Tidelift, we identify all of the open source dependencies they rely on, including the “hidden” transitive dependencies. Then, we partner with the individuals and teams who maintain those packages to provide security, licensing, and maintenance assurances. In exchange for maintaining their packages as part of the Tidelift Subscription, we deliver a predictable income stream to those open source creators.

We think the Tidelift approach is a compelling way to get help fund “the rest” of the open source projects, while also helping the star projects get even more funding, too. And at the same time, Tidelift provides a compelling answer to the question “who is supporting this?” for “the rest” of the open source packages professional development teams rely on. It’s a win for open source maintainers, and it’s a win for professional development teams.  

If you’re interested in learning more about this approach, here’s where you can learn more:

New Call-to-action