Recently, Tidelift co-founder and CEO Donald Fischer sat down with host of the Fintech Open Source Foundation (FINOS) Open Source in Finance podcast, Aaron “Grizz” Griswold, to share his personal journey of how he came into open source and its endless possibilities in the nineties, how these experiences informed the inception of Tidelift, and provide his take on popular open source analogies. Below, we’re sharing our picks for can’t-miss-quotes—you can listen to the podcast episode in its entirety on the FINOS Open Source in Finance blog. 

Programing roots

Many interviews start with “tell us about yourself,” and this interview was no different. Donald brought it back to the nineties to share what drew him to open source in the first place:

“I started building in the late nineties, and one of the things I got really interested in early in my journey was the free software movement and the community around that—what predated modern open source and what it has become. I was fascinated by what it allowed me to do in terms of having access to things I wouldn't be able to get my hands on. It was hard to get a Solaris system in those days, but it was easy for me to run Linux on my laptop. 

Then, as I went deeper into that rabbit hole, I started getting fascinated about things like, how is this possible? Where's this coming from? Who are these people? Somebody is making all this open source software. How is that happening? What are their incentives? And this is awesome. So how can we amp it up and make this even better? And that's basically been my sole focus for the last two decades of my career—figuring out how to amplify that organic energy in creative communities of smart and energized people around technology, specifically free software and open source communities.”

Creating Tidelift and paying open source maintainers

Open source is incredible and throughout the podcast, Donald praised its innovation, its sense of community, and its root in personal philosophies. When asked what he thinks of companies profiting from open source he explained that he’s happy that open source adoption has come this far, but the current system is unsustainable. We need companies to participate in open source, to stop counting on someone else to step in and help open source maintainers. In search of a solution, Donald co-created one: Tidelift. Tidelift’s goal from the start has been simple: fund the work of the developers who are working on these open source projects. 

“If you wander into any organization building using software at scale, you'll find there are 10,000 open source packages making up an application’s building blocks. The vast majority of the software at this tier is coming from individual, human maintainers. The thing that is generally true for the vast majority of these projects, even the ones that are relied on by the financial services industry, is that the folks who are maintaining these projects, and very often the creators of those packages, are not receiving an income. They're not, and it is not their job—they often have a job doing something else.

Some folks are in a privileged position where they can dedicate a lot of time and energy to very actively maintaining and securing their open source projects. Other folks have to balance their time, they have to balance their energy and they don't have the luxury to spend huge amounts of time on their projects. The idea that we had with Tidelift is: how can we draw inspiration from some of the things that have worked, and adapt that model to fit this space?

The application development community isn’t looking for a long term supported stable release of all of these packages— the scale of it is just too immense to do that. But they are looking for packages to follow secure software development practices. They want these projects to be actively maintained. If they're not going to be actively maintained, they at least want to know what the end of life is. Fundamental things that you would demand of any software company that was selling you a product.

So our very simple idea was the software is coming from somewhere; there's humans out there somewhere. Maybe we can go to those humans and say, thank you for creating this project and putting it out there. We appreciate this, but we want to ask you to do more, and specifically what we want to ask you to do is go through this checklist of secure development practices, et cetera. Attest to it. We want to encourage you to do these things and we want to recognize your work. We’re acknowledging that it's boring, but important work—we'll pay you to do it. 

Basically, we built a platform for individual, independent open source maintainers to go into business earning an income doing these things for the open source projects that they set into motion or have been maintaining.”

The xz hack and the reality of vulnerabilities

Maintainer burnout, lack of funding and support, and a growing pressure to adhere to unfunded standards are some of the biggest threats to open source software security. Without the necessary time and resources, packages can go unchecked and eventually unmaintained. An unmaintained package is a vulnerable package, and this glaring hole in the open source supply chain is a beacon for bad actors. The most recent newsworthy vulnerability is none other than the xz utils backdoor hack, which Donald explained in more detail:

“The xz project is not just proving that point [that open source maintainers are burnt out] but it’s actually taking this hazard to a whole new level. So many of the past ‘large spectacle’ open source software supply chain disruptions have been human errors or mistakes that were exploited by adversaries, but what happened with the xz event was an attack on an independent open source maintainer of a critical, but under the radar, open source package—they were explicitly targeted because they were volunteers struggling to keep up. Most folks are saying this looks like a foreign state actor given the level of sophistication, the duration of the campaign. 

If you look back at the original sequence of events, I think this goes back to 2021, when the adversaries started participating, the maintainer said, ‘I haven't lost interest in the project, but my ability to care has been fairly limited. It's good to keep in mind that this is an unpaid hobby project.’ These are the actual words of the maintainer. Then you have the sock puppet account joining and the maintainer says, Jia Tan (the hacker’s alias) may have a bigger role in the project in the future: ‘He has been helping a lot off-list and is practically a co maintainer already.’

Years go by and this thing unfolds. This gets to the fundamental issue, which is: if this stuff is going to be our critical infrastructure, we have to make sure that the folks behind this, those who have the ability to secure these projects and to maintain these projects, we have to make sure we meet them halfway and they are provided reasonable incentives. There's an extreme business impact and organizational impact if we don't partner with our suppliers here. As we do in every other supply chain known to humanity, we need to have a constructive partnership.”

Elevating the spoiled food analogy

The open source software space has been dominated by open source scanning tools that reactively point out vulnerabilities in the open source in use at one’s organization. It’s a recommended strategy to help clean up previously found vulnerabilities, or to help flag when vulnerabilities hit the scene (or more specifically, when they’re found). There’s a common food analogy regarding tackling vulnerabilities and likening it to cleaning out spoiled food, but what if organizations didn’t take in vulnerabilities in the first place? What if, instead, fresh organic food filled the fridge and people could spend less time checking for rot and more time finding more foods with better-for-you ingredients? Donald expanded on this analogy: 

“We'll get the best outcomes if we aim higher than ‘not toxic,’ and instead aim for well-secured and actively maintained. Security vulnerability framing of the problem has this limited focus because it's only based on a list of known defects. We're trying to offer models and approaches that work with maintainers. Let's identify open source projects and releases of those projects that have been vetted to be good, not just ‘not bad.’

We can have an incentive in place to continue to have those projects well-supported, and there can be a defined security response process in place for things that may come in the future. It's all about advancing beyond the reactive approach of avoiding toxicity, which again is a good idea to do as a starting point, but we should then go onto the next level, asking ourselves, how can we actually build proactive health and resilience into the software that we use? 

The really cool thing that we've found in building Tidelift is that this is a situation where everybody can win—the organizations that need the software to meet these standards need this kind of visibility. It's important to their business outcomes to know this and to act on this. It's worth them paying for this and paying the open source maintainers who can make it happen. It's valuable for them to derive an income from their work on these enterprise assurances for the software that they otherwise are doing as a hobby.”

Upstream and a closing parable

“At Tidelift we convene a community online event every year with the goal of basically intersecting organizations, such as FINOS member organizations, who rely on open source creators with the maintainers that we work with. The event is called Upstream, and the reason why it's called that is because it has a dual goal. Upstream is a term of art in open source software communities. It's the independent developers who work on the project, the folks upstream from you. But there's also a public health use of the terminology upstream. And one of the ways that I've heard it verbalized was with a parable of two people on the side of a river, literally a stream.

They see a kid floating down in the river, struggling and one of them jumps in, grabs the kid, drags him to the shore. Two more kids come floating down the river struggling—he jumps in, grabs them both, and brings them back to the shore. Three more kids come floating down the river…The other companion takes off and the guy in the river says, where are you going? We have to help save all these kids struggling and floating down the river. His companion says, I'm going upstream to figure out who's thrown all these kids in the river.

Let's solve the problem at its source rather than constantly playing whack a mole. 

One of the reasons why I've gotten involved in FINOS is that I think it's the same spirit. In the context of the financial services industry, a similar spirit of, ‘let's work together to get after some of the fundamental challenges that organizations face when they are availing themselves of this amazing abundance of creativity.’

And we can't do it blindly. We also have to be practical and come up with ways to make sure that this resource that we're relying on and depending on is well cared for and maintained, and continue to reinvest in it.”

— — — — — — — —

These are only some of the highlights—you can hear from Donald and host Aaron on the FINOS Open Source in Finance podcast website. Additionally, you can read more about FINOS and why Tidelift joined FINOS on the Tidelift blog. 

Want to learn more about Upstream? RSVP for the virtual, annual celebration of open source today—we hope to see you Wednesday, June 5th!