The Changelog: Software Development, Open Source - Tidelift's mission is to pay open source maintainers (Interview)

Episode Date: November 21, 2018

In this special crossover episode of Founders Talk, Adam talks with Donald Fischer. Donald Fischer and the team at Tidelift are on a mission of making open source work better — for everyone. To pay the maintainers of open source software they are putting a new spin on a highly successful business model that’s a win-win for the maintainers as well as the software teams using the software. In this episode we dig into that backstory and Donald’s journey.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at rollbar.com and we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by our friends at Rollbar. Check them out at rollbar.com slash changelog. Move fast and fix things like we do here at Changelog. Catch your errors before your users do with Rollbar.com slash changelog. Move fast and fix things like we do here at Changelog. Catch your errors before your users do with Rollbar. If you're not using Rollbar yet or you haven't tried it yet, they have a special offer for you. Go to Rollbar.com slash changelog. Sign up and integrate Rollbar to get $100 to donate to open source projects via Open Collective.

Once again, Rollbar.com slash changelog. Founders Talk. Adam talks with CEO and co-founder of Tidelift, Donald Fisher. They take a deep dive into the backstory of the company and Donald's personal journey. Without further ado, here's the show. From ChangeLog Media, this is Founders Talk, one-on-one conversations with founders, CEOs, and makers about their journey, lessons learned, and the struggles they go through to build and run their business. I'm Adam Stachowiak, host of this show and editor-in-chief of changelog.com. What's it like to be on a mission of making open source software better for everyone? Donald Fisher is one of four co-founders and the CEO of Tidelift. Their mission?

To pay the maintainers. To pay the maintainers of open source software and provide a new spin on a highly successful business model. That's a win-win for the maintainers, as well as the software teams using the software. So I asked Donald, what's it like to be on this mission? It's amazing actually to be on that mission, you know, and it's sort of naturally is an outgrowth of everything I've been working on for the last 15 going on 20 years, actually. You know, I've built my career in and around open source in a couple of different ways. And so, you know, when we saw this opportunity to sort of contribute something new to the equation with Tidelift, we decided we had to go for it because we saw the opportunity to create a new kind of win-win scenario for all kinds of different stakeholders in and around open source. I want to go back into

your past and figure out what got you here. What makes you and the rest of the team at Tidelift, the team that can make this happen? Help me understand more about you and Tidelift and what you're doing. We're building a methodology with software and a set of practices to help professional software teams make better use of open source software. And the way that we do that is by helping to address a bunch of pragmatic concerns that professional software teams have with the software that they use. And that's in areas like security, licensing and legal issues, just everyday ongoing maintenance. And the way that we address those problems is really what's new with Tidelift. We do it by partnering with the individual open source maintainers and teams of maintainers who work on open source projects.

And we kind of ask them to provide these professional grade assurances for their individual open source projects or components. And then what Tidelift does is we basically join those together and we represent them to these professional software teams as a whole product. And in so doing, we essentially address two different challenges. One is that professional software teams, they need support and they need maintenance for the software that they use, whether it's open source or not. And on the other side, it creates this economic opportunity for open source maintainers to do something that's very closely related to the just ongoing development of their software and something that they're best equipped and best situated in the world to do. But now for the first time for many of them, they can do that in a context where there's an income associated with it, an income that scales. Right. To kind of give some, maybe I'm speaking for you in some sense to help me course correct what I'm saying and make sure it's accurate, is you did a lot of interesting things at Red Hat.

There's a lot of things you and some of your team members have learned from the experiences at Red Hat. And obviously Red Hat is one of the, I think one of the most successful with like supporting paid versions of open source and support and things like that. Are you bringing a lot of what you're doing now from your experiences with that? Is that safe to say?

Yeah, I mean, definitely. You know, I had the privilege of being part of the early development of Enterprise Linux at Red Hat and all three of my co-founders also had tours at Red Hat around the same time. We all knew each other back then and worked together and have stayed in touch since then. But honestly, this is also what we're doing now is also informed by an awful lot of other experiences in other open source communities and commercial ventures around open source communities. It's not just a Red Hat copycat. It's actually, I think, if you want to put in reference to Red Hat, it's almost a generalization or an evolution of the Red Hat business model.

Yeah, well, their focus was one single open source project and one right way to scale it to enterprises and support and all the things that everyone's aware that Red Hat does. You're doing it at scale across open source. How do you make the decisions then to choose which projects to work with? How do you determine what matters? Do you go to the community and say, hey, which maintainers should we work with? Or do you go to the maintainers and say, which maintainers of, and maybe you're even agnostic, like not just JavaScript, not just Go,

not just Rust or other languages. How do you even choose where to place your focus? Yeah, so ultimately, remember that the way that we frame our solution is that we're solving real world problems for professional software development teams who are already building with open source components, but don't have the kinds of safety net assurances that they would expect traditionally from, you know, enterprise software vendors. So to your question of how do we choose which open source projects and maintainers to engage with, actually our subscribers choose, the customers of the Tidelift platform, they essentially direct us towards the maintainers

who are best suited to participate in Tidelift. And there's a mechanism for doing that, whereby we've built a software platform that attaches to the software development process at our customers, sort of integrates with their code collaboration platform, sort of in a similar way to how a continuous integration system would connect. And we look at the open source components that our subscribers are using in their projects,

in their applications. And then we go and recruit the open source maintainers of those projects to provide professional assurances around them. Yeah. Right. So it's like, we just kind of follow where our customer are voting with their feet, so to speak. And potentially their money too, since it's a subscription, I'm assuming that there's the word alone elicits that there's some sort of recurring payment into some sort of system. It's monthly, yearly, biannually, whatever it might be. Some sort of commitment on the long-term or some sort of term that says, you know, we want to use,

you know, enterprise level type software that's open source, that includes support and includes SLAs or whatever they may be needing on a certain duration. And their vote is essentially participating in that subscription, but then saying, hey, this is the software we're using. Can you go out and establish these relationships with those maintainers? Is that how it works? Yeah, exactly. So in other words, a customer of ours will subscribe to Tidelift for one of the applications that they're building, connect to our software infrastructure. Now we have a lens into what are the actual open source components that they're using. And by the way,

yeah, I was about to say not just the top level components, but we look at the transitive dependencies as well. All of the packages that those depend on. Yeah, we build the tree, right? And then the way that we've packaged it is we charge the subscriber a fixed cost for the, all of the packages in the tide lift subscription it's sort of like a netflix subscription in that way where uh netflix might not have every movie that you want to watch but if it has a lot of movies the kinds of movies that you like it's going to be interesting for you to be a subscriber right there's always more movies kind of joining joining the catalog right so um so we sort of simplify it by charging one blanket subscription price. And then we look at the, and we bill the subscribers on a monthly basis for that.

And then at the end of the month, we take each subscriber's payments for that month, and we split them up and allocate them specifically to the participating maintainers of the packages that they use. So a subscriber's dollars only ever get directed to the participating maintainers for the actual packages that that subscriber is using. And that's one of the ways that we align the interests up and down the system. And if there's not a participating maintainer for a particular package that the subscriber is using, we sort of note and increase the potential payment that

would be available for a new maintainer who showed up and agreed to participate in the Tidelift system. So we sort of create an incentive for somebody to, we signal the funded incentive for somebody to come along and take us up on, you know, following through on those maintenance tasks around that particular package. So if I'm a maintainer does, and I'm participating, does my, you know, in quotes, income or revenue generator from this, this style of, of funding for my project or my teams, does that number coming from Tidalift, does it ebb and flow then because of that? Or is there some sort of like barrier or some sort of predictability they can have into, you know, how they can begin to, you know, step away from their full-time job or do this full

time or whatever it might be, you know, how do they understand the income that's possible? And even not just possible, but like on a day-to-day or month-to-month basis, how does it ebb and flow? So this is actually like one of the fundamental reasons why we started the company. And one of the fundamental contributions that we want to make is that it's really hard to dedicate your efforts on an ongoing basis to an open source project if you're not sure what you're going to be paid tomorrow, or especially if your income is kind of swinging erratically in terms of what you're receiving related to your open source project. So our goal, in other words, is to make it a lot more predictable month to month. Now, it doesn't mean that your income could never, ever go down in the Tidelift system. You know,

as I said, we pay the maintainers based on subscribers using their software. So if, you know, all of a sudden, none of our subscribers are using that software anymore, you know, the amount could go down. But in reality, once software is in place, it tends not to go anywhere, right? Just new software gets added. And on the other hand, like, we're growing quickly, the audience of participating subscribers. So the total dollars in and the number of potential professional teams that open source maintainers will see much greater predictability and have sort of a steadier income to depend on, which is in contrast to some of the other existing models for funding open source projects that might be more episodic if they're

based on grant funding or, you know, sort of bounty kind of mechanisms. Actually, I think all of those systems are great and anything that is funding open source is laudable and awesome. But we just saw an interesting opportunity to contribute another model that's additive and incremental on top of those. What do we want a little bit back to the dependency tree that you mentioned

just for those listening who may not be like intimately familiar with how software works, which leads into one of your acquisitions and you can speak to that if you'd like to. But this kind of helps you get a lens into like the dependencies of dependencies.

So when you have an open source project or just a project in general, and you've got a project, an application you're building, you know, when you use Vue, for example, on the front end, well, Vue has so many layers of dependencies beneath it

that whenever you, as you mentioned, come into the platform, you're scanning the dependencies and probably points out some opportunities for you to grow as you mentioned you are. But I kind of want to touch on that a little bit because not everybody listening to this is like that familiar with the software process and what dependency trees actually are, you know, how deep they might go as dependencies of dependencies. Vue has tons of different things it relies upon.

And all those things tend to be other open source projects that are probably not receiving funding or really have any sustainable model behind it, aside from maybe side work, which is fine. That's open source. But we're looking for ways to make it enterprise level and enterprise grade. I'm assuming. Is that right? Yeah, that's right. I mean, this, the issue of the lack of appreciation or really understanding, I guess is what I mean of how much

software exists below the visible waterline is really remarkable, right? So, you know, for example, we recently wrote on our blog about look at React, you know, super popular web front app tool, you'll end up with a sort of Hello World web app based on React. And that thing by default will have 1,103 dependencies as of the last time that we looked. So that's over 1,100 distinct packages coming out of the NPM JavaScript package catalog. And those are coming from a lot of different places. A couple dozen of those are coming from, you know, being authored by the Facebook React engineering team. But, you know, kind of the beauty of open source software is that the vast majority of those are sort of coming from somewhere else, from somebody else, but all of them are getting built into your React application, right? So if you're a

professional software team at, you know, large enterprise that has, you know, a bunch of goals around security and compliance or needs, requirements, things that you need to comply with, it raises a lot of questions about who's on the hook to support all that stuff and why would they be on the hook? To which our answer is the best reason for them to be on the hook or a great reason, a great additional reason for them to be on the hook is that they're getting paid to do the work to make those things true about those open source components. And that's really the meat of what we're trying to do. An example that I'm not sure if you're familiar with Nadia or not, but Nadia Ekbal, when we first learned about her was several years back.

And we've since done a podcast with her called Request for Commits. I can link that up in the show notes if you want to check it out as a listener. I'm a long-time fan of Nadia's and the show. So yeah, I recommend it to all of your listeners who have not yet explored those paths. And it is retired. So when you go listen, just know that and send us your hate mail.

We want to hear more of it because we want to do more around sustainability of open source, but that show just is in a retired state for for its own reasons but uh the last episode does tell you why so if you're really curious just listen to the latest episode but you know she'd she'd written about you know the economics of open source and the the example she used was the rate at which instagram was able to become a billion dollar company and then be acquired by Facebook in a century.

But don't mean to keep going back to the Facebook. Well, it just happens to be that example. But, you know, Instagram was built on open source software. Now, I'm not that intimate with the details of what they've given back to open source. I do know what Facebook's involvement is, and they've since acquired Instagram. But that was always the that was the initial yardstick, at least by Nadia on like, you know, Instagram was worth, what was it? The acquisition was like 4 billion. Was it 1 billion, 4 billion? I can't recall right now. It was like $4 billion from Facebook. So somehow they got to that value and they were built upon open source software. And so go back to your model

is that we have this economic need of all these dependencies and they wouldn't have never been able to get there building all the technology on their own. They had to lean on open source. And so there's a responsibility there to support the dependencies beneath the tree. Yeah. I mean, there's a couple of different ways to look at it. I think, honestly, I mean, there's one lens of looking at it is to say, if you're building on all of this software, you know, you owe it to the creators to allow them to drive some participation in the value that they're creating. First of all, I agree with that. I think that's that's a very reasonable worldview. But it's hard to get large organizations to open up their checkbooks for things that would sort of, you know, are morally, purely morally justified. So one of the things that we're bringing to the table with our model is we're just

inviting professional software teams to act out of their explicit self-interest. And we're helping open source maintainers create a new service offering that didn't exist before that we're seeing is very appealing to a lot of the professional software teams who are using their software. And again, the specific service that we're helping put together is a community of maintainers who are proactively committed to maintaining the individual open source packages to a well-defined standard. And then Titleift's role in that is to sort of be the intermediating agent that helps all of those individual open source maintainers and teams connect to a particular professional software team in an organization. We're not asking people to buy

a title of subscription mainly because it's a morally correct thing to pay the maintainers. We're inviting people to buy a subscription because it's in your best interest to pay the maintainers. When you pay the maintainers. When you pay the maintainers, the software that you're using is better and more reliable. And we're adding some business process and technology to the mix that helps you kind of define what is meant by more well-maintained and reliable and sort of gets everybody on a common shared mission. This episode is brought to you by Linode, our cloud server of choice. It's so easy to get started. Head to linode.com slash changelog.

Pick a plan, pick a distro, and pick a location, and in minutes, deploy your Linode cloud server. They have drool-worthy hardware, native SSD cloud storage, 40 gigabit network, Intel E5 processors, simple, easy control panel, 99.9% uptime guarantee. We are never down. 24-7 customer support, 10 data centers, 3 regions, anywhere in the world they got you covered. Head to leno.com slash changelog to get $20 in hosting credit. That's 4 months free. Once again, leno.com slash changelog. So when you say professional software teams, I think I know what you mean when you say that,

but put it in layman's terms for me and the listeners, what is a professional software team as it relates to what you're doing with Tidelift? So when we say professional software team, we're typically referring to a team building software within an enterprise. That enterprise is kind of a silly, you know, IT word or entrepreneurship business word. It means a company and, you know, oftentimes like a larger company. So look, I've again, I've spent the last 20 years in and around open source. So I know one of the beautiful things about open source is that it's accessible to all different kinds of audiences. Right. If you're an indie developer, I mean, I started working with open

source, getting involved in open source when I was a student. You know, there's individual entrepreneurs kind of picking up raw open source and building with it. It's awesome. It's part of the beauty of the whole thing. There's also big teams inside a, you know, megacorps that are building with open source as well. And those different audiences have different needs in and around the software that they're using, right? When I'm doing a, you know, side project on the weekend, kind of, you know, cobbling together some, you know, open source components to sort of scratch my own itch, for sure, I do not need an enterprise support contract. You know, I'm not super focused on intellectual property documentation for this

thing that's only ever going to live on my laptop and never go anywhere. But when you have a team at a financial services company or a healthcare company or an industrial company, and they're building the core software that powers those businesses. And in 2018, for sure, they are building that with open source software. They need to have or they would love to have some additional guarantees around that software. So the open source license, you know, by the open source definition, gives them a bunch of capabilities right off the bat for software that's under an open source license. They can access the source code, they can change it, you know, as long as they adhere with the different requirements for what they need to do if they

redistribute it. But the open source license doesn't give you somebody who's on the hook to make sure that security vulnerabilities that arise will be dealt with in a timely way. It doesn't give you any certification around the licensing of all the components of the software that you find that are connected to that or that are dependencies of that. And it doesn't give you any kinds of assurances about what's going to happen with the software in the future? Is somebody going to keep caring for it and taking care of this essentially living organism that these software projects need to be as the world evolves over time? So those are the things that we think that professional teams need, that not all open source developers need, but professional teams, they do need it. And as a result, they're willing to pay for it. And one of the things we've done in the Tidelift context is verify that by talking to a lot of those organizations, surveying a bunch of those organizations, we shared the results of a

broad survey we did this year that said something like more than 80% of professional software teams were very interested in paying for those kinds of assurances around the open source software that they use. Another aspect to the professional software teams I thought you used in this context was describing the teams creating the software, meaning the open source software. Did you use it in that context as well? Like when you're identifying who to work with? No, the way that I've been using the terminology professional software team, I've been focusing more on the subscriber side in our terminology or the consumers of open source software. I actually think there is like a really compelling opportunity on the creative side of open source to also, in a sense, professionalize there. And I want to be careful about what I mean by that word professionalized.

So open source maintainers, whether they're paid or not, you know, it is demonstrably true that they create amazing software that is pro-grade, is used in, you know, real world applications all over the place. I guess a missing part of the professional definition there is that oftentimes they don't get paid for the work that they do. So it's hard for it to be a profession for the individual open source maintainer, right? So I do think there's a double entendre there you could look at, which is we would love to help open source maintainers make it their profession, you know, and that's really one of our ambitions with Tidelift is to enable more open source creators to dedicate more of their time to their open source projects, innovating the features and

functionality there, also just like doing the everyday kind of maintaining it tasks. And if we give them, if we, all of the users of open source, give them the license to do that and the necessary financial incentives to do that, then we're going to benefit because the software that we all use is going to be better. It's awesome. Yeah. And the reason why I asked you that question in the opening was I'd heard you use it. And I thought that your reference was essentially helping to understand the type of maintainers or type of teams that maintain software.

Describe them. That's how I thought you were using that content, which is why I opened up with that question. Because I wanted to understand more so like when you focus your attention on, you know, I know that a lot of your subscribers are the ones that are, you know, leading you to the down the dependency tree, which matters to them because they're paying for the subscription. And, you know, essentially that you said they're leading with their feet, that it would describe the kind of teams that are good candidates to be a part of this because they can provide the support. They can provide the other assurances that enterprise teams need to rely on open source. Like you said, in 2018, it's pretty difficult to build software today in any real capacity without using open source.

So we have to find ways to support it. And I asked that question to think that maybe you were describing a type of maintainer, a type of maintaining team, the way their philosophy, the way they organize, the way they've governed, what are healthy balances in there. So I was hoping, I thought that's what you're talking about. That's why I went into that direction.

Yeah, so just to comment on one really fun part of what you just, uh, just, uh, we're, we're, we're touching on there. I think the really happy news, uh, here is that teams inside of, you know, larger enterprises that have, um, the requirements for, you know, security licensing, maintenance kinds of assurances around the software that they use. Turns out the software projects that they're picking to build their, you know, new applications out of the software components that they're taking out of the package managers, they're the same ones everyone else is using, right? Those are the same. They're using the same components at big bank that I'm using to do my weekend project. Right.

So it's actually a really nice situation where if those professional teams are interested in paying for these additional assurances, the creators of those, you know, open source projects and technologies can access that income that's associated with that. It gives them the license to spend more time on the projects that they're creating. And then the, you know, improvements or, you know, increases in functionality that can be shared by everybody, the payers and the non-payers. And that's actually one of the beautiful things about open source, right? That's the, that's why I love your name, Tide Lift. Like that's, that's the underlying to keep the puns going current

of what you're doing here is like, you know, you enable subscribers to lift the tide of everyone. Like you said, I could be using, you know, whatever the library may be that's, that's part of the lififter project you have going on and which we'll dig into more. If I'm paying and they're getting supported, then I'm just enabling others to benefit from my, you know, subscription and then therefore funding of those maintainers and those projects. I love the name. It's like spot on. So, you know, so we spent the better part of maybe 40 ish minutes kind of digging into the context.

So I want to go into more of the getting started, where the idea came from, kind of some of the background even, which is sort of like the crux of what this show is really about. We've kind of gone into, which I love doing in a deeper explanation of what Tidelift is and what you're doing there for the better part of 40 minutes. Let's kind of rewind a little bit and just sort of get a picture of, you know, some of your personal experiences and maybe the experiences of other team members. But maybe let's start off with, you know, like back in 2017, when this began, you were, what I understand is you were in venture capital, you stepped away, you had this idea. I believe this began with a fundraising round. I'm not really sure. Can you kind of go back to those details and help pave the way for how this got started? You know, my personal history briefly is, you know, I started out as a programmer.

You study computer science. As we talked about before, I had a really interesting tour at Red Hat in the, starting in the early 2000s, you know, and was able to be part of the team participating in building the Red Hat Enterprise Linux business there, which is really an amazing thing that is, I think, often underappreciated in the IT industry. I mean, Red Hat Enterprise Linux, Red Hat as a whole is, you know, an over $3 billion recurring revenue business now. It's, it's, it's really, it's really a beautiful and amazing thing. And there's a lot to be learned. Yeah, over $3 billion a year in revenue.

Just to, just to make you say it twice, that's pretty big. Yeah, it's big. And, you know, it just steadily grows, right? So it's, it was an amazing, you know, time when, you know, I did not figure this stuff out myself, by the way, but as a team and as an organization, we learned a lot of things about what, again, professional software teams that are using open source really need that doesn't just come for free. And we figured out a model that was appropriate for those set of technologies at that time and has continued to evolve to support a steady business today. So then what I did after Red Hat is I spent almost a decade as a investor working with

early stage founders who were starting and growing businesses around open source communities. And I chose to focus on that theme because I've personally just always been fascinated and sort of in awe of how open source communities arise, this phenomenon where, you know, a technology will come from, you know, a creator or a small band of creators. And then, you know, a crowd of individuals will start to kind of assemble itself around that technology. And then, you know, people sort of, you see, um, technologists sort of form these tribes. And when I say tribe, I mean, in a good way, not in, not in a, uh, you know, tribalism kind of way, but in a, a sort of, um, you know, collective, collective way. Yeah. I mean, it's, it's really amazing. And, and when people, you know, you might join the Python tribe

or the, the Ruby tribe, or maybe it, or maybe it's not a programming language. Maybe it's the deep learning tribe or something like that. But it starts to become part of individual people's personal identity, their professional identity. It's really like a powerful thing. And so what's always fascinated me is, you know, if there's this fundamental energy around, you know, people, technologists sort of assembling themselves in these tribes, there's so much power to it. What are the opportunities to add a commercial component there?

And the thing that I've always really focused on is not just how do you go kind of harvest that energy from the community, which I think is a very pessimistic way to view the world, but can you build a complementary business that sort of amplifies the energy in one of those communities that helps, you know, capture more resources to invest more aggressively into developing the technologies or advocating, evangelizing the technology? How can you build businesses that sort of amplify those communities and make them even more successful and make the individuals within them more successful. So I think there's a, there's a really, you know, a fortunate history of, um, you know, startups and, uh, um, uh, you know, businesses of different scale, uh, being built, uh, uh, over the last 15 years now, um, that do

that. Um, and, uh, you know, that's just been a phenomenon that I've loved to follow and sometimes to be part of. I think the important thing to draw from this is that it seems to me that you spend a lot of your life trying to find ways to support open source. And it's either helping certain types of businesses build themselves around open source through venture capital and investing. And I'm sure in a lot of ways, leading product, because that's also part of the investor role is to be somebody who is an advisor to the direction of a business and the viability. I think the other important thing you said there was that you're the support rather than, I forget what the exact language was that you use, but essentially, you're there to amplify

versus to draw and take away from the energy or what was the word you used to, of how you're not attaching to the community? I think the language that I use was instead of trying to, you know, sort of harvest energy from these communities. It's like, can you actually build an engine that contributes net energy back to the community, right? That helps it grow and become more sustainable as opposed to sort of, you know, drawing energy off of it. Those are the really powerful, you know, companies. And also, I think they help to form really powerful communities, right? Like if you look at the different businesses that have been built around Linux or, you know, different big data technologies or, you know, core, you know, systems level databases and things like that. If you can get

a community going that has complementary and additive businesses, that's a beautiful thing. And so, you know, to kind of connect that to the story of Tidelift, you know, I've been a student of that phenomenon for a long time now. And I've, you know, had the great opportunity to work with a number of other folks who are also, you know, fascinated by the same kinds of dynamics. And so, you know, one of the things that annoyed me about the existing models for commercializing open source or building these complementary businesses around open source is that, you know, if you look at something like the venture capital model, where I was personally quite active, there's only a relatively small number of open source projects or communities or tribes, if you will, that have enough scale to them for the traditional venture capital model to work. There definitely are some. At this point, there's several dozen substantial venture capital-backed companies that have been formed,

are performing, several have gone public. It is a model that works, but it only works for a really pretty small subset of open source in general. And one of the really interesting things to me is that it only works for a subset of the commercially relevant open source projects. So I would often, as a venture capital investor, meet with entrepreneurs, open source creators who had projects. They had lots of real world professional users. Oftentimes, the users that they had were asking them for, hey, can I get a support contract for this or a service level agreement for it. And yet, they didn't really fit the

venture capital model of going and raising X million dollars and then building a company from scratch with all that that entails. Building a sales force, a finance function, a way to handle subscriptions, a support, level one support team, and so on. So, when I started talking to my co-founders, the gentleman who eventually became my co-founders at Tidelift, we looked at that problem, that opportunity. And we said, essentially, what if we build that go-to-market mechanism, like the sales and support and finance, back office kind of stuff? What if we just kind of build that once instead of asking every open source project

to do it themselves and then just let the open source projects and teams plug into it, right? Sort of like in the way that creators plug into Etsy. You know, one of the beautiful things about these marketplace models is, you know, if you're amazing at creating some, you know, craft good, you can go to Etsy. Etsy helps you access an audience of people who are interested

in your kind of thing. They handle all the payments and logistics and customer service issues and so on. And you don't have to go learn how to do all of those things. You know, Etsy is kind of your partner for doing that. You get to focus on conducting your craft. And so, you know, that's kind of one of the things that we're trying to do with Tidelift. We want to make it possible for open source teams who are building technologies that are used by these, you know, professional organizations to be able to access some of that potential energy and income that can be associated with that without having to go become salespeople or customer support people themselves.

We'll kind of do that with you and in a sense, do that for you as the open source creator. You kind of plug into our infrastructure and you focus on making the open source project amazing. We'll help with a bunch of the business stuff. These teams generally would still have to be the ones providing the service level agreement, right? Like you may, if I understand correctly, you may institute it and do the business level side of things to ensure that there are subscribers to, you know, that have desires to bring on certain lifters or whatever, but it's still the lifters job, which is a term we haven't

defined it. So, you know, maybe as part of your response, help me understand really what a lifter is or, you know, what that role is there, because they're going to have to eventually support that software and provide the enterprise grade stuff that you're selling as part of the subscription, right? This whole general sales thing is like, that's what the product is, is that it's reliable, it's supported, bug fixes, et cetera. The way that it works is that, you know, one of the things that we add to the equation by creating Tidelift is we are an intermediary between the professional teams that are paying for these assurances and the individual open source maintainers.

So a couple of benefits of that. One is that we turn a many-to-many relationship that would basically be impossible for every open source application development team to strike a business agreement with every one of those 1100 NPM module maintainers, right? That goes into their web app. We allow them to have one place to go, which is Tidelift. And then we sort of federate all of the participating maintainers behind that. So we have a relationship with each of the paying subscribers. And then Tidelift also has a relationship with each of the participating maintainers behind that. So we have a relationship with each of the paying subscribers. And then Tidelift also has a relationship with each of the participating maintainers.

And what we ask the maintainers to do, it's actually detailed on our website for any maintainers who are interested in sort of understanding what we propose in our model. We ask maintainers to look after their projects according to a certain set of criteria. These are things like work with our security response team. If there's a new security issue that arises, make sure that it's addressed in your particular package. Or if there's an issue in one of your dependencies, make sure that your package is adjusted to take account for that. Help us documenting new releases that are happening. You know, any licensing changes.

We sort of record all of that. Those are the kinds of things that we ask maintainers to do. Just to highlight, at least for now, we're not asking maintainers to fix a bug or add a feature or provide help desk support for a runtime issue that was encountered by a subscriber. Those things, there are open source business models associated with that. They're challenging business models because they scale with the number of hours that an open source maintainer has in their day. There's only so many support tickets you can respond to or so many consulting engagements that you can have. We're trying to focus, since that's already possible in the world,

we're trying to focus on a new model, which is doing things that can be done once where many people benefit from them, like, you know, resolving the security issue. You do that once and all of the users get to benefit from it. Our part is to create the alignment of interest so that those things always get done with predictability. And, you know, we do ask our maintainers, participating maintainers, as we call them, lifters, to do those things. And then Tidelift's role is to sort of make sure that everybody is following through correctly, deal with any kinds of, you know, issues that come up in the mix.

You used the term a well-defined standard earlier in the call. I am assuming that that means that it's either written down once or it's the way things are, or it's maybe a case by case basis with each lifter or maintaining core team. You know that they say, you know, OK, Tyler, we want to be a part of this. We want to be a lifter. Sign us up. We're ready to go. And then there's something I'm sure that says in I'm assuming this will define standards as, hey, this is what you're gonna be on the hook to. This is what you're committing to. Is that accurate? Can you describe that? Yeah, it's more like a set of open source project best practices that we ask our participating maintainers to follow.

And here's actually another really great part of how this all works is that most open source projects that have a substantial user base are already doing most of these things or all of these things. I mean, this is things like having a responsible disclosure policy and adhering to a responsible disclosure policy around security incidents, right? Or, you know, using two-factor authentication on all of your systems that are involved in the build and distribution chain for an open source module, sort of like checklists for healthy living as an open source project. Those are the things that we ask open source maintainers who are participating in our system

as lifters to do. And even though many of them are doing most of those things, by creating a uniform standard where everybody who's participating as in the Tidelift system is doing all of those things, it allows us to represent that this collection of open of software as a whole meets those standards to our subscribers. And again, that's worth a lot to these, you know, professional software teams that are building enterprise applications. If we can show them a menu of, you know, health, healthy open source project attributes that we're ensuring are true for the dependencies that they use, they love it,

you know, and it's a it's a modest cost for them to pay to ensure that they for the dependencies that they use, they love it, you know, and it's a, it's a modest cost for them to pay to ensure that they're the software that is really powering their our friends at GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. Check them out at GoCD.org or on GitHub at github.com slash GoCD. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end with no problem. They support Kubernetes and modern infrastructure

with Elastic on-demand agents and cloud deployments. To learn more about GoCD, visit gocd.org slash changelog. It's free to use. They have professional support and enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. Most companies have co-founders. In this case, you have three other co-founders, I believe. What's the story there? Who are they and how did you all meet? Yeah, well, this is the best part of Tidelift for me. It's my co-founders and then the team that we've built to go on this mission together with us. And it is an interesting story. So, you know, I have three co-founders, Havoc, Pennington, Jeremy Katz, and Louis Villa. And we've all known each other pairwise for at least

15 years. And a couple of us go back longer than that. As I mentioned before, we all intersected at Red Hat in the early 2000s. And then we've collaborated on different projects since then. And each of us sort of has a different ingredient that we contribute to the mix. So, you know, I talked about my background a little bit. A lot of it is sort of the business side of open source. Havik is our co-founder. He currently is leading product for us. He is a longtime veteran of the open source world. He was originally one of the founding voices in the GNOME free desktop community, you know, the Linux desktop, and, you know, led the creation of the GNOME Foundation, co-led the creation of the GNOME Foundation, co-led the creation of the GNOME Foundation, which continues, you know, productively to this day.

Implemented a lot of the software himself that powers the GNOME desktop. And then he was, I got the chance to work with him first when he was leading the desktop development team at Red Hat. And then Havik has interestingly gone on to do tours in a couple of other interesting and different open source communities. He was working for a stretch in the Scala community in the sort of greater Java world. And then most recently was back in the Python data science community before

we got together to start Tidelift. And then third co-founder is Jeremy Katz. So Jeremy is amazing technologist. I got to know him when he was one of the core developers at Red Hat. Then he went on to, um, sort of, uh, grow his, uh, professional, uh, portfolio beyond just open source. He was an early employee at HubSpot, the marketing, uh, SaaS company. Um, and then he was, he led the implementation of this product called Stackdriver, um, which was a startup that was sold to Google and now serves as essentially the management console for the Google Cloud Platform. So really a seminal piece of software in the cloud generation. And our fourth co-founder, Louis, has sort of the, I think, the

most unusual story, which is, you know, Louis started with us as the rest of us as, you know, programmer, you know, open source developer. And, but Lewis ended up going to law school, and then closing that loop by becoming an open source legal expert, really one of the, you know, widely respected voices around legal issues associated with open source. He did a really interesting stretch working with Mozilla, where he actually led the drafting of the Mozilla public license 2.0. And then he had a really interesting time at Wikimedia Foundation, the organization behind Wikipedia, you know, dealing with a whole bunch of open content issues there and sort of leading the community effort there as well.

So it's a really interesting set of disparate, you know, backgrounds and professional experiences grounded in having all been, you know, open developers, software developers and open source participants in the early years. And we're sort of I guess what we're trying to do is to, you know, bring those those different experiences back together and apply them back where we all started, trying to make open source work better for everyone, the creators and the users. It's an interesting mix of of people. I mean, obviously you got business, you got, you know, I'm sure everyone is somewhat involved in coding, at least at some point in their life,

but taking a role in that, having a role in Google and what powers that, and then legal, the licensing part of open sources, you know, to some often overlooked, but pivotal to how it could be used you know we see license changes in business there's some recent news not long ago with redis and whatnot around commons clause or license zero and all those things have implications and even react because

you mentioned them earlier and we even logged that about, you know, who actually supports react. They had, uh, I'm not, I'm not sure the details don't fall this closely, but it had some concerns around the community, whether or not like the way Facebook licensed react, we've even had, uh, Heather Meeker on request for commits. And she mentioned that earlier. And we talked about Nadia, like we had a deep conversation around the importance of licensing. So it's, it sounds to me like you've got an ensemble of the right components to do Tidelift. And I don't know how you did it, but that's pretty insane that you have. And it's,

it's even more interesting that you all intersected Red Hat. Yeah. I mean, I just feel so privileged to work with, with, with these gentlemen. And then again, the team that, that we've, you know, brought aboard to, to share this mission with us. It's a lot of fun. It's a lot of fun. But to the point around licensing, licensing is actually one of,

the legal code is one of the technologies that makes open source possible. It's sort of a technology unto itself. And like other technologies, it's complicated, right? I mean, it's complicated for the creators to make the right sets of decisions around which license should I use? You know, what are the tradeoffs and so on? It's also really complicated on the consumption side, right?

And that's one of the, again, one of the things that we're trying to help address for, you know, professional teams that, you know, want to engage with open source in the right way. You know, they don't have the time to each go become an open source legal scholar like Lewis did. So we're going to try to, you know, create some tools and standard ways to approach this that let them, you know, get the advantage of some of that substantial knowledge that Lewis has accumulated in his days. I'm sure this is the case for most founders or co-founders, but I find it kind of interesting

that each of you have a particular milestone in your career that is like each of you can point to a particular thing you've done that is widely notable. To say, not so much that this is why you do what you do or you belong here or you can trust you, but it's like you all have some large scale contribution to the community you're currently serving through what you're doing now. all have some large scale contribution to the community. You're currently serving through what you're doing now, you know, to say we're part of

the community. We're not just entering, like you said earlier and trying to solve a problem. And we've never been here before. Like, no, we've been boots on the ground for decades and our resumes and the work we've done before, you know, is what you pointed to prove it. Yeah. I mean, the only caution there is that every situation is different, right? So, you know, one of the things I always try to remind myself is not to, you know, to learn from the past,

but not to over-apply models from the past because sometimes they can be misleading, right? The world changes. Like the world is a lot different now in 2018 in terms of where open source is, you know, in the software ecologies in general versus 2002. Back when we were, you know, doing the first version of the, you know, enterprise Linux business model in 2002, you know, most professional companies looked at Linux and said, this thing looks crazy. What do you mean free software? How could this possibly work, et cetera, right? Now, fast forward 15 plus years later, there is no proprietary software to buy in most of these categories, right? It's pretty hard to go find a proprietary application framework to build with these days.

It's almost complete takeover by open source. Our point that we're trying to highlight with our work in Tidelift is just because open source is everywhere, it doesn't mean that software doesn't need to be maintained. In fact, it sort of heightens the question of who is taking care of that software and why. Right, who's responsible.

And so, you know, who needs it to happen and how do we connect the dots? Well, let's close the loop on, you know, this idea of, you know, sustaining open source, maintaining open source, you know, this word and phrase that often gets put out there and talked about and like the actual mechanics of what that really means. There's other models out there. There's and every sort of model is needed because you said it earlier, like, hey, if money is coming in open source, great. And let's not, you know, say one way is wrong or right. But I want to kind of go into the differences of like, let's say other models you've got. We've talked to Pia Mancini on here before

around Open Collective. We talked to Eric Berry around CodeFund, previously CodeSponsor. I haven't talked to anybody from Patreon or Patreon before, but we've definitely talked to like Evan Yu on Request for Commits and several others who, Henry Zhu from Babel on how they're, you know, leveraging, you know, their ability to go full time and using those platforms to really well, you know, really good advantages. But then here comes Tidelift. So what is the biggest difference between like Tidelift and other models where they could be seen as like more charity or somewhat value-based? Yeah. First of all, just to, you know, get on the table, the more the merrier. I said it before. I think every channel to pay the maintainers is additive, right? And so we're just trying to

add another option into the mix. And probably the answer, quote unquote, is not one of these. It's a polyglot solution of multiple of these working in different ways, right? I do think that we have a somewhat different approach than a lot of the systems that have been implemented before. And it comes back to just being very practically minded around not just asking organizations to pay back the maintainers that created software that they're using because it's the right thing to do, not only because it's the right thing to do, we're giving them the additional or we're seeking to give them the additional self-serving reason to do it, which is if I pay for a subscription that covers these open source components, I know that there is somebody who is committing to me that they're going to care for this software. And when we say

care for the software, it's written down what we mean by it. And if something, an issue arises, I'm going to have someone to go to, they're committed to work with me. So it's like, it's something that they don't get if they don't pay. And we think that's compelling to a certain audience. And again, it's, you know, we're more oriented towards these, you know, software teams within enterprises. That's not particularly compelling to most, you know, hobbyist developers. They're not really the audience for Tidelift, at least at this moment, not the one that we're targeting, at least. And for hobbyist developers, I think, you know, there's a bunch of other options on the table.

By the way, as a hobbyist developer on the side myself, I'm happily a, I happily contribute to a number of different, you know, funding mechanisms for the projects that I use. I think it's great and I love doing it and it makes me feel good and everybody should. So definitely echo what you're saying on the more, the merrier. One question I have for you though, is like, since you said you're a listener of this podcast and you listened to the latest episode or one of the latest episodes with Eric Berry, one thing I can recall him saying in the conversation we had was around this extra layer. So the example we use in that show was Jack Lukic, who was the creator of Semantic UI,

which we actually use here at Change. It's the UI framework we use for our backend. And the question in the conversation there was essentially like layering on one more thing for a maintainer to do. So Jack may be really great with user interface, may be really great with the framework, and that's all he may really want to do. But he's at a stopping point of like time invested because the lack of funding.

And so in a Tidelift model, and maybe Jack's not the perfect person. So Jack may be considered hobbyist, even though his project is used tremendously and very vital to so many projects that's using it. But, you know, he may not have the time or the desire to want to do the other things to support, you know, or to to be in the Tidelift model. How does that fit in? Yeah, I think, I think, um, uh, if I was to rephrase the question, it's like, what if, uh, the, uh, open source maintainer or team like, isn't interested in doing the Tidelift, um, uh, maintenance Tidelift style maintenance assurances. Yeah.

So there, um, you know, we sort of look at that again from the, look, think about it from the, you know, open source user's perspective. The user is still interested in having somebody, you know, look after the security, look after the licensing and the maintenance of this component. So if the current contributors to that project are not interested in doing that, can we create an incentive for some new contributors to join the project to do that? And one of the patterns that I've witnessed being in and around open source communities is when somebody shows up in an open source community and they say, hey, I'm interested in doing some of the grunt work around here to sort of,

you know, help with some of the day-to-day maintenance tasks, especially if everybody else has already passed on, you know, volunteering to do those things. Usually they're accepted with open arms, right? So I think that we, our model can potentially help in those scenarios by, you know, giving people someone else a nudge to sort of show up and volunteer. It's not really volunteering because they get paid to do it. They're getting paid. Yep. Pay the maintainers is our mantra. I like that tagline a lot. I mean, I just think it's short.

It's three words. It gets to the point. Pay the maintainers. I like that. And I think, you know, as we talked about, you know, you said the more the merrier. And I think that's what kind of everyone is saying. Like, let's just find ways to pay the maintainers

so that they keep maintaining, so that they keep innovating, so they keep really just enjoying it. Like open source is fun to be involved in. What makes it not fun is whenever you're not, not so much not rewarded, but just when you're, when you feel depleted, you know, at the end of the day, because you wake up to 35 new issues, all these different things, and then you've got your day job and your family and your life, you know, that's what sort of drags it down and makes it very difficult to scale.

And maybe why earlier you mentioned venture capital. Capital wasn't a great option for it because just the way the market worked. There's always different ways, but this is just one of several ways we can pay the maintainers. And I like that mission a lot. So Donald, we're coming to the close here. I like to end with this question. Super secret. Something's going on at Tidelift that maybe people aren't aware of.

I don't know. You know, I don't know. Is it, you know, a new announcement, something coming up? What's something that no one knows about that you could share here on the show today? Or even tease, whatever it might be. Yeah, I'll just, I'll just mention a little, you know tease for that we're going to have some really um exciting to us and i think relevant news um coming out um in the next couple of weeks talking about um getting to a certain kind of scale milestone uh on the tidelift platform um and uh yeah stay tuned for

that uh stop by tidelift.com depending on when you're listening to the podcast to learn more about, you know, sort of showing the model working at some interesting scale that we think people will find compelling. When you say milestone, it means the big deal, right? This is a big deal. It means we're reaching another waypoint on our journey to, you know, demonstrating the Tidelift model working at scale and paying the maintainers. Gotcha. And so even if you're listening to this distant in the future and this announcement since past, we're going to update the show notes. So what Donald's talking about, we'll definitely link it up, whatever it might be. I don't know where it's at, but wherever it is on the internet, we'll link it up. So just go back to your show notes. We'll make sure we have we have those up to date. Uh, Donald, anything else in closing, man? I mean,

it's a fun journey that you've been on from, you know, your history in open source, all the different co-founders that have worked with you on this, the mission you have to fund open source in particular pay the maintainers. I love that. Uh, anything else you want to say in closing to the listening audience that, uh, that may may be interested in the journey of open source and what it's about? First of all, I would just say thank you to you, Adam, and to Changelog and Founders Talk for covering these topics. Because I think you're a really important voice and you're shining light on important issues. And I guess that would be my parting thought is that these issues are important, right? Like, as a lot of folks now have pointed out, you know, you referenced Nadia did an amazing job sort of shining a light on the importance of open source software. Yeah.

We have now decided to collectively to build our civilization largely out of software. And that software is open source. So if we want our world to be a great one, we need our software. And that software is open source. So if we want our world to be a great one, we need our software to be great. And that means we need our open source software to be great. So, you know, I just invite everybody who's, you know, interested in these topics, learn more about the different models that are being proposed. I'd love for folks to come and learn more about Tidelift and talk to us and help us evolve it in the right way, take it the right way. Launch additional models. You know, let's try a whole bunch of things and collectively, I think we can have a really positive impact on the

world. And thanks a lot for paying attention and, you know, putting this in front of an interested audience, Adam. Absolutely, man. Thank you so much for saying that to me. This has been, you know, a labor of love for many years, turned business, and we've been fortunate in that. And, you know, if it weren't for our listeners and those who contribute to open source and this entire community, like we would not be able to exist, obviously, because we'd be nothing to talk about.

But, you know, we're just so thrilled that we get to be in this position. We've been down a long road, and I honored to have one you on the show, then two, you as a listener. And when I mentioned things, even in the breaks, you're like, I've already listened to that. I didn't know that you were that passionate about, you know, sometimes people say, you know, thank you, but you're an actual listener who listens

to every show or at least a lot of them. That's that's awesome. I love that. Keep up the good work, man. Well, thank you, Donald. It was a pleasure and really appreciate it. Thanks for having me on. All right, everyone.

Thank you so much for listening. You can find more episodes of Founders Talk at changelog.com slash Founders Talk. Rate, recommend, or review the show wherever you listen to podcasts. Thank you to our sponsors, Rollbar, Linode, and GoCD. Bandwidth is provided by Fastly. See you next week. Music is by the incomparable Breakmaster Cylinder. The show was edited by Adam Stachowiak and remastered by myself, Tim Smith. See you next week.