Forem: Donald Fischer

Thinking upstream about the White House cybersecurity executive order

Donald Fischer — Wed, 19 May 2021 16:42:17 +0000

The upstream parable

Stop me if you’ve heard this one before.

Three friends are relaxing beside a river. Suddenly, they hear the sound of someone crying out for help.

Looking out into the river, they see a child flailing in the middle of a strong current. The first friend moves quickly, jumping in and swimming as fast as they can to get the child and pull them to safety.

Before the first friend is able to get back to shore, there are more cries for help. Three additional children are in the river, in need of urgent rescue. The second friend, knowing he must rescue all three at once, grabs a nearby raft and paddles out into the river.

Meanwhile more children keep popping up, all needing rescue. This second friend, overwhelmed, desperately looks around for the third friend, who is nowhere to be seen.

Finally, he spots her, in the river, swimming upstream.

“Where are you going, these children are going to drown!” calls out the second friend.

The third friend keeps swimming and calls back:

“I’m going upstream to find out who is throwing all of these children in the river!”

What is upstream thinking?

This parable is at the heart of what is known as upstream thinking. In his recent bestseller Upstream: The Quest to Solve Problems Before They Happen, author Dan Heath introduces the concept this way:

“So often in life, we get stuck in a cycle of response. We put out fires. We deal with emergencies. We stay downstream, handling one problem after another, but we never make our way upstream to fix the systems that caused the problems. Cops chase robbers, and doctors treat patients with chronic diseases, and call-center reps address customer complaints. But crime and chronic disease and customer complaints are preventable! So why do our efforts skew so heavily toward reaction rather than prevention?”

So if downstream thinking focuses on solving problems after they occur (fishing children out of the water, in our parable), upstream thinking focuses on efforts to prevent problems before they occur (“I’m going to find out who is throwing all of these children in the river!”).

Those who practice upstream thinking, also known as upstreamists, are systems-level thinkers, seeking to understand the root causes of downstream emergencies.

Upstream thinking and the White House cybersecurity executive order

Which brings me to the recent White House cybersecurity executive order, which we’ve done a full debrief on here.

TL;DR: the cybersecurity executive order is an attempt by the United States government to use its purchasing power to create positive changes to the way cybersecurity is addressed around the world.

Recent high profile breaches like the Colonial Pipeline ransomware attack or the SolarWinds software supply chain attack have shown that our cybersecurity defenses are woefully inadequate. This executive order forces a higher standard of cybersecurity for any organization selling software to the federal government, which in turn makes it the de facto global standard for all software in the future.

As I read the executive order for the first time, I couldn’t help but think it provides an incredible opportunity to apply upstream thinking to software.

In open source, the focus has been downstream for too long

Sticking with our parable for a second, when we look closely at the problems that open source software has faced when it comes to cybersecurity, most work over the past few years has gone into developing downstream solutions that help those already in crisis.

In fact, an entire industry has cropped up around software composition analysis (SCA) and container scanning tools that will tell you what is wrong with your software from a security or licensing perspective. This kind of open source urgent care has become a big business, with companies raising hundreds of millions of dollars and grabbing the attention of frustrated CIOs who don’t want to go down in flames as “the next Equifax.”

But are we really content to continue being overwhelmed by a never-ending parade of open source health crises?

Or should we instead turn our attention upstream?

Spurring an upstream movement in open source

On June 7, Tidelift will be hosting a completely free, virtual event to celebrate open source and the people who create it, and we’ve named it Upstream (sign up here!).

From the Wikipedia definition of upstream, as it relates to software development:

“In software development, upstream refers to a direction toward the original authors or maintainers of software that is distributed as source code, and is a qualification of either a version (released by the original authors, based on their upstream source code), a bug or a patch.”

Our original intent with this name was to honor the work of the people who create and maintain the open source code that all of our applications rely on: the upstream maintainers.

But we also loved the dual meaning, that this event could serve as an opportunity to spur a movement of upstream thinking in our open source corner of the universe.

While Dan Heath’s book shares examples of upstreamists operating in many different fields, healthcare is probably the field where upstream thinking has seen the most traction.

For some broader perspective and inspiration, we’ve invited one of the leading upstreamists in healthcare, Dr. Rishi Manchanda, to give a keynote at Upstream. If you haven’t seen his TED Talk on upstream thinking, you can view it here.

But why wait? We can start applying upstream thinking to open source software security and maintenance issues right now!

Applying upstream thinking to open source

Let’s do a little exercise in upstream thinking.

Problem: managing open source effectively and keeping it secure is an enormous challenge

For most organizations, it has become a difficult—if not practically impossible—task to effectively manage the security and maintenance of all of the open source code they use.

In fact, a recent Tidelift survey found that only 16% of organizations with over 10,000 employees are extremely confident that their open source is up to date, secure, and well maintained. Meanwhile a whopping 39% were not very or not all confident in their practices for managing open source.

A downstream solution: scanning

Many of these organizations have attempted to solve their problem with software composition analysis tools that point out security, maintenance, and licensing issues with their open source dependencies. But too often these tools are introduced late in the development process, and report false positives or issues with no easy resolution. They are in essence crying out, “hey, there are children in the river!!”

Yeah, we know.

This leaves developers stuck with bad choices.

Replace problematic packages (with the associated delay, and only possible if good alternatives exist)
Rewrite the code yourself (if you have time)
Work with with an open source maintainer to get the issue fixed upstream (if you can get their attention)
Ignore the scanner result (if you want to roll the dice)

Heading upstream to discover root cause

It begs the question: why are there so many issues for scanning tools to find? And could we reduce the open source equivalent of emergency room visits by examining the environmental factors that are causing them?

There are a lot of root causes we could consider for issues in open source, from what motivates scanners to report false positives to how package managers deliver updates. But today I want to focus on one root cause that is staring us right in the face. It was perhaps most poignantly captured by this recent xkcd cartoon.

In open source, the majority of people writing the code that modern digital infrastructure depends on are volunteers or are grossly under-compensated for their work. In other words, random people in Nebraska, thanklessly maintaining projects since 2003.

Sneak preview of our upcoming maintainer survey results: almost half of maintainers are paid nothing—not one cent—for their work, while more than half are paid less than $1,000 US per year. Only 6% are paid what might be considered a living wage (more than $50,000 US per year).

Which means that for most maintainers, open source is more of a hobby than a profession. It just happens to be a hobby that all organizations are counting on them to keep doing, to an enterprise standard, without compensation.

It doesn’t take a neurosurgeon to uncover the root cause here.

An upstream solution: partner with maintainers and users to improve software health and security

Which leaves us with some simple truths:

Enterprises building applications on top of the modern open source digital infrastructure need open source they can rely on.
Open source maintainers should be fully compensated if we expect them to deliver secure, well maintained software built to an enterprise standard.

It might seem kinda obvious, but one solution is to build a model where maintainers get paid to do the work enterprise users need them to do.

How many security issues could be avoided if maintainers were being properly compensated to ensure their components stayed secure and up to date? Even more interesting: how much amazing open source software isn’t even being created today because there aren’t incentives in place for the people who might create and maintain it?

In Rishi Manchanda’s TED Talk about upstream thinking, he tells the story of Veronica, who appeared in his clinic suffering from debilitating migraine headaches and severe allergies. Multiple visits, multiple treatments, nothing could fix what was wrong with her.

Until Dr. Manchanda asked her about where she lived. It turned out that her house was moldy, wet, and roach-infested. Instead of prescribing another medication to treat her symptoms, the doctor referred her to a specialist who could help her improve her housing conditions. As if by magic, once her housing conditions improved, her migraine headaches and allergies disappeared.

If we really want to address the health and security of open source, it’s time to get our house in order.

Let’s pay the maintainers and get a head start on tackling a principal root cause of open source cyber insecurity once and for all.

If you're interested in exploring this topic further, please join us on June 7 for Upstream, a free online one-day celebration of open source, the developers who use it, and the maintainers who create it.

Photo by Michael Niessl on Unsplash

Introducing Upstream: A free one-day celebration of open source, the developers who use it, and the maintainers who create it

Donald Fischer — Tue, 06 Apr 2021 21:07:17 +0000

Open source is an amazing testament to human ingenuity.

We don’t often stop and take the time to celebrate what we—the creators and users of open source—have made together and the impact it has on our world.

So let’s stop and do exactly that!

On June 7, 2021, please join us for Upstream, a new one-day celebration of open source, the developers who use it, and the maintainers who create it. This 100% virtual, completely free event will bring together like-minded application developers, open source project maintainers, and the extended network of people who care most about their work.

Do you ever stop to think about all the open source libraries, frameworks, and components that your applications depend on? All those dependencies—hundreds of lines scrolling by when you run an "npm install" or the equivalent in another language? Upstream is about zooming in on the creators behind those essential open source packages and the developers who build amazing things with them.

We’ll journey with the maintainers behind the open source libraries and frameworks you use every day, across ecosystems including JavaScript, Java, PHP, Ruby, Python, .NET, Rust, and Go, learning the “how” and “why” behind the projects, and getting sneak peeks into where they are headed next. We’ll explore today’s most interesting and exciting open source projects, and ride along with those developing applications with open source at scale.

Our goal is to accelerate the creation of even more great open source software by bringing together an inclusive community of people with a shared interest in making open source work better for everyone.

You can learn more and register for free at Upstream.live. The first 300 people who register will receive some cool goodies, so don’t miss out. (Shipping to North America only, sadly.)

Do you have an interesting story to share you think might be a fit for Upstream? We are accepting applications until May 4 for presentations from developers using open source to build interesting applications and open source maintainers who want to share more about their projects or passions.

We look forward to seeing you at Upstream!

Tidelift catalogs and the rising urgency of managing your open source supply chain

Donald Fischer — Thu, 11 Feb 2021 15:14:56 +0000

Today, Tidelift is introducing several exciting elements of the Tidelift Subscription that help organizations more efficiently manage the health of their open source supply chain.

At the heart of this news are some important advancements around Tidelift catalogs, which provide a comprehensive way for application development teams to create, track, and manage collections of known-good, proactively maintained open source components with help from Tidelift and its partnered maintainers.

We’ve also introduced the first set of Tidelift-managed catalogs, giving organizations a head start on building a paved path of approved components for development teams to use. These catalogs are enterprise ready, with Tidelift and its partnered maintainers managing them to meet clearly defined security, maintenance, and licensing standards.

Why should open source software supply chain health matter to you right now?

It used to be that the only people thinking about the software supply chain were CIOs and industry analysts. Today—thanks to the breach impacting SolarWinds and its customers around the world—these words have found their way to the front page of the New York Times and into tense boardroom conversations.

For good reason. The potential costs of software supply chain attacks can be staggering. We are only beginning to come to grips with the impacts of the SolarWinds exploit. The Equifax breach cost that company billions in shareholder value and caused unknowable damage to all of us in terms of compromised data security.

In conversations with executives—especially over the past few months—I’ve seen software supply chain health go from somewhere in the middle of the list of IT priorities to the very top.

Meanwhile, open source continues to become a larger and larger part of the application development supply chain, with our research showing that 92% of applications contain open source components and in some cases open source makes up 70% or more of the code.

Which brings me to some simple math and a new reality.

More software supply chain attacks
+
More open source software
=
More risk of open source software supply chain attacks.

Supply chain risks are compounded in the open source world because every project has historically had its own standards and processes for handling security and maintenance. Some projects have robust checks and balances in place, with extensive staff paid by the biggest companies to look after their open source code full time. Other projects have—as xkcd so artfully put it—a lonely maintainer, living in Nebraska, thanklessly maintaining their code since 2003. And some projects have no one actively looking after the code at all—even thanklessly—because the last maintainer ragequit after a particularly bad day in the issue tracker.

So if you work in an organization using open source for software development, and let’s face it, most of us do, you’ve probably at some point made a judgement call on whether your organization would rather move fast or stay safe.

Move fast—letting developers pull in whatever open source code they need, YOLO and go, take whatever risks may come in stride and deal with any security or code maintenance issues as they come up. Roll the dice, and hope for the best, so your developers can keep moving.

Or stay safe—put guardrails in place to ensure any open source being used in the organization is fully vetted, run through scanning tools to check for security, maintenance, and licensing issues and basically implement a bureaucracy that keeps risk at bay, while also dulling all of the shiny parts of using open source to accelerate development.

It is a depressing tradeoff to make. And thankfully, no longer a necessary one.

Let’s solve this with the creators of open source!

For the past few years at Tidelift we’ve been focused on how to help development teams and the organizations they serve avoid this false choice—between moving fast and staying safe— by constructively partnering with the creators behind the open source packages they depend on. We wanted to develop a solution that allowed them to move fast and stay safe. With Tidelift catalogs, that’s exactly what they get via the Tidelift Subscription.

Watch our new on-demand demo.

Manage your open source supply chain with Tidelift catalogs

With catalogs—included as part of the Tidelift Subscription—organizations have a comprehensive approach to creating, tracking, and managing the open source components they are using for application development across the organization while setting and enforcing usage policies.

A paved path: Organizations can accelerate development and reduce security and licensing-related risk by defining and curating catalogs of known-good, proactively maintained components. Developers can draw from them safely without fear of late-breaking deployment blockers.
Clear policies: Organizations can set and automatically enforce standards early in the development lifecycle, such as an organization’s license policies.
Integrated experience: Tidelift integrates with existing source code and repository management tools so developers don’t need to change their workflow. They can pull approved components and submit new ones for approval directly from the command line.

As I mentioned above, today we are also introducing our first set of Tidelift-managed catalogs, giving organizations a head start on building a paved path of approved components for their development teams to use.

Organizations can pull from Tidelift-managed catalogs of known-good, proactively maintained components covering common language frameworks like JavaScript, Python, Java, Ruby, PHP, .NET and Rust, backed by Tidelift and its partnered maintainers. These catalogs are designed to be enterprise ready, with Tidelift and its maintainer partners managing them to meet clearly defined security, maintenance, and licensing standards.

Address the open source-related concerns of multiple stakeholders

With catalogs in place, the Tidelift Subscription now delivers value across the organization:

For managers: Increase development velocity while ensuring development teams are building with safe, approved, and compliant components from the start.
For developers: Move fast and avoid rework, eliminating late-breaking surprises that slow down development by using pre-approved, known-good components.
For information security: Get a single place to define, review, and enforce policies around security vulnerabilities in open source components.
For legal: Get a single place to define, review, and enforce license policies and get indemnification to protect against licensing-related risk.

And help pay open source maintainers for their work

Best of all, Tidelift-managed catalogs are backed by Tidelift and our growing network of partnered open source maintainers. We pay the maintainers to keep their projects and these catalogs enterprise-ready.

The more subscribers using a project, the more its maintainers get paid. Which means they can dedicate even more time to maintenance and security tasks, while continuing to invest in making their projects even better.

Making open source work better—for everyone

Look, it can be an ugly world out there and no matter how you slice it the threats to the health of your software supply chain are going to continue to increase over the coming years. Straight talk.

But now with catalogs as part of the Tidelift Subscription you can begin to take back control of your destiny, and avoid making lose-lose choices about slowing development speed or increasing risk. Instead, start to efficiently manage open source across the organization, ensuring you can take advantage of all of the things you love about open source—and using it to its full potential.

In a recession, who’s looking out for the open source maintainers?

Donald Fischer — Tue, 12 May 2020 14:37:21 +0000

As the global economy enters a recession triggered by many businesses, schools, and services shutting down to slow the spread of COVID-19, I’ve been reflecting on what these precipitous changes mean for the future of open source.

While several people have written thoughtful pieces on how open source as a whole might be impacted, I’ve been wondering specifically about the effect these changes might have on independent open source maintainers. You know, the people who write and maintain most of the open source code you are using to build your applications?

Today independent maintainers are, like many people, under more time and financial pressure than they were only a month or two ago. Most of these creators work on their projects on the side—not as their main day jobs—and personal and professional obligations come before open source work for many.

So how are they feeling right now? Since here at Tidelift we work with the maintainers of thousands of the most significant independent open source projects on a daily basis, we thought we’d just ask them directly.

Jordan Harband, maintainer of more than 250 JavaScript packages and a long-time member of the committee that writes the JavaScript specification, says available time isn’t the only consideration factoring into open source contributions.

“Contributing to open source is a privileged thing. Contributors need to have enough income to create enough free time to contribute, or a job that allows them to do it on company time,” Jordan said.

“But everything is harder now, and the available energy supply many maintainers have to work on their projects on evenings and weekends is smaller than it was a few months ago. In the past, open source maintainers pitched our employers to ask them to cover some portion of our time spent on our projects as part of our salary. Now that budgets are tighter and many companies are focused on short-term survival, I'd expect many maintainers to have less time for their projects.”

Most crucial open source projects are maintained by volunteers

Usage of open source consistently booms during times of economic strain as organizations rush to do more with smaller budgets. At the same time, market upheavals create openings for new businesses. Shared open source infrastructure and application frameworks let innovators in every sector build and introduce products and services quickly and cost-effectively. They also permit engineering teams to focus developer talent on creating differentiated products or features, rather than recreating commodity technologies.

Corporations fund much of the development of some big infrastructure building blocks, like Linux, widely used NoSQL databases, Hadoop, Docker, and more. But corporate sponsorship has a much more limited role when it comes to the crucial open source components that comprise most business applications today. Nearly all of the work on projects like Babel, Beautiful Soup, and Material-UI—which are integral to application development at thousands of organizations across industries like financial services, healthcare, and more—is performed by independent open source maintainers.

Given this, what will happen to critical open source projects when the maintainers behind them need to redirect energy to their day jobs as workplace demands intensify? Or when maintainers have other life commitments that cause them to set aside work on unpaid projects, potentially indefinitely?

“I think people will have more time to contribute, but less energy to do so,” Jordan said. “Most of it will be tied up in dealing with the psychology of being stuck in your house, perhaps newly working outside of an office, or worse, not working at all, and trying to figure out how to pay the bills.”

Backing independent creators to ensure project maintenance

Some in our industry predict we’ll see more open source contributions as engineers have more time at home.

The maintainer of the Active Admin framework for Ruby on Rails applications and the byebug debugger, David Rodríguez, has already seen this effect.

“I’ve found either the same level of engagement or more in terms of contributions to my projects since the COVID-19 crisis started, so the ‘people have more time’ hypothesis could make sense.”

While at Tidelift we’d not be surprised to see some individuals step up their contributions, we expect maintainers of many other projects to put their work on hold as long as necessary to attend to other priorities. When any recession passes, we’d anticipate further strain on independent maintainers if their day jobs change—a dynamic some call the “bus factor,” but we call the “boss factor” to more accurately reflect the fact that independent open source projects are left in precarious condition when things change with solo maintainers’ full-time jobs.

Businesses that rely on open source to fuel their own development need to plan ahead for potential interruptions to the maintenance of critical open source components and get ahead of them. One way to do this is by aligning with maintainers to give them a financial incentive to continue to develop their projects on a predictable timetable. Another is to have processes in place to vet open source components across numerous parameters to understand whether they are well-maintained.

Hope for the future

Alex Clark, the creator and project lead for Pillow, the friendly fork of the Python Imaging Library, is hopeful that open source, including individual maintainers, will share in some of the growth that open source companies have experienced in past recessions.

"For me the most comforting aspect of Tidelift's existence, particularly in the time of a pandemic, is just that: it's existence,” Alex relayed. “In the previous two recessions, when both Linux and then open source in general saw significant upticks in usage, no such companies existed.”

“If companies like Red Hat (circa 2000) and GitHub (circa 2008) were super-successful in their respective time as a result of recession, then I hope companies like Tidelift (and individual developers like ‘Tidelift lifters’) are super-successful this time."

Photo by Federico Respini on Unsplash

COVID-19 will accelerate, not delay, tech innovation

Donald Fischer — Tue, 21 Apr 2020 14:33:32 +0000

The global pandemic is a shock to many aspects of life—as individuals, families, teams, and organizations. For sure it’s changing business as usual, initially by introducing uncertainty and friction into many parts of life that we previously took for granted.

At first, this felt to many like a seizing up of the gears, with many aspects of our modern civilization grinding to a halt. But at a time when it is difficult to look at things through an optimistic lens, it comforted me to spend a few minutes seeking a positive side to the recent turbulence. What if the next phase of our journey is not a slowdown, but an acceleration of inevitable technological changes that were already simmering in the background before this global crisis?

From my vantage point on the industry, I identified three key transformations enabled by technology that are set up to accelerate—not decline—in this changing world environment.

Remote work

Zoom and Slack may both be having a moment right now, but neither were conjured out of the ether. Many organizations—including Tidelift—have been remote-first for years and conduct most of their business via these platforms.

COVID-19 has accelerated the adoption of this style of collaboration by necessity in traditional organizations that had previously only experimented with it. And with K-12 schools and universities attempting to execute an on-the-spot flip to distance learning, the next generation is even more likely to be comfortable in a remote work environment much sooner than before COVID-19.

When we emerge on the other side, our individual and collective skills and working conventions will be transformed. Sure, many will return to offices, but our expectations around the tools and constraints that we’ve traditionally clung to will be dramatically changed.

My question: once we’ve learned how to be effective as distributed teams, will we want to go back? What additional productivity, what new opportunities will this new style of work unlock?

Cloud, managed IT services, and open source

For technology-driven organizations, the new constraints imposed by the economic fallout of the pandemic all point in one direction: do more with less resources. Obvious technology levers that organizations can pull to reduce costs and sharpen their focus on their value-added products and services, while maintaining effectiveness, are expanding use of the cloud, making smart use of managed technology services, and leveraging open source software.

Most organizations have been increasingly adopting cloud and turning to managed service providers in key areas like cybersecurity that can’t be deprioritized in a tough economy, yet require specialized expertise. With the tightened resources—and heightened expectations—from today’s economic environment, that’s only going to accelerate.

Recently Dries Buytaert wrote an article asking whether open source is recession proof, sharing some of the experiences of past downturns, and I added my own perspective in this followup post about how and why open source usage tends to expand and not contract in a recession.

Non-traditional workforce models

A new generation of businesses are leveraging the first two trends—remote work and democratized cloud and open source platforms—to enable entirely new business models, like two-sided business-to-business marketplaces and the gig economy—that simply only work when 1) participants are distributed and 2) business is conducted entirely over the Internet.

We’re all familiar with two-sided marketplaces in the consumer sector—headlined by services that transformed what we consume, like Spotify, Netflix, DoorDash, and many more. The societal shock resulting from the pandemic is opening eyes to the possibilities for similar economic models in other sectors.

For example, here at Tidelift we leverage cloud and remote work tools to make it possible for companies to partner with individual creators located all around the world to ensure the software they are using meets commercial standards.

This shift is already playing out in parallel contexts, such as the artistic crowd-funding platform Patreon, which saw a huge uptick in its artist sign-ups in the first weeks of the pandemic.

Durable change will emerge from crisis

The global pandemic of 2020 and its economic impacts are far reaching and deeply painful. At the same time, it’s becoming clear that the sudden changes in so many aspects of life are going to leave a lasting impact.

Through the broader societal lens, let’s hope that the silver lining is that this shared experience accelerates our focus on creating stronger public health and social support systems. Meanwhile a massive change to the way we work is underway—driven by the increasing need for remote work options, cloud, IT, and open source cost savings, and flexible workforce models—and we may just now be stepping on the gas.

Photo by Sirima Sriraksa on Unsplash

The third wave of open source migration

Donald Fischer — Tue, 14 Apr 2020 14:17:21 +0000

A few weeks ago, Dries Buytaert, creator of Drupal and co-founder of Acquia, published a blog post entitled Is open source recession-proof? He wrote:

“...during an economic downturn, organizations will look to lower costs, take control of their own destiny, and strive to do more with less. Adopting Open Source helps these organizations survive and thrive.”

I joined Red Hat in the aftermath of the dotcom crash in the early 2000s, and lived through the rapid growth of open source during that recession. At the time, the main driver of open source expansion was UNIX to Linux migration.

And what was the single biggest driver of people abandoning their Sun Solaris servers and HP-UX or AIX installations and moving over to Linux?

Saving money.

It was simply much less expensive to run Linux than UNIX, because Linux could run on relatively inexpensive Intel hardware. Companies of all stripes made the jump because—in the midst of a painful recession—they could save a lot of money without sacrificing performance, all while avoiding vendor lock-in.

In the early days of the enterprise business at Red Hat, Sun Microsystems was a goliath with over 30,000 employees and Solaris was arguably the de facto web server platform. By the end of the decade, Sun was a shadow of its former self—in large part due to UNIX to Linux migration—and ended up being gobbled up by Oracle.

But UNIX to Linux was only the beginning of the proprietary to open source workload exodus. What started with the all-open source LAMP stack (Linux operating system, Apache web server, MySQL database, and PHP/Perl/Python programming languages) quickly expanded as the cost saving benefits of open source became more pronounced.

Proprietary databases such as Oracle and IBM DB2 started being replaced by more modern open source databases like MySQL, PostgreSQL, and MongoDB. At the same time, open source middleware—including application servers and servlet containers like Jetty and Tomcat—started to make inroads into the customer bases of big companies like BEA. More recently, open source has been critical to the open source strategies of storage management systems and networking solutions companies like Juniper and Cisco.

And when the financial crisis hit in 2008, the rise of hosted cloud services like AWS, Google Cloud, and Microsoft Azure (all of whom actually built most of their IaaS using open source too!) capped the second powerful wave of open source migration, as organizations looking to cut costs and improve flexibility moved workloads out of their own data centers and into the cloud, where the value prop for using open source was even stronger.

Now, after one of the longest bull market runs in history, the road ahead is again uncertain. As the COVID-19 outbreak upends entire industries, organizations attempting to get leaner without sacrificing competitiveness will return to the tried-and-true playbook, cutting IT costs by finding the next place to migrate to open source. At the same time, the pandemic has caused changes in consumer, corporate, and public sector spending that are effectively boosting other sectors, demanding that they quickly step up or alter operations to meet demand. These organizations also rely on open source throughout their technology stacks.

So where is the low-hanging fruit in 2020? A recent survey by Tidelift found that over 92% of all application libraries contain open source components. Yet in many organizations, development teams have balked at fully embracing open source for their application development projects.

Why? Despite clear advantages in other areas like technology flexibility, developer satisfaction, cost, quality, and security, the Achilles heel for open source applications has historically been the consistent availability of support and commercial assurances for the independently maintained open source components used to develop applications using JavaScript, Python, Ruby, PHP, Java, .NET, and other open source frameworks.

Often, these components are created by independent open source maintainers who have historically not been financially compensated to keep these components maintained to a commercial standard. So using them comes with more risk than using the earlier wave open source backed by big commercial open source companies.

And what workloads are primed for this next round of migration? Certainly any web application that is not yet built using modern open source frameworks like React, Angular, or Vue would be a great place to start. Or organizations still utilizing expensive data science platforms like SAS or MATLAB might find that they can save money, modernize, and attract top talent by instead using some of the new and powerful data science tools like NumPy, pandas, and SciPy. More broadly, for any technology-driven organization that hasn’t embraced the reality that the modern application development platform is a polyglot mix of open source languages, frameworks, and packages: the time is now.

The first and second open source migration waves were periods of rapid expansion for companies that rose up to provide commercial assurances for Linux and the open source databases, like Red Hat, MongoDB, and Cloudera. Or platforms that made it easier to host open source workloads in a reliable, consistent, and flexible manner via the cloud, like Amazon Web Services, Google Cloud, and Microsoft Azure.

This trend will continue in the third wave of open source migration, as organizations interested in reducing cost without sacrificing development speed will look to migrate more of their applications to open source. They’ll need a new breed of vendor—akin to Red Hat or AWS—to provide the commercial assurances they need to do it safely.

It’s been hard to be optimistic the last few weeks. But as I look for a silver lining in the current crisis, I believe there is an enormous opportunity for organizations to get even more nimble in their use of open source. The last 20+ years of technology history have shown that open source is a powerful weapon organizations can use to navigate a global downturn. In a few years, once the economy has recovered and global industry is humming along, hopefully we’ll look back at this as the moment the third great wave of open source migration began.

Photo by Dawid Zawiła on Unsplash

What is managed open source?

Donald Fischer — Thu, 27 Jun 2019 15:37:50 +0000

Take yourself back in time for a minute. It is 2007, and you’ve just finished building your new J2EE app. You get a message on your Blackberry from the guy in procurement, “Where do you want me to ship these Dell servers?”

Crap. You realize you still haven’t made a call on which colo facility to use. A good friend told you about one in Phoenix he really likes, but you have zero interest in flying 5 hours to Phoenix in the middle of the summer every time a server fails.

Now bring yourself back to 2019, same situation. Except this time you don’t have to worry about any of that stuff. When your Node app is ready to go, type a few commands, and you’ll have it up and running at your favorite cloud hosting provider in minutes. No airplanes, no hardware, no running around cold rooms plugging and unplugging cables. No procurement.

When it comes to getting your app launched out there in the world, things are infinitely simpler than they were a decade ago.

Yet when it comes to building apps by integrating open source components life can still be, well… difficult. Let’s count the ways you waste time managing your open source dependencies:

Staying up to date with the latest bugfix versions.
Porting to new, incompatible major versions of frameworks—when the upstream project has no bandwidth to support old releases.
Dealing with issues caused by missing or unreliable package maintainers: you get to waste your team's time porting to a replacement package (best case) or risk a nasty trojan (worst case).
Handling requests from your legal department to list every package you're using, along with their licenses.
Documenting everything you use for your security team, and addressing live vulnerabilities.

Our research shows that in modern application development, almost every application includes open source dependencies, and developers spend as much as 30% of their time on maintenance, with 25% of that time related to the open source components they use.

Much like the cloud computing movement revolutionized the way apps were hosted in the early 2000s, we see a revolution happening in the way apps are built in 2019.

It’s called managed open source.

So what is managed open source?

In short, managed open source is a way to free yourself and your team from the time you currently spend wrangling open source dependencies. And—just like you outsource your hosting responsibilities to Amazon or Google or Microsoft, now you can outsource the care and feeding of your open source components to the experts who know them best—the maintainers who created them—through Tidelift.

Here’s a short video with my take on managed open source and why I think it may be the answer to getting your team out of the business of dealing with open source dependency-related trivia. With managed open source, you can get back to what really matters—building your own app.

Take a look, and if you want to learn more, check out the Tidelift guide to managing open source.

Tidelift partners with GitHub, funds 4,000 open source projects

Donald Fischer — Thu, 23 May 2019 10:51:07 +0000

Today, GitHub announced GitHub Sponsors, a tool to help support open source creators, with Tidelift as a launch partner.

Now over 4,000 open source projects on GitHub are immediately eligible for income from Tidelift through GitHub Sponsors!

GitHub knows it's time to pay the maintainers. We agree wholeheartedly—so we made a short film about it:

Tidelift and GitHub are a natural fit

GitHub is the world's leading software development platform for open source projects.

Tidelift is the world’s leading managed open source provider, working in partnership with independent open source maintainers to solve key security, licensing, and maintenance challenges for organizations that rely on open source.

It’s natural that we would collaborate on this effort.

Open source maintainers can now feature their Tidelift participation natively in GitHub

With the new GitHub Sponsors functionality, open source projects can provide a direct link to their project's page on Tidelift via a new “Sponsor” button next to “Watch” and “Fork."

Open source projects can sign up for Tidelift and add a Sponsor button to their GitHub project today.

For organizations, Tidelift’s managed open source subscription saves time and reduces risk

With the Tidelift managed open source subscription, Tidelift’s network of participating open source maintainers work on your behalf to resolve security, maintenance, and licensing problems in the packages your applications depend on, freeing up your developers’ time while reducing risk.

Tidelift partners with the open source maintainers to "take care of it for you"—to give you ready-to-use, continuously monitored, always cared-for software. Managed open source, rather than open source that needs management.

With support for application development in JavaScript, Python, Ruby, PHP, Java, .NET, and more, the Tidelift Subscription also includes software tools that provide an overview of security vulnerabilities, licensing issues, and technical concerns across dependencies, at-a-glance metrics that help developers gauge how package updates impact their applications, and recommendations on when to upgrade key frameworks and libraries.

This new integration with GitHub makes it easier for your organization to save time and reduce risk with Tidelift's managed open source subscription.

For open source maintainers, Tidelift provides a scalable income solution

Tidelift makes it possible for open source maintainers to provide concrete value to the professional organizations who rely on their software by keeping it actively maintained and secure.

In return, open source maintainers receive a scalable, reliable income stream.

With GitHub’s new underlying platform enhancements, participating maintainers can better integrate the Tidelift Subscription directly into their GitHub project pages.

If you are an open source maintainer, find out if your project is one of the 4,000 projects eligible for immediate income from Tidelift, sign up, and learn how to integrate with GitHub Sponsors.

Tidelift aligns the creators and users of open source, now together with GitHub

Open source software is at the heart of our digital society. Tidelift’s managed open source subscription makes it possible for organizations to ensure the open source components their applications rely on are robust, secure, and well-maintained, while simultaneously creating a scalable income stream for open source maintainers.

We’re excited to work with GitHub to make it even easier for the users and creators of open source to partner constructively with one another via Tidelift, now as part of the native GitHub workflow.

Managed open source

Donald Fischer — Tue, 30 Apr 2019 19:27:11 +0000

Last week I wrote on DEV about about the challenges faced by organizations as they transition from closed source platforms to community-led open source. In this post, I'd like to give a sense for how we're looking to help those organizations manage the transition, via Tidelift.

Nearly all application developers rely heavily on open source code, yet most organizations don’t have a strategy to keep that code secure and well maintained.

What if you could just pay a team of experts to do this for you, like you pay your cloud provider for compute and storage?

Tidelift is partnering with creators and maintainers of a vast array of community-led open source projects to make that possible.

We call it managed open source.

The flexibility of open source with the confidence of commercial-grade software

The best solutions are comprehensive solutions, and we’ve reached a major milestone with the Tidelift Subscription now providing assurances for over 1,000 of the most popular community-led open source projects. That means we’re paying the maintainers of each of those projects to ensure their packages meet uniform commercial standards.

Apache Struts, Joda-Time, Vue, Babel, Material-UI, Gulp, Mongoose, Nokogiri, and hundreds of other community-led projects that are pivotal to commercial application development are now part of the Tidelift Subscription.

And there are more on the way—with over 4,000 projects immediately eligible for income across the JavaScript, Python, PHP, Ruby, Java, and .NET ecosystems. (If you’re an open source maintainer, learn about partnering with Tidelift.)

Even more broadly, the Tidelift Subscription monitors over 3.3 million open source packages across 37 different ecosystems.

To make this actionable for your organization—the managed open source part—we’ve launched new software tools that include an overview of security vulnerabilities, licensing issues, and technical concerns across dependencies, at-a-glance metrics that help developers gauge how package updates impact their applications, and recommendations on when to upgrade key frameworks and libraries.

Those capabilities are all powered by Tidelift’s network of participating open source maintainers, who work to resolve security, maintenance, and licensing problems on your behalf, freeing up your developers’ time.

It comes together in a comprehensive solution

If you want a working operating system, you could go buy a bunch of tools to help you build your own operating system image—or you could let Red Hat or Amazon do that and just subscribe to the result.

With the Tidelift Subscription in place you have what you need to deal with all your package managers, across all important dimensions—security, legal, and technical. We're giving you software tools, yes, but also services—including help directly from upstream projects.

Our goal is to "take care of it for you"—to give you ready-to-use, continuously monitored, always cared-for software. Managed open source, rather than open source that needs management.

Want to see it in action? Visit our web site for a detailed walkthrough of how it all comes together.

The closed source sustainability crisis

Donald Fischer — Thu, 25 Apr 2019 14:34:56 +0000

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

Open source creators: Red Hat got $34 billion and you got $0. Here's why.

Donald Fischer — Wed, 31 Oct 2018 13:41:27 +0000

In the aftermath of IBM’s announced acquisition of Red Hat for $34 billion in the largest software deal ever, countless VC investor, stock analyst, and industry hot takes have hit the interwebs.

None of that "thought leadership" addresses the most salient question to most open source maintainers: Red Hat got paid billions selling what you created, and you got paid jack. 😡

How the hell did that happen?

Prior to co-founding Tidelift, I was the product manager for Red Hat Enterprise Linux during its creation and early years of growth. I’m intimately familiar with why it works for Red Hat, and why it didn’t work for you.

Now it’s time to let you in on the secret, so you can fare better next time around.

What Red Hat knows

Red Hat unbundled the traditional enterprise software business model.

For the first several decades of the commercial software industry, when you bought a commercial software product, say a database from a vendor like Oracle, you got:

(a) a license to copy, install, and run that code

(b) a support and maintenance agreement to ensure you are successful doing so, today and in the future

Red Hat saw, earlier than most, that the ascendance of open source made the need to pay for code go away, but the need for support and maintenance grew larger than ever.

Thus Red Hat was never in the business of selling software, rather it was in the business of addressing the practical challenges that have always come along for the ride with software.

Who’s going to keep that software patched and secure? Red Hat will.

Who provides legal protection and indemnification? 👋 Red Hat.

Who gets all the individual open source components working together, and keeps them working for years to come? Yep, the 🎩 people again.

Red Hat doesn’t sell a work product they created alone (after all, you actually created it, isn’t that how we got here?). They sell promises about the future of a collection of software that someone else wrote, and the solutions (people, process, methodology) that make those promises come true.

Contrary to conventional wisdom that “support doesn’t scale," providing those assurances is a model that scales very well indeed. Red Hat has a gross profit margin of ~85% and an operating margin of ~25% on over $3 billion in annual sales. In other words: they make a lot of money doing this.

How do you get in on that game?

As an open source developer, you created that software. You can keep your package secure, legally documented, and maintained; who could possibly do it better? So why does Red Hat make the fat profits, and not you? 🤔

Unfortunately, doing business with large companies requires a lot of bureaucratic toil. That’s doubly true for organizations that require security, legal, and operational standards for every product they bring in the door.

Working with these organizations requires a sales and marketing team, a customer support organization, a finance back-office, and lots of other “business stuff” in addition to technology. Red Hat has had that stuff, but you haven’t.

And just like you don’t have time to sell to large companies, they don’t have time to buy from you alongside a thousand other open source creators, one at a time.

Sure, big companies know how to install and use your software. (And good news! They already do.)

But they can’t afford to put each of 1100 npm packages through a procurement process that costs $20k per iteration.

Red Hat solved this problem for one corner of open source by collecting 2,000+ open source projects together, adding assurances on top, and selling it as one subscription product.

That worked for them, to the tune of billions.

But did you get paid for your contributions? 😖

We can fix this, together

We think there’s a better way that borrows from Red Hat’s business model, but then takes it to a whole new level. That’s why we created Tidelift.

Here’s our logic:

Companies need assurances around the software they use, open source or otherwise, and they are happy to pay for it
The creators and maintainers of open source are the best suited to provide those assurances for the very software they wrote and maintain
To make it work, companies need a simple way to buy standardized assurances from all the maintainers together, and maintainers need a shared "business stuff" service

Tidelift opens up the system and levels the playing field, so that as a maintainer you can provide the same kinds of assurances that Red Hat provided, but for your own package.

With Tidelift, open source teams create their own solution—security, licensing, and maintenance for their package—alongside many other open source packages in an easy-to-consume bundle that companies can constructively engage with. Subscribers get their problems solved, not for a little corner of open source, but for all of it. And the maintainers who create the software they use? They get paid, starting with over $1m already committed. Win-win.

Now that you know, next time you can get paid, too.

Meanwhile, to our friends at Red Hat: do not go gentle into that good night. ❤️

$1m to pay open source maintainers on Tidelift

Donald Fischer — Tue, 18 Sep 2018 14:59:10 +0000

Open source can be puzzling. It's now widely accepted that open source software is everywhere. Yet almost every day there is a new passionate debate around how to align the interests of open source creators and users. How can we ensure that the open source software we rely on continues to get even more awesome and more dependable?

At Tidelift, we believe the solution is hiding in plain sight: pay the maintainers.

We’re dedicated to creating an effective way to do just that, and today we’re announcing a major milestone on our journey, as we pass $1 million committed to pay open source creators on Tidelift.

An open source business plan that lifts all boats

With the Tidelift Subscription, we make it easy for professional software teams to get one-stop shopping for security, licensing, and maintenance assurances for the wide variety of open source software they use. And from our research and our conversations with professional developers, we know that these assurances are in high demand.

Think of the Tidelift Subscription like a Red Hat or Cloudera subscription, but for all of the other open source libraries you build into your applications from package managers like npm, Maven, PyPI, Packagist, and RubyGems. And with the proceeds flowing through to the actual open source maintainers behind that software.

Tidelift makes it possible for open source creators to get paid by adding net-new valuable assurances around their software. We add something useful that professional development teams want, rather than hiding existing and future capabilities away behind paywalls or curtailing your ability to use the software freely. Our model grows maintainer income as projects have more users, rather than as maintainers spend more hours, so it’s possible to build a significant income around your open source project.

This is a business model innovation, and it’s great for a couple of reasons:

It’s pragmatic. Open source is still software. It needs maintenance to keep it functional and secure. That's real work, and if there are no incentives, it just doesn't happen. (👂did someone say Equifax?)
It's just. These individuals and teams are creating amazing value, and deserve to be supported and rewarded for doing so.

We’ve been gratified to work with leading projects such as Vue, Material-UI, Babel, Gulp, Fabric, Active Admin, Doctrine, and StandardJS over the past several months to prove out this model.

TLDR: It just makes sense, and it's working.

$1 million for open source creators

Today we’re excited to announce that we’ve reached a significant milestone, with over $1 million in committed payments for maintainers via the Tidelift platform.

We're also opening the doors for any open source project to register to participate in Tidelift.

What does this mean for open source maintainers?

We’re offering a guaranteed minimum $10,000 over the next 24 months to select projects. See if your project is eligible.
Any open source project can sign up. You can register today to start encouraging your users to participate as subscribers, and start receiving subscription revenue for your project as it is available. Sign up.

Now it’s your turn

Working on Tidelift is a joy. Together, we are solving acute problems faced by professional software teams who build on open source software, and in so doing we are rewarding the maintainers of that software and supporting their work.

You can play a part, today!

If your organization builds software applications using open source components (hint: 92% do), then learn more about how the maintainers behind the Tidelift Subscription can keep your software secure, legally compliant, and maintained.
If you contribute to an open source project, learn more about how you can get paid for doing the work you love.

Whether you are a professional team building with open source or an open source creator, we invite you to join us in advancing this win-win approach to making open source better—for everyone.