Bart Copeland, is the CEO of ActiveState. Since the 90s, millions of developers have used the famous ActiveState distributions of Python, Perl and Tcl. In this episode, Bart narrates ActiveState’s journey, including several pivots and ownership changes. Stay tuned to the end to find out how they were able to pivot to the open source thing that they do so well.

Transcript

Intro

Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 36 with Bart Copeland, CEO of ActiveState.

If you’ve ever installed Python, Perl, or Tcl on a Windows workstation, there’s a pretty good chance you use the ActiveState installer and distribution.

ActiveState is one of the oldest open-source companies in existence. The founder was Dick Hardt, who some of you might know as one of the editors of the OAuth 2.0 specifications, among other notable achievements.

This episode is the first one we’re publishing that was recorded in person at the open-core summit. If you’re a fan of the podcast, you heard Joe Jacks, a few episodes back, describing the event which did not disappoint.

Don’t miss the next one if you can get to San Francisco. Especially if you’re a founder or entrepreneur interested in open-source software development.

ActiveState made some major pivots, although I think they ended up returning to their roots. It’s a pretty fascinating story. So, without further ado, here we go. Bart, thanks for joining the podcast today.

Bart Copeland: Thank you, Mike, it is great to be here.

Origin

Michael Schwartz: ActiveState was founded in 1997, which makes it one of the oldest companies we’ve interviewed so far. It was acquired by Sophos, I guess in the 2000s, and then, it was bought out by management.

Just focusing on what happened after the acquisition, can you take us back to the time after the buyout happened, and how you refocused a company?

Bart Copeland: It’s a really good question, Mike, but I should start with, in order to understand the refocus, we need to understand a little bit of history of why ActiveState was acquired in the first place.

ActiveState started in 1997, it was all around open source, building specifically language distributions around open source for the developers. Developers had needs specifically around Perl. Then, anti-spam became a huge problem. ActiveState came up with an anti-spam solution called Perl MX, and that caught the interest of Sophos.

Sophos acquired all of ActiveState, but Sophos really wanted the Perl MX product, which eventually became PureMessage under Sophos. The CEO Sophos had a lot of affinity, and pride, and admiration for all of ActiveState. And the other team, the language distribution team, was dormant within Sophos, and he did not want to do anything to hurt that team.

That’s where I got involved, and I was an early investor in ActiveState, but I wasn’t part of management. But then, Steve Munford, the CEO of Sophos, contacted me, and I, with a couple of few other outside investors, we acquired the team, the technology, the customers and the ActiveState brand.

And what we wanted to do leaving Sophos, is, we wanted to do the next great thing. We often said, “We want to do the next PureMessage.” So that started us on what we refer to as chapter 2, or version 2.0 of ActiveState. So, 1.0 was 1997 to 2003. And then, 2.0 was after the dormant period, from 2003 to 2006. And 2006, that’s when we started ActiveState 2.0.

Maybe, before I go on, did I give you a good grounding of…?

Michael Schwartz: Sure. And what was the plan when you bought it out?

Bart Copeland: There was two key plans. The first key plan was, we needed to extract ourselves from Sophos. There’s all this infrastructure and technology overlap that we needed to distract ourselves from, so that was our first plan.

The second plan was, let’s go do the next great thing. And that’s what we were going to do. We were a team, I think at the time, we were about 16 people or so. One other key caveat, above all this, was, I wanted to do it organically. I didn’t want to raise a bunch of money. I said, “Let’s do this the good old-fashioned way. Let’s drive revenue, let’s reinvest that revenue, our profits into growing even further.” So, that was what we embarked on.

Value Prop

Michael Schwartz: Would you say that you’re similar to Anaconda, or RedHat, making an open-source software distribution, consumable by the enterprise, by providing reps and warranties, and liability protection, and patches, and aligning with the enterprise procurement process?

Bart Copeland: The short answer is — I’m going to give you two answers, the short answer and the long answer. The short answer is, I say, we do the same thing that RedHat does for Linux, but we do it for open-source programming languages. 

We have RedHat Enterprise Linux or RHEL, and it’s a enterprise-grade distribution of Linux. We have Enterprise grade-distributions for Perl, Python and Tlco, and there’s a lot more we’re doing there. That’s a short answer.

The longer answer is, our whole mantra at ActiveState is twofold. Mantra number one is, making open-source easy for the enterprise. Mantra number two is, making open source that just works for developers.

When it comes to open source run times, whether you’re the enterprise or the developer, there’s different needs. But if you look at the complexity it is today, to build a language distribution from an open-source ecosystem, and have that consistency across operating systems, managing all the dependencies, managing the security issues, managing the license issues, and then, keeping it updated, and making it really easy to deploy and share with other developers, making it really easy to move that distribution from your dev environment to your test environment, or your staging environment, or it’s your production environment- it’s not easy.

We do a number of things that make it easy, as well as the indemnification that you talk to. There’s really two audiences, there’s developer audience and they have their needs, and then, there’s the Enterprise audience and they have their needs. And our goal is to meet both audiences’ needs.

Revenue Streams

Michael Schwartz: So, from a revenue perspective, what are the most important products, and which products do you think are the most promising for future growth?

Bart Copeland: I talked about the versions or chapters of ActiveState. Under chapter 1, the most important product in terms of revenue potential and growth was Perl MX product.

Under chapter 2, it was the Stackato product. The Stackato was our private PaaS offering. That product was sold to HP in 2015.

However, under chapter 3, it’s our language distributions product. But here is the important thing to recognize, Mike. Under chapter 1, and chapter 2, and under chapter 3, this has been a steady growing business, our language distribution business. What we’re doing different under chapter 3, is we’re trying to grow our business so that it doesn’t bifurcate. Because, if you notice in chapter 1 and chapter 2, we ended up with two business units.

In chapter 1, we had the language distribution business, and we had the Perl MX business. Under chapter 2, we had a language distribution business, and then, this product called Stackato, which I touched on briefly.

So, we ended up with two business units under chapter 1 and chapter 2, and I really felt what was important for us, as a company going forward under chapter 3, is, let’s have a unified product offering, no bifurcated businesses or two-business unit.

Our real growth opportunity and potential for ActiveState going forward is around this whole area, what we refer to as open-source language automation. This is a category that we’re leading in. It is bringing automation to your open-source runtime.

And, as you know, Mike, in the hole open-source ecosystem today, there is a lot of movement towards bringing automation to the software development life-cycle. We are touching on one aspect of that, and that’s the open-source runtime.

Why this is so important, and why we see this is a huge opportunity, not only for ActiveState, for a lot of people in the open-source ecosystem is that developers today have lost the freedom to do what they do best, and that is, write code.

Developers today are spending more time doing things other than writing code, they’re dealing with security issues, they’re dealing with license compliance issues, they’re dealing with IT compliance issues, they’re dealing with bug fixes. And it’s knowing that developers are losing their efficiency in doing what they do best.

Furthermore, developers are not able to use the best tools to do the job. What we’re trying to do, as a company, is to help free up developer, so they have the right tools to do the best job, and they’re doing what they do best and love to do, and that’s just writing code.

So, in summary to your question of, “Where is the biggest potential for ActiveState?” – It’s around this whole category that we have created called Open-source Language Automation.

Customer Segments

Michael Schwartz: ActiveState is serving many large customers, but the market for programming language is a very horizontal market, probably every company on the planet can use it. Do you segment the market in any way?

Bart Copeland: We do, and we don’t. There’s two ways we look at the market. The first way we look at the market is, we think of the developer, and we think of the large enterprise – we’re constantly thinking about that.

At ActiveState, we talked about bottom-up and top-down. Bottom-up is, we think of the developer, and how do we create an experience for them, to be very easy for them to consume our products and use them in working with us quickly.

The top-down is, the developers using our product, bring it into an enterprise, they bring it to their boss, and they say to the boss, “I really like to use the ActiveState platform in greater detail at the job.” That’s the top-down, it brings in the decision-maker, it brings the buyer. So, that is one way we look at the market.

The other way we look at the market is, in terms of verticals, who has the greatest affinity for the types of solutions we build and sell. And historically, and going forward today, we’ve had a lot of success in obviously high-tech.

We’ve had a lot of success in banking and finance, we’ve had a lot of success in aerospace and defense, we’ve had a lot of success in insurance, and we’ve had a lot of success in manufacturing. Whereas we haven’t had a lot of success for example in healthcare, to give you an example where we haven’t had success.

But on the whole, though, we don’t do a lot of segmentations, because you’re right, it’s a very horizontal play for us. And what we try to do is, we try to make our softwares accessible to as many developers as we can globally. Throughout the planet, we have downloads all over the planet. The number one download is the US, and I think after that, our downloads are really big in China and Japan, and then, in Europe.

Hopefully that gives you an idea of how we look at the marketplace. And I guess, if I would really wear my marketing hat, we could do a lot more segmentation that we’re doing than we’re not doing.

Sales Motion

Michael Schwartz: So, drilling down into the team a little bit, how do you organize the sales effort for such a global market? And how is that sort of adjusted over the years?

Bart Copeland: The first thing is actually, the adjustment has been the same under all versions of ActiveState, or all chapters of ActiveState, 1, 2 and 3. The selling motion has been the same. The selling motion from a sales organization is effectively comprised of account managers, account executives, and customer success managers, and inside sales reps, and depending on where you are in the selling cycle, involves those individuals.

Typically, what happens, we — and I got the other aspect of sales engineers — we get a potential opportunity. Usually, it comes from a developer, or group of developers, using our solution within an organization. That then leaves to greater interest into, going from the free version to a paid version. That involves an account executive, with a sales engineer, they work together, and we do this all over the phone.

All our selling is done over the phone, rarely do we go on-prem to an organization. It’s done over the phone, or through a series of video conference calls. Then, relationship is made, a deal is consummated, all our deals are based on annual subscriptions. That’s a recurring revenue model. Once the deal closes, then it goes to our customer success manager.

The customer success manager with her team, their job is to make the customer successful. Then, there’s an account manager that is brought in to nurture and manage the account, and renew it, and work with the account, to help them in other areas of their business, where our solutions can help them. And that’s typically the cycle that we work on.

Now, that is for the Enterprise tier. One thing that I haven’t touched on, Mike, is that we, not only have an Enterprise tier, we also have a lower-tier pricing structures. We have five tiers, we have the Community Tier which is free, but then, we have the Coder Tier, the Team Tier, the Business Tier, and the Enterprise Tier.

For the Coder Tier, Team Tier and Business Tier, that’s handled by an inside sales group that deal with the smaller price point products.

OEM

Michael Schwartz: I noticed that you have an OEM license – is that a material part of your business? And how did that come about?

Bart Copeland: Yeah. If you look at our business today, at the enterprise level, about 50% of the revenue at the enterprise level is enterprise subscriptions, and the other 50% is OEM. So, the way it came about is that when you get a distribution supported from ActiveState, there’s two ways you can consume that distribution. One way is, you consume it internally, and you consume it internally for all of your internal Dev practices or Dev applications that are enterprise wide.

However, another way you can consume our distributions is, you bundle it with your product, and you sell that bundle to your end-users. For example, you may have a product that requires a Python language distribution to run your Python product on your customers’ systems.

Then, we OEM our language distribution as part of a bundle, and that’s how it came about. It’s a sizable portion of our business, the OEM portion.

Other Partnerships

Michael Schwartz: Are there other partnerships that you think are important to ActiveState?

Bart Copeland: So, going forward with the ActiveState platform, around open-source language automation, we feel the partnerships that are really important, it is right now looking at the whole landscape around CICD, around what GitHub and GitLab are doing, and what the cloud providers are doing, specifically AWS, Microsoft Azure and Google with Google Cloud platform, as well as we watch IBM Cloud, it’s kind of the number four cloud player.

Those are the three key partnerships. We’re looking at other areas that we are concentrating aggressively. I would say there’s another area, fourth area of a bunch of miscellaneous groups that we feel are important. For example, we feel it’s very important to play well in the whole RedHat ecosystem.

Another ecosystem we feel it’s important to play well is in the VMware ecosystem. Another very important area, which is more around standardization, is the Docker ecosystem, or the containerization ecosystem, to make it very easy to consume our distributions as containers.

Is ActiveState Open Core?

Michael Schwartz: You mentioned a few tiers of product – would you consider ActiveState distribution to be open core?

Bart Copeland: Absolutely, yes. If you look at what comes off of the platform, the ActiveState platform is all about building your language distribution, certifying it, and resolving.

So, when I say building, you decide which packages you want from the open-source ecosystem, you decide which of the language runtime you want to use from the open-source ecosystem. For example, to stick to Python, you want Python 3.7, you want 35 packages from PyPI, you bring that all, and that’s all open source.

We then build it for you, for the operating systems you care about. You have three choices: Windows, Linux and Mac. You build it for the operating systems you want. That then is created as a distribution, the core of the distribution is open core, because it’s relying on all the open-source licenses that exist, and we preserve that.

Once you build the distribution, then, we certify it, we check for any “dependency hell” issues. What I refer to as dependency hell, we check for any security violations, we check for any license issues that you may have decided as a user, there’s certain licenses you don’t want.

The other thing we do is, we resolve any issues that come up automatically in the background. You’ve got this distribution on the ActiveState platform, and the result is, the dependency breaks or there’s a CV threat – we fix that automatically and we alert you.

Where I’m going with this in the spirit of your question, all of that is still open-core. It’s all based on all the open-source ecosystem, but the platform itself is closed-core. That’s the closed proprietary layer on the outside.

Pricing

Michael Schwartz: Over the years, have you significantly adapted your pricing strategy, or has it been relatively stable? Let’s just talk about the distributions, what you’re still in.

Bart Copeland: The distribution business has been relatively stable. The key thing that’s different is, historically, we’ve been distribution as-a-service. You come to ActiveState, and we provide you a distribution as-a-service. Now, we’ve evolved the business, where it’s, you self-serve with the platform and build your own distribution. It’s a software-as-a-service solution.

The pricing for the most part is the same, but we’re offering a lot more for the same price now under the ActiveState platform.

Open Source With A Third-Party Project?

Michael Schwartz: One of our guests previously made the case that it’s better to sell open-source software that someone else writes because, otherwise, you are funding engineers who are basically not billable – would you agree with that?

Bart Copeland: Yes. But I think you have to find a fine balance. Because, if you are always taking and not giving – that’s not good. From my perspective, you have to have a very fine balance of how you’re dealing with the open-source ecosystems.

Language Support Roadmap

Michael Schwartz: There are new programming languages every year, it seems. I’m guessing if you’re a new programmer, you’re not going to start learning Perl or Tcl – has that made these products more valuable, maybe as you face less competition in the tools market?

Bart Copeland:  I believe it makes it worth value for two reasons. The first reason is what you mentioned. It is that we have a lot of legacy languages that we support, it is very important to the enterprise. Because, for example, and some of your listeners may laugh at this, is that we support today Perl 5.12.

We have Perl 5.28, but we have enterprises, we have applications and production, and we support 5.12 for them, because it’s easier for them, if we support Perl 5.12, to migrate to 5. 28.

So, in that sense, that’s very valuable to us and valuable to our customers. But at the same time, the same customers are saying, for new applications, for greenfield applications, we need to use the new languages, and can we go to ActiveState to get the new languages.

Our goal eventually, with the ActiveState platform, is to support any language that our customers want to use. We’re not there yet, but that’s the vision for the ActiveState platform.

Michael Schwartz: Which languages do you think you’re maybe in sooner than later?

Bart Copeland: Great question. Right now, we’ve got Perl, Tcl and Python. On a roadmap for coming up here is Javascript, and Ruby, and Java. And then, most likely were looking at PHP, R, Elm, Rust – these are some of the languages that are on our radar.

Team

Michael Schwartz: Can you talk a little bit about your approach to building the team? Does location weigh into the hiring equation, or are you willing to use remote people?

Bart Copeland: That’s a really good question. My philosophy is, we go where the talent is, we don’t force the talent to come to us. So, we are a company about — what is it today — think about it, just under 2/3 are head office in Vancouver. But I think it’s getting closer to 50%. The other 50% are distributed throughout North America.

Our philosophy is, as I said, we go where the talent is. And as a result, especially on the development side, we are hiring developers, wherever the talent is. We have developers spanning four different time zones, from West Coast all the way to Halifax, which is one hour further than the East Coast time.

But we tried to bookend it within those time zones, because we haven’t yet expanded to either the Asian market or the European market, just because of the collaboration. We wanted to be able to collaborate in real time. We use Slack aggressively as an organization.

So, the answer to your question is, we are very open to a distributor organization. We think we’re doing a really good job of managing a distributor organization. There’s a number of things we do to include all of our virtual activators. We call ourselves activators at ActiveState. And we refer to our remote activators as virtual activators or remotes.

Here’s some things we do to make them feel inclusive. We use Slack aggressively. Most of our Slack channels are all public within the company, so everybody can see what everybody’s doing. There’s freedom to lurk, there’s freedom to participate.

We have regular company meetings once a month, with the entire company, with video on. We also really encourage video meetings all the time. Every morning, all the teams, various teams have daily stand-ups, the agile methodology, all those daily stand-ups are done with video or a video conferencing.

We also try to have all our activators, at least twice a year, come to head office, so we fly everybody in. We have them all together, so they can build relationships and cross-pollinate.

Also, many tech companies have a lot of nice fringe benefits, like free drinks, free food, we bring in a warm lunch every Friday, we call it “free-lunch Friday”. Unfortunately, our remote activators don’t have access to that, so what we do is, we send them a food package once a month with Amazon Prime — and I’m not sure exactly how we do it, I’m not involved with it myself — but we actually ask them what they would like and we arrange it in an Amazon Prime, and we deliver it to their homes.

And the other thing we do is, various members of the remote team fly up on a regular basis to interact with the head office as well. These are some of the things we do to promote inclusive environment, and also needs to grow. Because it’s very hard, given the type of work they are doing, to find all that talent in Vancouver – I would say it’s impossible. It’s not very hard – it’s impossible.

Balance Free And Paid

Michael Schwartz: As a sort of Python hacker myself over the years, I’ve been on the ActiveState site a number of times, looking at code examples – how do you choose which efforts to invest in? And how do you invest, I guess the R&D or community work that you do – how do you prioritize it?

Bart Copeland: It’s a really good question. I don’t have a good answer for you on that. At the end of the day, we have to find a balance between investing in developers and solutions for developers and meeting their needs, and balance that with ultimately the enterprise, because they long-term pay the bills. And we need a healthy balance there.

One of the things I should touch on, Mike, is that, if you look at ActiveState through its entire 20-year journey, there’s something common through that 20-year journey. And that commonality is as follows: every single product has been based on open source. Every single product has been built and designed with the developer in mind. 

And every single product has been built with a developer and the enterprise in mind. If they take the intersection of those three, that’s our sweet spot, that’s where we make money. We’re constantly trying to find the balance because we are a company that’s growing organically.

We don’t have outside money, we have to rely on our hard work and creating a happy balance between developers, who don’t want to pay for things, which we’re fine with, but finding and giving them those solutions that they’re free to use, and then find that happy balance with developers and the enterprise who are prepared to pay for what we offer.

How Far Do You Forecast?

Michael Schwartz: So, you’re 20 years in, which is not something a lot of tech companies can say – how far do you look ahead to the future? Are you looking 20 years out?

Bart Copeland: I look in three to five-year timeframes. Because if you look at ActiveState history, under ActiveState 1.0, we were focused on Perl, the high-rapid growth of Perl, and with the anti-spam problem under ActiveState 2.0, again we were focused on language distributions, and we were focused on the whole cloud computing space, and specifically for us, platform-as-a-service.

Now, we’re focused on open-source language automation and helping make software really work well for developers in the next three to five years.

Because tech moves so fast, the industry is so vibrant and so exciting. And I often say to younger developers, younger people getting into tech – because I’ve been it now for 30 years– I say, “We are still in the early innings. We’re like an inning 2.”

If somebody said to me this is a 100-year cycle we’re in right now in tech, and we’re still in it 20 years or so, we got a lot to do. It’s just starting to get exciting. I’m kind of looking here, I’m at the

the latter part of my career, and I’m looking at my two young sons, who are just starting their careers, and I want to do it all over again.

Because I think it’s going to get even more exciting. But the point I’m trying to make here, Mike, it’s very hard to look beyond three to five years in my view. We, right now, are focused on this audacious goal of building a platform for open-source runtimes and specifically solving the problem around open-source language automation. That’s our focus, that’s a three to five-year plan. We’re going to deliver on that, and then we’ll regroup again.

Bootstrap Governance

Michael Schwartz: Quick question on governance. As a bootstrap company, do you have a board of directors? What does governance look like in a bootstrapped company?

Bart Copeland: Bootstrap company, by definition, that means we’re a private company. So, the company is owned by its employees and some key shareholders. And I believe in good corporate governance, and there is a board. The board is comprised of some of the key shareholders – it’s a very small board.

I think it’s important, as a CEO, that you get external advice, so in addition to having a board, because that’s one form of advice, I have a group of advisers that advise me as well and advise my leadership team.

And I think that’s very important. I think as a bootstrap company, you shouldn’t do things in isolation. It’s very important that you have individuals that are not in the trees with you, and they can constantly spot and say, “Hey Bart, have you considered this, or what about that?”

There’s four of us on the board. And then, I have three other advisers, who are not part of the board, but advise me one-on-one.

Advice For Open-Source Entrepreneurs

Michael Schwartz: Last question. Any advice for new entrepreneurs, who are launching a business around an open-source software project?

Bart Copeland: Oh, that’s a good question, Mike. I think there’s a general advice, and then there is advice specific to open source. The general advice that I give — and I do a lot of Angel Investing with young entrepreneurs, and invest in small promising individuals and companies — the advice I give is, persistence, and perseverance and focus.

If you believe in something, stay at it. Don’t lose your focus. That doesn’t mean you shouldn’t pivot, but if you look at people who are successful – it’s about perseverance and persistence. That’s the general advice.

As far as open source is concerned, I think my advice is, I love open source. It IS the future. When I first started an open source, people were saying, “This crazy. Why are you doing open source? There’s no future in it.” Now, open source has one. There’s so much power in collaboration in open source.

My advice is, if you are not using open source, then there’s something wrong with your company. You should BE using open source. It’s the way to go. It is the de-facto standard to build a great organization.

Michael Schwartz: Bart, that was fantastic. Thank you so much for joining us today.

Bart Copeland: Thank you, Mike, it’s been great.

Michael Schwartz: Thanks to Bart and the ActiveState team for making this interview happen. Thank you, thank you to the Open Core Summit team for giving us a table at the event to promote the podcast, and for giving up their sponsorship room a few times, which was the quietest place we could find to record.

Please, support the event. We need more events like this to grow the industry and to share our experiences in person.

Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

Have comments? Tweet at us. Our Twitter handle is @fosspodcast.

Please subscribe to the podcast and add it to your favorites on your podcast app. That helps us get the word out.

Next week, we have Ben Golub from Storj, who will take us through the first open-source, blockchain business model.

Until then, thanks for listening.

Loris Degioanni is the Founder and CTO of Sysdig, a platform for cloud-native visibility and security for workload production. In this episode, Loris discusses how his past entrepreneurial experiences have helped shape a successful business at Sysdig.

Transcript

Intro

Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 35 with Loris Degioanni, Co-Founder and CTO of Sysdig.

For you, older geeks out there, Loris is a legendary technologist who is one of the authors of Wireshark, a tool, which used correctly, could seem like black magic to layman. So, hearing the voice behind Wireshark is probably reason enough to listen to this episode.

Sysdig has raised over $120M on revenues of $30M, employees around 200 people, so to say that they’ve been successful for a company founded about six years ago is an understatement.

Loris has some unique metaphorical advice for entrepreneurs at the end of this interview, so make sure you hang in there. Enough of my blabbering – let’s get on with it.

Loris, thank you so much for joining the podcast today.

Loris Degioanni: Thank you for having me.

Origin

Michael Schwartz: What was it about Cloud Native infrastructure that gave you the idea for Sysdig?

Loris Degioanni: This is actually sort of a long story. Cloud Native infrastructure is, in my view and in terms of the rationale and motivation to Sysdig, just an inflection, one of the many inflections and radical changes in computer architectures.

We’ve seen several of them in the last couple of decades, the switch from physical servers to virtual machines, the generated arrays of VMware and similar companies, the evolution of virtualization into public Cloud, like Amazon AWS and so on, and most recently, the birth of containerization and modern application orchestrators like, for example, Kubernetes, created by Google.

Each of these big radical changes in the ecosystem typically require to reinvent the functionality that was available before, because the whole ecosystem needs essentially to update to the new paradigm. That’s essentially what I’ve done when I started Sysdig.

I essentially reapplied my previous experience in open-source and commercial products, and I just tried to make something that would be perfectly suited for the new world of cloud computing and Kubernetes.

To give you a little bit more context essentially, I come from a background, I’ve done computer networks and network packet capture for the first 10 years of my career, started in 2000. In particular, my first company was called CACE Technologies, and was behind an open-source packet network analyzer called Wireshark that essentially reshaped the industry of being able to essentially capture network traffic and look into networks.

That company was acquired in 2010 by a bigger company called Riverbed. When I was at Riverbed, I became the CTO of one of their business units, and I was in charge of the product roadmap for the business unit that was doing visibility and performance management for networks and applications by using essentially network packets and so on.

I realized that despite the business going very well, the world was changing, and so, I tried to essentially reapply what I did in open source and commercial, in the previous generation to the new world of Cloud Native and Cloud Computing. That was the summary of the basic reasons why I started Sysdig.

Project Or Company First?

Michael Schwartz: When you started Sysdig, did you start by writing some tools? And I’m wondering if a community coalesced around those tools from the beginning.

Loris Degioanni: Yes. And again, I’m going back, and I will do it probably multiple times during this podcast, to my previous experience with Wireshark, with network packets, because there are several parallels.

When I started my first company, essentially we already had Wireshark, and even before that, a network packet capture for Windows as strong established open-source projects.

That allowed us, me and my co-founders to bootstrap a business in a way that was very efficient, with minimal cost, and allowed us to create a brand and reach a pretty substantial market by just essentially having a very strong and very visible open-source property that was very relevant for our class of buyers.

In that first experience, first myself, and other people in that community that then started the business with me, operated the open-source tool and worked with the community for many years before we started a business.

When I started Sysdig, my second company, I definitely tried to leverage as much as possible the learnings, and in particular, I already knew how effective an open-source tool, adopted by the broader community, would be to bootstrap an enterprise and infrastructure company.

When I started Sysdig, I was in a different situation because I didn’t have an established open-source property, but I decided essentially to create one, to leverage its properties to successively create a business.

First, you need to make something useful. And you need that to be useful enough that people at least want to install it, try it, use it, maybe use it in production. And that both is validation for your idea and also as your initial source of marketing, visibility, lead generation and so on.

What I did with Sysdig was, essentially the basic idea was like what I was doing before with packets was going to be irrelevant because packets as a data source are not accessible anymore when you have, for example, virtual machines instances that are running on Amazon AWS.

You just have machines that are floating on somebody else’s network or infrastructure. You don’t really have access to the router for example to extract these packets to get inside.

Similarly, when you are running containerized infrastructures, based on Docker or Kubernetes, you have these many, many little elements that are pretty opaque, and you cannot really see what they’re doing from the network point of view.

I created a technology that would allow people to gain these insights again, by essentially sitting in the operating system, like for example Linux, and collecting signals, like system calls from this operating system.

Long story short, I sort of came up with a technology that would work again and reestablish that kind of visibility. By doing that, I stumbled into something that would have quite a bit of value for the community.

I decided to release this technology initially as open source, to create essentially a tool that would gather a community around it.

This was in 2014/15, so the very first release that we did of Sysdig was bringing these technology as open source to the community. And to the point Sysdig was born, and to the point the community noticed us, and to the point we started having people talking about us, we started having people installing our tools, and that was how Sysdig was bootstrapped.

Products

Michael Schwartz: I see. So, Sysdig, the company, actually predated the first release of the software?

Loris Degioanni: That’s correct. Sysdig was incorporated a few months before the very first release of the software. Then, of course, the company created a bunch of commercial tools on top of the Sysdig technology. But the timeline was, company started, open-source Sysdig released, and then, commercial products came like two years later.

Michael Schwartz: Sysdig has several product offerings delivered both as software and as-a-service. Today, what are the most important products from a revenue perspective, and which products do you think have the greatest growth potential for the future?

Loris Degioanni: I was saying before I’m going back again to the analogy of network packets, and if you look at network packets, they are a very rich and powerful data source, on top of which you can build many different things.

On top of network packets, you can build a router, a firewall, an intrusion detection system, a forensics tool, performance management tool, visibility monitoring. It is just because packets are data source that is a very horizontal, very rich in content, and typically pretty straightforward and lightweight to collect.

As I was saying before, with Sysdig, the original technological advancement that we did was inventing the new data source that would be similar to packets in terms of properties for Cloud Native in the next generation, which means that similarly to packets with these data source, you can create several classes of tools.

Sysdig in particular has multiple open-source solutions and multiple commercial solutions built on top of them. In particular, from the open-source point of view, we have Sysdig, which gave the name to the company, which is a command line open-source tool that is comparable to like TCPdump or Wireshark, but for modern cloud-based Kubernetes-based infrastructures.

Then we have a tool called Falco, which is a rule-based intrusion detection and runtime protection tool, which I often compare to open-source tools like Snort, or Suricata, but for modern Kubernetes environments.

Falco and Sysdig are completely open-source and are completely community-oriented. On top of them, we’ve built two commercial products. One is called Sysdig Monitor, and it’s for visibility, performance management, alerting, dashboarding, and so on.

The other one is called Sysdig Secure. Sysdig Secure is a bunch of functionality to essentially protect modern workloads that are based on Kubernetes, including forensics, including runtime detection and protection, including vulnerability management and image scanning, and many other things.

Michael Schwartz: Do you bundle those two together, or do you sell them individually?

Loris Degioanni: We bundle them together. Of course, you can buy them individually, but the majority of our customers buys them together.

Michael Schwartz: With regard to cloud, or as-a-service delivered vs. software delivered – which one is more important to you?

Loris Degioanni: I would say equally. As-a-service is the future, is our preferred way to deliver our product to our users. At the same time, Sysdig has many enterprise customers.

Actually, we mostly serve as target customer demographic enterprises, like financial, healthcare, media, and so on. As you can imagine, the SaaS model is something that everybody aspires to follow in terms of vendors, but some of these customers are still not ready for that.

As you can imagine, a substantial portion of Sysdig’s biggest customers’ demands from us software that they can install in their data centers.

License

Michael Schwartz: The commercial tools – are they commercially licensed, or is it just a commercial’s binary?

Loris Degioanni: These are commercially licensed. Essentially the model that Sysdig is following is our core technology, and some of our core pieces of functionality are open source.

I was mentioning Sysdig and Falco before. Those are part of our commercial offering, but at the same time, the commercial offering, instead of just being like licensing and support for our open-source tools, tries more to create bundles that include some of our open-source technology and orchestrate it to work essentially at large scales, and complements it with some proprietary functionality that we’ve built on top of that, which includes both pieces of functionality that are missing in the open-source offering, and workflows and user interfaces on top of everything.

Open Core

Michael Schwartz: Would you say it’s an open-core business model?

Loris Degioanni: I would say Sysdig is a unique open-core model. It is open core, but, for example, I do not compare it to — I have no idea – your typical MongoDB. There’s open-source core is more like a relatively small piece of a broader offering, rather than just the core of what we do. This is by design, by the way.

I always found it a little bit challenging to just commercialize what we’ve built in open source because you tend to pretty quickly fall into the dynamic, by which you’re always thinking about every new feature that you build.

Should I open-source it, or should I “make money” out of it. And I typically don’t like to be in the situation. I like to have the freedom, to have this choice to take every time. I prefer to build stuff where there’s a more clear demarcation between what’s open-source and what’s commercial.

They work more like together in symbiosis, rather than being an extension of the other one, and you have more space to evolve two sides in a less, let’s say, stressful way.

Go All Open Source?

Michael Schwartz: Yes. Would you say then that it’s more tools, where certain tools are open-source and certain tools are commercial – and that’s how you draw the line?

Loris Degioanni: Yes. Tools and also use cases based on these tools.

Michael Schwartz: One of the things I have recently observed is Cloudera, the database company, and also Chef, have gone to a model, where they say everything is 100% open source.

Has this changed your thinking at all about maybe whether to open-source or not certain components?

Loris Degioanni: Partially, from one point of view, there’s the dynamic that you’re describing, which I’ve definitely noticed.

On the opposite side, there’s some other companies struggling a bit to decide exactly what their posture should be, in particular with regards to cloud providers like AWS, taking maybe their software and packaging it for the users.

Elastic was one of the most recent examples of that. I think that there’s no perfect mix, there’s no perfect approach. I think that every product is different, every ecosystem is different, every company is different.

Again, from our point of view, more than looking at what other companies are doing, which we definitely do and we take it into account, we try to do our best to find out what’s best for our users first, and then, what allows us essentially to grow our business.

Material Benefit Of Open Source?

Michael Schwartz: Do you think that open-sourcing of the some of the software has materially benefited the company?

Loris Degioanni: Absolutely. Has and still is material benefit in the company. One example that I can bring is, I mentioned Falco, as one of our core open-source initiatives. We’re putting quite a bit of focus around it because, as I was telling you, there’s an exploding ecosystem, the Kubernetes one, which is more and more shaping to become the operating system for the cloud.

So, the platform on which everybody will build their applications in the future. One thing that is interesting is that Kubernetes is really gaining a lot of traction, and nowadays is essentially been adopted by all of the major product vendors, because it was an open effort.

It was designed to be this kind of lingua franca, completely community-oriented, completely open-source to build your modern applications.

We at Sysdig strongly believe there’s the strength of Kubernetes, and every single component and piece of functionality in Kubernetes eventually will be community-oriented and will be open source.

That’s why we did something that is not super common in the security industry. We started open source first. Security industry, compared to other industries, is still quite a bit more protective and a little bit more proprietary in its approach.

But in Sysdig, we just decided, “Okay, first would be the tool.” It will be Falco. We try to make it part of the ecosystem, we try to make it part of the Cloud Native computing foundation, and we do our best to make it part of the stack.

This is, of course, with the goal of providing value and functionality and security for the broader community, and there is something that can be like a standard, a part of the stack in the future. But, of course, doing that also made us very quickly one of the key players in Kubernetes security as a company.

Despite us giving to our community this important component for free, it’s also helped us essentially grow our revenues in the space. So, yes, this has been very useful for us as a business.

Michael Schwartz: Attaching to this really fast-growing ecosystem and becoming part of the stack had a huge marketing distribution advantage for you.

Loris Degioanni: Yes, and attaching to an ecosystem like this is only possible if you’re truly community-oriented right. That gave us an advantage, compared to our competitors, and is allowing us to grow faster than our competitors in that space.

Is Open Source Value Perceived By The Market?

Michael Schwartz: You made an interesting comment about security not always being open source.  I don’t know if you know but my company is in the identity security area, and we’re open source.

I was just reading one of the S-1 of our competitor, Ping Identity, who’s going public, and I did a text search for open source and their S-1, and the only reference I could find to it was a mention of the risks of open source software, and how the use of open-source software might come back to hurt them in the future, and therefore was a risk to investors.

Do you think there’s a disconnect somehow between investors’ perceptions of open source and the reality that you see as a technical professional using open source?

Loris Degioanni: I think that traditionally, for sure, in the investment community at any stage, starting from seed to going public, there’s been skepticism in the investment community.

There’s been skepticism because one of the things that many people say is that open source has generated less winners than expected, and not a lot of these winners have become really, really big. We could argue with it, but I’m just reporting what I’ve heard several times in the investment community.

At the same time, I am seeing more and more investors becoming sophisticated, becoming smarter, understanding what open source means, actually supporting it. I can, for example, make two examples that are extremely close to me.

I have two investors that bet on Sysdig pretty early on, Bain Capital Ventures and Accel, and in particular, my board members, Salil Deshpande, and Ping Li, and Eric Wolford, from these two firms – these are really strong open-source believers that really understand what an ecosystem means, are able to drive it, have a track record of generating successes with open-source companies.

The investors are there, the mindset is changing. I’m seeing, even just recently, multiple funds, these funds being created to focus specifically on open source. I think that the enterprise space, which is the one where Sysdig operates, is particularly ripe for disruption from open source.

I think that despite things not probably being where they should be, they are changing quite fast especially driven by a group of people that are leading the charge. In the future, we’ll see more and more of this, exactly for the reason that you just mentioned.

Open source will become, even more than now, the approach that dominates the software industry, and software is becoming more and more important. So, there’s no escape. The winners will be generated, existing players will be disrupted, and sometimes, it takes a long time, but it always has effects.

Challenges For Open Source Companies?

Michael Schwartz: What do you think are some of the biggest challenges today for open-source startups?

Loris Degioanni: Since we were just talking about funding, related to that is business model. I think that in some verticals, for example databases, we now understand the open-source model, like the go-to-market model pretty well.

We witness MongoDB, Elastic — there’s many of them, Cloudera — we witness to many success stories that essentially leverage sort of a similar playbook, or at least a variation of two or three playbooks.

In those verticals, where the playbook is understood, I’d not say straightforward, but it’s pretty clear how you approach this – open source is everything. Open source is much more than databases, and ranges anywhere from the operating system to user interface stacks, or JavaScript stuff.

I feel that in many of these areas, the go-to-market motion is less established, less proven and still requires a lot of creativity and experimentation from the founders, which also means that at the beginning, the open-source model can be relatively expensive to fund.

From one point of view, you’re focusing on your community, and that takes work, especially when you’re a small team, and takes focus. You have to do that, which means that you’re investing upfront, and you’re spending time and money upfront, have to essentially figure out the approach to market and the business model.

In my opinion, having bootstrapped, two open-source companies – that’s also the most delicate and the toughest part of the journey.

Challenges For Entrepreneurs

Michael Schwartz: One last question, because you have started two businesses, and I would’ve imagined most people who started one would know the dangers and emotional roller-coaster of that journey and not want to do it again, but do you have any advice for entrepreneurs that people going through that process of starting a business and not only starting a business but starting using open source?

Loris Degioanni: I wish I was able to say something magic that teaches people how to do this. I think that the only thing that I learned about, especially about the very, very early stages of a company is don’t give up, it’s really inch by inch.

Celebrate every little small success because that’s how you survive. You will get a thousand punches for every little success that you have. You need to cling to those because it is really a game of inches. It’s just the way it is.

And number two is, jump in the pool on the deep end, in the pool with sharks, and this is the best way to find out if you can swim or not.

I think if there’s something that makes me different from other people that maybe have not started company or have not been successful, that is, I just do it to survive. And yeah, we’ve seen what happens with Sysdig because it’s still relatively early in the life of the company.

But at the same time, Sysdig has over 200 people now. So, it’s a pretty decent-sized organization, and I still try to learn how to swim even at this stage.

Closing

Michael Schwartz: Thank you so much, Loris, for sharing some of your thoughts today.

Loris Degioanni: Thank you very much for having me. It was fun and pleasure.

Michael Schwartz: Thanks for the Sysdig team for helping to organize and promote this podcast.

Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

Have comments? Tweet at us. The Twitter handle is @fosspodcast.

iTunes listeners, send us here five stars, and please subscribe to the podcast – that really helps us get the word out.

Next week, we have Bart Copeland from ActiveState, another legendary company in the open-source ecosystem. Don’t miss it!

Until then, thanks for listening.

In this special rebroadcast episode, we revisit the conversation held by Adam Stacoviak, host of The Changelog, the renowned podcast for developers, and Donald Fischer, Co-founder and CEO of Tidelift. Tidelift offers subscription-based support and maintenance for open source dependency applications, powered by the project’s maintainers themselves. In this episode, Adam and Donald discuss Tidelift’s mission to elevate open source software by supporting both the users and maintainers of open source projects.

Transcript

Michael Schwartz: Hello, and welcome to Open Source Underdogs. I am your host, Mike Schwartz, and this is episode 34, featuring an interview with Tidelift Founder and CEO, Donald Fischer.

Tidelift’s mission is to pay the maintainers of open source software, including the developers who maintain libraries buried deep in the stack.

They have a brilliant and simple way how to do it. This is a really special episode of Underdogs because we’ve been given the opportunity to rebroadcast one of the best open source podcast teams out there.
If you don’t know The Changelog, it’s an epic podcast with currently more than 350 episodes. The hosts are Adam Stacoviak and Jerod Santo.

I’d run into Jerod at the Open Core Summit this past September. This episode is Changelog #324, which itself is a rebroadcast of the related broadcast Founders Talk, which features in-depth, one-on-one conversations with founders, CEOs, and makers.

Founders Talk is hosted just by Adam. He asks all the questions that I would have asked and adds more.

A big thank you to Jerod and Adam for sharing this interview ad-free. Thanks a lot, guys. Without further ado, here we go.

Adam Stacoviak: What’s it like to be on a mission of making open source software better, for everyone? Donald Fischer 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 the 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.

Donald Fischer: It’s amazing, actually, to be on that mission… And it sort of naturally is an outgrowth of everything I’ve been working on for the last 15 going on 20 years, actually. I’ve built my career in and around open source, in a couple of different ways, and so 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 win/win scenario for all kinds of different stakeholders in and around open source.

Adam Stacoviak: I wanna 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.

Donald Fischer: 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.

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.

Then what Tidelift does is we basically join those together and we represent them to these professional software teams as a whole product. In so doing, we essentially address two different challenges. One is that professional software teams – they need support, 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 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, and an income that scales.

Adam Stacoviak: To kind of give some – maybe I’m speaking for you in some sense, so help me course-correct what I’m saying and make sure it’s accurate, is you did a lot of interesting things with Red Hat, there’s a lot of things you and some of your team members have learned from the experiences of Red Hat, and obviously, Red Hat is one of the most successful with 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?

Donald Fischer: Yeah, definitely.

I had the privilege of being part of the early development of Enterprise Linux at Red Hat, and all my co-founders also had tours of Red Hat around the same time; we all knew each other back then and worked together and stayed in touch since then.

But honestly, 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 – if you want to put it in reference to Red Hat, it’s almost a generalization or an evolution of the Red Hat business model.

Adam Stacoviak: Yeah, where like 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 – not just JavaScript, not just Go, not just Rust, or other languages… How do you even choose where to place your focus?

Donald Fischer: 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 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. There’s a mechanism for doing that whereby we’ve built a software platform that attaches to the software development process at our customers, it 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.

So we just kind of follow where our customers are voting with their feet, so to speak.

Adam Stacoviak: And potentially their money too, since it’s a subscription.

The word alone elicits that there’s some sort of recurring payment into some sort of system that’s monthly, yearly, biannually, or whatever that might be; some sort of commitment on the long-term (or some sort of term) that says “We wanna use enterprise-level type software that’s open source, that includes support, 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?

Donald Fischer: 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, connect to our software infrastructure. Now we have a lens into what are the actual open source components that they’re using…

Adam Stacoviak: Dependencies.

Donald Fischer: 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…

Adam Stacoviak: The entire tree.

Donald Fischer: Yeah, we build the tree.

And then the way that we’ve packaged it is we charge the subscriber a fixed cost for all of the packages in the Tidelift subscription. It’s sort of like a Netflix subscription in that way, where Netflix might not have every movie that you want to watch, but if it has a lot of the kinds of movies that you like, it’s gonna be interesting for you to be a subscriber; there’s always more movies joining the catalog.

So we sort of simplify it by charging one blanket subscription price, and then we bill the subscribers on a monthly basis for that. 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 following through on those maintenance tasks around that particular package.

Adam Stacoviak: So if I’m a maintainer and I’m participating in this, my “income” or “revenue” generated from this style of funding for my project or my teams – is that number coming from Tidelift, does it ebb and flow then because of that? Or is there some sort of barrier or predictability they can have into how they can begin to step away for their full time job or do this full time, or whatever it might be? How do they understand the income that’s possible, and even not just possible, but on a day-to-day or month-to-month basis, how does it ebb and flow?

Donald Fischer: This is actually one of the fundamental reasons why we started the company, and one of the fundamental contributions that we wanna make – 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 gonna be paid tomorrow, or especially if your income is 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.

It doesn’t mean that your income could never ever go down in the Tidelift system; as I said, we pay the maintainers based on subscribers using their software, so if all of a sudden none of our subscribers are using that software anymore, the amount could go down. But in reality, once software is in place, it tends not to go anywhere; just new software gets added.

On the other hand, we’re growing quickly, the audience of participating subscribers, so the total dollars in and the number of potential teams that might be using your project for any given maintainer is increasing. We think that what will practically happen as a result of this model is 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 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.

Adam Stacoviak: I wanna rewind a little bit back to the dependency tree that you mentioned, just for those listening who may not be 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 it just kind of helps to get a lens into the dependencies of dependencies; so when you have an open source project or just a project in general and you’ve got an application you’re building, 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 their dependencies, and it probably points out some opportunities to grow as you’ve mentioned you are.

But I kind of wanna just touch on that a little bit, because not everybody listening to this is that familiar with the software process and what dependency trees actually are, 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?

Donald Fischer: Yeah, that’s right. The issue of the lack of appreciation or really understanding of how much software exists below the visible water line is really remarkable.

For example, we recently wrote on our blog about look at React – super popular web front-end framework, born at Facebook. If you go through the prescribed Hello World creating a new React application, using the very well-executed Create React 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 we that we looked.

So that’s over 1,100 distinct packages coming out of the Npm JavaScript package catalog. Those are coming from a lot of different places. A couple dozen of those are coming from being authored by the Facebook React engineering team.

But the beauty of open source software is that the vast majority of those are coming from somewhere else, from somebody else. But all of them are getting built into your React application.

So if you’re a professional software team at a large enterprise that has 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 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. That’s really the meat of what we’re trying to do.

Adam Stacoviak: An example that – I’m not sure if you’re familiar with Nadia or not, but Nadia Eghbal, when we first learned about her was several years back, and we’ve since done a podcast with her called Request For Commits.

Donald Fischer: I’m a long-time fan of Nadia’s and the show. I recommend it to all of your listeners who have not yet explored those paths.

Adam Stacoviak: And it is retired, so when you go listen, just know that, and send us your hate mail; we wanna hear more of it, because we wanna do more around sustainability of open source, but that show just is in a retired state, for its own reasons. But the last episode does tell you why, so if you’re really curious, just listen to the latest episode.

But you know, she’d written about the economics of open source, and the example she used was the rate at which Instagram was able to become a billion-dollar company and then be acquired by Facebook – I don’t mean to keep going back to the Facebook well, it just happens to be that example. But 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 don’t know what Facebook’s involvement is, and they’ve since acquired Instagram, but that was the initial yardstick, at least by Nadia, on like, you know, Instagram was worth – the acquisition was like four billion? One billion? I can’t recall right now. It was like 4 billion dollars from Facebook, so somehow they got to that value and they were built upon open source software.

So going back to your model – we have this economic need of all these dependencies, and they would have never been able to get there building all the technology on their own. They had to lean on open source. So there’s a responsibility there to support the dependencies beneath the tree.

Donald Fischer: Yeah, there’s a couple different ways to look at it, honestly. One lens of looking at it is to say if you’re building on all of this software, 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 a very reasonable worldview. But it’s hard to get large organizations to open up their checkbooks for things that are purely morally justified.

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 as 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 Tidelift’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 Tidelift 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, 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.

Adam Stacoviak: So you say “professional software teams” – I think I know what you mean when you say that, but put it in laymen’s terms for me and the listeners. What is a professional software team as it relates to what you’re doing with Tidelift?

Donald Fischer: When we say “professional software team”, we’re typically referring to a team building software within an enterprise.

Enterprise is kind of a silly IT word, or entrepreneurship business word; it means a company, and often times like a larger company. 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.

If you’re an indie developer – I mean, I started working with open source, getting involved in open source when I was a student. 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 of mega-corps that are building with open source as well, and those different audiences have different needs in and around the software that they’re using. When I’m doing a side project on the weekend, kind of cobbling together some open source components to sort of scratch my own itch, for sure I do not need an enterprise support contract, I’m not super-focused on intellectual property documentation for this thing that’s only ever gonna 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 would love to have some additional guarantees around that software.

So the open source software, 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, 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 gonna happen with the software in the future – is somebody gonna keep caring for it, and taking care of this essentially living organism that the software projects need to be, as the world evolves over time?

Those are the things that we think that professional teams need, that not all open source developers need, but professional teams do need it, and as a result, they’re willing to pay for it. 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.

Adam Stacoviak: 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?

Donald Fischer: 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 a really compelling opportunity on the creative side of open source to also, in a sense, professionalize there. And I wanna be careful about what I mean by that word, professionalize. Open source maintainers, whether they’re paid or not, it is demonstrably true that they create amazing software that is prograde, is used in real-world applications all over the place.

I guess a missing part of the “professional” definition there is that often times 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.

So I do think there is a double entendre there, which is “We would love to help open source maintainers make it their profession,” and that’s really one of our ambitions with Tidelift – 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, 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 gonna benefit, because the software that we all use is gonna be better. It’s awesome.

Adam Stacoviak: 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 it in that context, which is why I opened up with that question. Because I wanted to understand more so like when you focus your attention on – I know that a lot of your subscribers are the ones that are leading you to, down the dependency tree which matters to them, because they’re paying for the subscription, and essentially, 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 you that question to think that maybe you’re describing a type of maintainer, a type of maintaining team, their philosophy, the way they organize, the way they govern, what are healthy balances in there… I thought that’s what you were talking about, that’s why I went that direction.

Donald Fischer: Yeah, so just to comment on one really fun part of what you were touching on there – I think the really happy news here is that teams inside of larger enterprises that have the requirements for security, licensing, maintenance kinds of assurances around the software that they use. It turns out the software projects that they’re picking to build their 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. They’re using the same components at a big bank that I’m using to do my weekend project.

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 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 improvements or increases in functionality – that can be shared by everybody, the payers and the non-payers. That’s actually one of the beautiful things about open source.

Adam Stacoviak: That’s why I love your name, Tidelift. That’s the underlying (to keep the puns going) current of what you’re doing here; you enable subscribers to lift the tide of everyone. Like you said, I could be using whatever the library may be that’s part of the Lifter project you have going on, 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 subscription, and then therefore funding of those maintainers in those projects. I love the name, it’s spot on.

So we spent the better part of maybe 40-ish minutes kind of digging into the context. I wanted to go into more of the getting started, where the idea came from, some of the background even, which is sort of like the crux of what this show is really about. Which I love doing – 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 get a picture of some of your personal experiences, and maybe the experiences of other team members. But maybe let’s start off with back in 2017 when this began – from what I understand, 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 go back to those details and help pave the way for how this got started?

Donald Fischer: My personal history briefly is I started out as a programmer, I studied computer science.

As we talked about before, I had a really interesting tour at Red Hat starting in the early 2000’s, 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 under-appreciated in the IT industry.

Adam Stacoviak: Absolutely.

Donald Fischer: Red Had as a whole is an over three billion dollar recurring revenue business now. It’s really a beautiful and amazing thing, and there’s a lot to be learned…

Adam Stacoviak: Did you say billion?

Donald Fischer: Yeah, three billion dollars a year in revenue.

Adam Stacoviak: Three billion… Just to make you say it twice, because that’s pretty big.

Donald Fischer: Yeah, it’s big.

And you know, it just steadily grows. It was an amazing 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, and that doesn’t just come for free. And we’ve figured out a model that was appropriate for that set of technologies at that time, and it has continued to evolve to support a steady business today.

What I did after Red Hat is I’ve spent almost a decade as an 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 technology will come from a creator or a small band of creators, and then a crowd of individuals will start to kind of assemble itself around that technology.

You see technologies sort of form these tribes, and when I say tribes, I mean in a good way… Not in a tribalism kind of way, but in a sort of…

Adam Stacoviak: A Seth Godin way.

Donald Fischer: …collective way, yeah. It’s really amazing.

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

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 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?

I think there’s a really fortunate history of startups and businesses of different scale being built over the last 15 years now that do that, and that’s just been a phenomenon that I’ve loved to follow, and sometimes to be part of.

Adam Stacoviak: I think the important thing to draw from this is it seems to me that you’ve spent 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 ways leading product, because that’s also part of the investor’s role, is to be somebody who is an adviser to the direction of the business and the viability.

I think the other important thing you said there was that you’re the support, rather than – I forget the exact language was that you used, but essentially, you’re there to amplify versus to draw and take away from the energy. What was the word you used of how you’re not attaching to the community?

Donald Fischer: I think the language that I used was instead of trying to harvest energy from these communities, it’s like “Can you actually build an engine that contributes net energy back to the community, that helps it grow and become more sustainable, as opposed to sort of drawing energy off of it?”

Those are the really powerful companies, and also I think they help to form really powerful communities.

If you look at the different businesses that have been built around Linux, or different big data technologies, or core 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 to connect that to the story of Tidelift, I’ve been a student of that phenomenon for a long time now, and I’ve had the great opportunity to work with a number of other folks who are also fascinated by the same kinds of dynamics.

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.

Adam Stacoviak: Yeah.

Donald Fischer: 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 – often times the users that they had were asking them for “Hey, can 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 level one support team and so on.

So when I started talking to my co-founders, the gentlemen who eventually became my co-founders at Tidelift, we looked at that problem and 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 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?” Sort of like in the way that creators plug into Etsy.

You know, one of the beautiful things about these marketplace models is if you’re amazing at creating some craft good, you can go to Etsy, and Etsy helps you access an audience of people who are interested in your kind of thing, they handle all the payments, and the logistics, and customer service issues and so on, and you don’t have to go learn how to do all of those things. Etsy is kind of your partner for doing that. You get to focus on conducting your craft. That’s one of the things we’re trying to do with Tidelift – we wanna make it possible for open source teams who are building technologies that are used by these 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, in the sense of do that for you, as the open source creator; you plug into our infrastructure and you focus on making the open source project amazing. We’ll help with all the bunch of the business stuff.

Adam Stacoviak: These teams generally would still have to be the ones providing the service-level agreement, right? If I understand correctly, you may institute it and do the business-level side of things to ensure that there are subscribers that have desires to bring on certain lifters or whatever, but it’s still the lifter’s job – which is a term we haven’t defined yet, so maybe it’s a part of your response, to help me understand really what a lifter is, or what that role is there. Because they’re gonna have to eventually support that software, and provide the enterprise-grade stuff that you’re selling as part of the subscription. This whole general sales thing – that’s what the product is, it’s reliable, it’s supported, bug fixes etc.

Donald Fischer: The way that it work is that 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.

A couple 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 1,100 Npm module maintainers 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. And what we ask the maintainers to do – it’s actually detailed on our website, for any maintainers who are interested in 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 is a new security issue that arises, sort of 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, 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. So since that’s already possible in the world, we’re trying to focus on sort of a new model, which is doing things that can be done once where many people benefit from them, like 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 we do ask our participating maintainers (lifters, as we call them) to do those things, and then Tidelift’s role is to make sure that everybody is following through correctly, deal with any kinds of issues that come up.

Adam Stacoviak: 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, that they say “Okay, Tidelift, we wanna be a part of this, we wanna be a lifter. Sign us up, we’re ready to go,” and then there’s something in these well-defined standards that says “Hey, this is what you’re committing to.” Is that accurate? Can you describe that?

Donald Fischer: 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 – most open source projects that have a substantial user base are already doing most of these things, or all of these things.

This is things like having a responsible disclosure policy and adhering to a responsible disclosure policy around security incidents, or 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 is participating in the Tidelift system is doing all of those things, it allows us to represent that this collection of software as a whole meets those standards to our subscribers.

And again, that’s worth a lot to these professional software teams that are building enterprise applications; if we can show them a menu of healthy open source project attributes that we’re ensuring are true for the dependencies that they use, they love it. And it’s a modest cost for them to pay, to ensure that the software that is really powering their business is well cared for.

Adam Stacoviak: 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?

Donald Fischer: Yeah, 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.

I have three co-founders – Havoc Pennington, Jeremy Katz and Luis Villa. We’ve all known each other pair-wise 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 2000’s, 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.

I talked about my background a little bit; a lot of it is sort of the business side of open source. Havoc, our co-founder, currently is leading Product for us. He is a long-time veteran of the open source world. He was originally one of the founding voices in the GNOME Freedesktop community, the Linux desktop, and co-led the creation of the GNOME Foundation, which continues productively to this day, and implemented a lot of the software himself that powers the GNOME desktop.

I got the chance to work with him first when he was leading the desktop development team at Red Hat. Then Havoc 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 sort of the greater Java world, and then most recently was back in the Python data science community before we got together to start Tidelift.

Then the third co-founder is Jeremy Katz. Jeremy is an amazing technologist. I got to know him when he was one of the core developers at Red Hat, then he went on to sort of grow his professional portfolio beyond just open source – he was an early employee at HubSpot, the marketing SaaS company. He led the implementation of this product called Stackdriver, 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, Luis, has (I think) the most unusual story, which is Luis started with the rest of us as a programmer, open source developer, but Luis ended up going to Law School, and then closing that loop by becoming an open source legal expert, really, one of the 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, 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 backgrounds and professional experiences, grounded in having all been open developers, software developers, and open source participants in the early years. I guess what we’re trying to do is bring 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.

Adam Stacoviak: It’s an interesting mix of people. Obviously, you’ve got business, you’ve got — I’m sure everyone was somewhat involved in coding, at least at some point in their life, but taking a role on that, having a role in Google and what powers that, and then legal; the licensing part of open source is, to some, often overlooked, but pivotal to how it could be used.

We see license changes in business; there’s some recent news not long ago with Redis around Commons Clause, or License Zero. All those things have implications. And even React – because you’ve mentioned them earlier, and we even logged that, about who actually supports React.

They had – I’m not sure of the details because I don’t follow this closely, but it had some concerns around the community, the way Facebook licensed React. We’ve even had Heather Meeker on Request for Commits, since you’ve mentioned that earlier, and with Nadia – we had a deep conversation around the importance of licensing.

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 even more interesting that you all intersect at Red Hat.

Donald Fischer: Yeah. I mean, I just feel so privileged to work with these gentlemen, and then again, the team that we’ve brought aboard to share this mission with us; it’s a lot of fun. But to the point around licensing – the legal code is one of the technologies that makes open source possible.

It is sort of a technology onto itself, and like other technologies, it’s complicated. It’s complicated for the creators to make the right sets of decisions around “Which license should I use? What are the tradeoffs?” and so on. It’s also really complicated on the consumption side, and that’s (again) one of the things that we’re trying to help address for professional teams that want to engage with open source in the right way.

They don’t have the time to each go become an open source legal scholar like Luis did, so we’re gonna try to create some tools and standard ways to approach this, that let them get the advantage of some of that substantial knowledge that Luis has accumulated in his days.

Adam Stacoviak: 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, 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. And 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. No, we’ve been boots on the ground for decades, and our resumes and the work we’ve done before” is what you point to to prove it.

Donald Fischer: Yeah. I mean, the only caution there is that every situation is different. One of the things I always try to remind myself is to learn from the past, but not to over-apply models from the past, because sometimes they can be misleading. The world changes.

The world is a lot different now in 2018, in terms of where open source is in the software ecologies in general versus 2002. Back when we were doing the first version of the enterprise Linux business model in 2002, most professional companies looked at Linux and said “This thing looks crazy. What do you mean free software? How could this possibly work?” etc.

Now, fast-forward 15+ 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, but 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?”

Adam Stacoviak: Right. Who is responsible, yeah.

Donald Fischer: Yeah, and who needs it to happen, and how do we connect the dots?

Adam Stacoviak: Well, let’s close the loop on this idea of sustaining open source, maintaining open source, this phrase that often gets put out there and talked about, and the actual mechanics of what that really means. There’s other models out there, and every model is needed, because you said earlier “Hey, if money is coming in open source – great! Let’s not say one way is wrong or right”, but I wanna kind of go into the differences of other models.

We’ve talked to Pia Mancini on here before around OpenCollective, we’ve talked to Eric Berry around CodeFund, previously CodeSponsor… I haven’t talked to anybody from Patreon before, but we’ve definitely talked to Evan You on Request for Commits and several others. Henry Zhu from Babel on how they’re leveraging their ability to go full time and using those platforms to really good advantages.

But then here comes Tidelift – so what is the biggest difference between Tidelift and other models where they could be seen as like more charity, or somewhat value-based?

Donald Fischer: First of all, just to get on the table – the more, the merrier.

Adam Stacoviak: Right.

Donald Fischer: I’ve said it before, I think every channel to pay the maintainers is additive, and so we’re just trying to add another option into the mix, and probably “the answer” is not one of these, it’s a polyglot solution of multiple of these working in different ways.

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 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 gonna care for this software.

And when we say “care for the software,” it’s written down what we mean by it, and if an issue arises, I’m gonna have someone to go to; they’re committed to work with me. So 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, we’re more oriented towards these software teams within enterprises. That’s not particularly compelling to most 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 there’s a bunch of other options on the table.

By the way, as a hobbyist developer on the side myself, I happily contribute to a number of different 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.

Adam Stacoviak: I definitely echo what you’re saying on “the more, the merrier.” One question I have for you though is like, since you’ve said you’re a listener or this podcast, and you listened to 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 used in that show was Jack Lukic, who was the creator of Semantic UI, which we actually use here at Changelog; it’s the UI framework we use for our back-end.

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, maybe really great with the framework, and that’s all he may really wanna do, but he’s hit a stopping point of time invested because of the lack of funding. So in the Tidelift model – and maybe Jack is not the perfect person. Jack may be considered a hobbyist, even though his project is used tremendously, and very vital to so many projects that are using it. But he may not have the time or the desire to wanna do the other things to support or to be in the Tidelift model; how does that fit in?

Donald Fischer: I think if I was to rephrase the question, it’s like “What if the open source maintainer or team isn’t interested in doing the Tidelift-style maintenance?”

Adam Stacoviak: Assurances, yeah.

Donald Fischer: We sort of look at that, again, from the – think about it from the open source user’s perspective. The user is still interested in having somebody 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 help with some of the day-to-day maintenance tasks,” especially if everybody else has already passed on volunteering to do those things, usually they’re accepted with open arms.

So I think that our model can potentially help in those scenarios by giving someone else a nudge to sort of show up and volunteer… It’s not really volunteering, because they get paid to do it.

Adam Stacoviak: They’re getting paid!

Donald Fischer: Yup. “Pay the maintainers” is our mantra.

Adam Stacoviak: I like that tagline a lot. It’s short, it’s three words, it gets to the point. Pay the maintainers.

I like that. And you said “The more, the merrier”, I think that’s what everyone is saying – 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. 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 feel depleted 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.

That’s what 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, just because of the way the market worked. There’s all these different ways, but this is just one of several ways we can pay the maintainers, and I like that mission a lot.

Donald, we’re coming to the close here. I’d like to end with this question. Super-secret – something’s going on at Tidelift that maybe people aren’t aware of; you know, I don’t know. Is it 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.

Donald Fischer: Yeah, I’ll just mention a little tease.

We’re gonna have some really exciting to us, and I think relevant news coming out in the next couple of weeks, talking about getting to a certain kind of scale milestone on the Tidelift platform. Stay tuned for that.

Stop by Tidelift.com, depending on when you’re listening to the podcast, to learn more about sort of showing the model working at some interesting scale that we think people will find compelling.

Adam Stacoviak: When you say “milestone”, it means the big deal, right? So this is a big deal.

Donald Fischer: It means we’re reaching another waypoint on our journey to demonstrating the Tidelift model working at scale… And paying the maintainers.

Adam Stacoviak: Gotcha. So even if you’re listening to this distant in the future, and this announcement has since passed, we’re gonna update the show notes for what Donald is 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 those up to date.

Donald, anything else in closing? It’s a fun journey that you’ve been on, from your history in open source, all of 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.

Anything else you wanna say in closing to the listening audience that may be interested in the journey of open source and what it’s about?

Donald Fischer: First of all, I would just say thank you to you, Adam, and to the 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. I guess that would be my parting thought – these issues are important. As a lot of folks now have pointed out – you referenced Nadia did an amazing job shining a light on the importance of open source software…

Adam Stacoviak: Yeah.

Donald Fischer: We have now decided 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 to be great, and that means we need our open source software to be great. I’d just invite everybody who is 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. 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 putting this in front of an interested audience, Adam.

Adam Stacoviak: Absolutely, man. Thank you so much for saying that. This has been a labor of love for many years, turned business, and we’ve been fortunate in that. And if it weren’t for our listeners and those contribute to open source, and this entire community, we would not be able to exist obviously, because there’d be nothing to talk about.

But we’re just so thrilled that we get to be in this position; we’ve been down a long road, and I’m honored to have 1) you on the show, then 2) you as a listener… And when I mentioned things, even in the breaks, you were like “I’ve already listened to that.” I didn’t know that you were that passionate about – you know, sometimes people say thank you, but you’re an actual listener, who listens to every show, or at least a lot of them. That’s awesome, I love that.

Donald Fischer: Keep up the good work, man.

Adam Stacoviak: Thank you, Donald. It was a pleasure, and I really appreciate it.

Donald Fischer: Thanks for having me on.

Adam Stacoviak: All right. Thanks for tuning in for this week’s episode of Founders Talk. Do me a favor, assuming you’ve got some value from this episode, share with friends, rate this show on iTunes, favorite it on Overcast – this is the best way you can help me and this show, and help others to discover it too.

Find all our shows at changelog.com/podcast.

Subscribe to the master feed changelog.com/master. Get every single show in one feed.

Thank you for tuning in – I’ll see you on the next one.