Invest Like the Best with Patrick O'Shaughnessy - Chetan Puttagunta and Jeremiah Lowin – Open Source Crash Course - [Invest Like the Best, EP.188]

Episode Date: August 25, 2020

My guests this week are Jeremiah Lowin and Chetan Puttagunta. Jeremiah is the founder of Prefect.io, an open-source software company where my family and I are investors, and Chetan is a partner at Benchmark Capital. Both are past guests and good friends. I asked them on to help the audience understand the open source software business model. I’ve been fascinated with this model in which companies give a huge chunk of their work and value away for free to a community of developers, and then make money by building additional tools, functionality, and services on top of their free and open platform. While this may strike you as a wonky discussion on a niche software topic, I think it is valuable for everyone because the ideas can be applied to more than just code. I view much of my own activity as open-sourcing investment research and knowledge. It is also important because much of the world’s technology is built on top of open source projects. I hope you learn something new about this emerging category. Please enjoy.   This episode of Invest Like The Best is sponsored by Canalyst. Canalyst is the leading destination for public company data and analysis.  If you’re a professional equity investor and haven’t talked to Canalyst recently, you should give them a shout. Learn more and try Canalyst for yourself at canalyst.com/Patrick.     For more episodes go to InvestorFieldGuide.com/podcast. Sign up for the book club and new email newsletter called “Inside the Episode” at InvestorFieldGuide.com/bookclub. Follow Patrick on Twitter at @patrick_oshag   Show Notes (2:40) – (First question) – Originator business in open source software; Redhat (5:51) – Why open source is valuable in building a business (7:40) – Examples of the benefits of open source projects (10:27) – Open source business models that produce the best results (17:04) – Defensibility of open source companies (25:02) – Mentoring younger founders on using open-source (30:54) – The benefits of launching open-source (36:41) – Building a digital community (41:31) – Lessons from Open Source that can be applied to other businesses (50:04) – The opportunity sets available in the open source space (53:33) – Future of open source             (56:31) – Tobi Lutke Podcast Episode   Learn More For more episodes go to InvestorFieldGuide.com/podcast. Sign up for the book club and new email newsletter called “Inside the Episode” at InvestorFieldGuide.com/bookclub. Follow Patrick on Twitter at @patrick_oshag

This episode is sponsored by Canalyst. Canalyst is the leading destination for public company data and analysis. I'd heard of Canalist over the past few years and became more interested after meeting the founder and CEO last year to pick his brain about SaaS businesses. Founded by a former by-side analyst who encountered friction in sourcing, building, and updating models, Canalist is now used by over 300 institutions, including the largest money managers in North America and by a number of guests on the show. with detailed company-specific models on over 4,000 public companies,

Canalist platform lets analysts update their own models in seconds, complete with KPIs and segment data, adjustments, and restatements. Everything you want and expect in your own models on virtually every investable public equity. If you're a professional equity investor and haven't talked to Canalyst recently, you should give them a shout. Learn more and try for yourself at canalyst.com slash Patrick. That's C-A-N-L-Y-S-T-com slash Patrick. Hello and welcome, everyone. I'm Patrick O'Shaughnessy and this is Invest Like the Best.

This show is an open-ended exploration of markets, ideas, methods, stories, and of strategies that will help you better invest both your time and your money. You can learn more and stay up to date at investorfield guide.com. Patrick O'Shaughnessy is the CEO of O'Shaughnessy Asset Management. All opinions expressed by Patrick and podcast guests are solely their own opinions and do not reflect the opinion of O'Shaunacy Asset Management. This podcast is for informational purposes only and should not be relied upon as a basis for investment decisions. Clients of Oshonosia asset management may maintain positions and the securities discussed in this podcast.

My guests this week are Jeremiah Loan and Chathin Putagunta. Jeremiah is the founder of Prefect.io, an open source software company where my family and I are investors, and Chathen is a partner at Benchmark Capital. Both are past guests and good friends. I asked them on to help the audience understand the open source software business model. I've been fascinated with this model in which companies give a huge chunk of their work and value away for free to a community of developers and then make money by building additional tools, functionality, and services on top of their free and open platform. While this may

strike you as a wonky discussion on a niche software topic, I think it is valuable for everyone because the ideas can be applied to more than just code. I view much of my own activity as open sourcing investment research and knowledge. It's also important because much of the world's technology is built on top of open source projects. I hope you learned something new about this emerging category. Please enjoy. So Chathin and Jeremiah, thanks so much for doing this with me today. Our topic is going to be a single topic, deep dive on open source software and the

businesses that surround open source software, which has become a category that I'm personally fascinated in. I know obviously Chathen you've invested in some of the biggest companies in this space, and Jeremiah, you're building one. So I thought this would be a neat group to get together. As a jump off point, Chathen, I would love for you to describe. sort of the originator business in this space, which was Red Hat, as a way for the audience to understand sort of what's distinct about this sort of business model. I think one of the things

that's pretty interesting in the history of the firm that I work for, Benchmark, is that Benchmark was an investor in Red Hat in the very first benchmark fund. So Benchmark One was an investor in Red Hat. And the story of Red Hat itself is particularly fascinating. And as we look at what has happened 25 years later, frankly, in terms of the evolution of open source, which we'll get into here. It's pretty interesting how far sort of open source has come and how sophisticated it's become from where Red Hat started. And Red Hat is a particularly interesting story because in 93, Red Hat was actually two different companies that came together. One was a catalog business that sold Linux and Unix software accessories. And then a second business, which was actually

Red Hat Linux, which was its own Linux distribution that Mark Ewing had started. The two companies actually came together in 1995, and that was how Red Hat, the software company, came together. Red Hat became public in 1999 and lost in sort of the history, but Red Hat had, I think, like the eighth biggest or the 10th biggest first day gain in the history of Wall Street. I mean, it sort of brought this open source business into the limelight in such a dramatic way. And what's also pretty interesting about the first benchmark fund is that the group had also invested in MySQL, which had also been pioneering the open source business, which, of course, then Sunbought. I think that Red Hat starting in 95 and then four years later becoming a public company and having this huge spike on Wall Street,

it being categorized as this unbelievably disruptive force where you had this open source operating system and you had a corporation that was behind it that had the wherewithal on the balance sheet to support the R&D efforts to push the open source community forward and you had all this developer excitement around what Linux was and what Red Hat Linux was. And then, of course, Red Hat went through its own evolution

as a business and over a period of 25, years pretty dramatically transformed. And then ultimately, of course, IBM acquired it for $34 billion in 2018. But I think that announcement to the world, if you will, where it formed and very quickly become a public company and got so much public attention, I think was a real firestarter for thinking about open source as an incredible commercial business model and software. Jeremiah, since you're actively building a business that has a sort of an open source at its base, maybe you could describe why you think it's a valuable thing within a business versus as a version of Prefect that's not open source, it's just a software product. Talk us through a little bit

how you think about it philosophically. So open source is a very complicated thing, especially if you haven't encountered it before, because it can be something that's critically important to you that you can look at the source code of software that you're working with, or you actually might not care and you might only benefit sort of implicitly from, say, a network effect or other benefits that come from it. I think the critical thing about open source software is actually not that the source code is available. It's rather what that represents. So by making your source code available, you can affirm some degree of trust with the community.

You can, of course, invite contributions into the source code. You can make it very easy for people to deploy that source code and customize it to their needs within an environment without the sort of corporate sponsor being involved. But more than anything, I think it's about reach for a young company, especially one like ours. And as we've open source more of our stack, we've certainly experienced that. And I think if you think about a marketing budget versus the fact that we have an engaged open source community, one's a compounding activity. And one is just the pursuit of ROI, sort of blindly. If there are dollars at this, maybe people see it, maybe they'll buy my software.

And so one of the motivating things is this ability where if one person in the community likes it, they can tell another person, there's no barrier to entry. They can, maybe that's the person who's going to contribute to the software. Maybe that's the person who's going to extend the software. Maybe that's just a person who will attract the next person. But that idea of almost, I don't want to say free because an awful lot of effort goes into maintaining a healthy community, but it's a very qualitatively different experience about expanding the reach that the software can have than I guess a more traditional model. I'd love Jeremiah just very briefly for you to make this a little less abstract for those listening and just give an actual example using your

company. So obviously people use something because it's useful, as you guys have both said. said, something is hired to do a job, especially in software. This isn't really for entertainment purposes. So in the case of the open or free product, what job are they hiring, say, Prefect to do? And then on the paid layer, just give the example that slots into everything you just said, which is you're not competing with compute and storage. You're providing an ancillary service, but that nonetheless needs to be a paid service. Sure. So Prefect's open source project is a workflow engine. It's a workflow management system. You use it to achieve a goal that you have, which is to to make sure that code is run at a certain time

in a certain place in a certain way. That's what it does, and we give that away. We open source it and anyone can run it. Our proprietary services, we describe as an insurance product. We actually divorce it from the idea of running the workflow. Its actual job is to deliver as fast as possible the knowledge that something is wrong, to put it bluntly, like any insurance product, and to protect from it.

Now, we deliver a version of that in an open source form, But specifically because it's a risk management product, Patrick, as you know, I spent my whole career looking at risk management stuff. The devil's in the details on making sure that this stood up in a very specific way to make sure it's robust, highly available scales at any time, is secure. These are all things that can be done, but they're very hard to deliver in an open source way that's infrastructure agnostic, which is one of the things that we try very hard to do in our open source.

And it's very hard to teach people and sort of read me how to do this. Instead, we hire people who have deep expertise in doing these things and we employ them in order to deliver this insurance product to our customers. When we go out and we ask people, what value do they get, our paying customers, what value are they getting from using Prefect? We hear nice things about the workflow engine. It's easy to use and save some time and stuff like that. But ultimately, the stories always revolve around, oh, and then there was this one time when something went wrong and woken up by Slack and whatever. And it's this very real moment where without the software in place and being governed by us and monitored by us, there would have been a real consequence. All of a sudden, we are delivering that real value, which in a funny way has actually nothing to do with the open source, except for the fact that the open source allowed this person to very easily describe what it was that they wanted us to do.

So our open source, that's actually a good way to describe it. The open source is a way for people to inform us what they want us to do. we redeliver that proprietary platform in an open source way, but our challenge is to make sure that we deliver it to our paying and our enterprise customers in a way that scales across their entire organization plugs right in with as little configuration as possible. Chaythin, I'm curious in all the companies that you've backed that have pursued this model, if you have an opinion about what tends to produce the best business outcomes. There have been four companies that have invested in that have had in our sort of like venture

Capital World, we think of as quote-unquote exits. So MongoDB, Mulesoft, Elastic, the company behind Elasticsearch, all have become public companies. Salesforce ended up buying Mulesoft in early 2018 for about $6.5 billion. And then I was also involved in Aquia, which is the company behind Drupal. And that company was acquired by Vista Equity for a little over a billion. So I would say that if you looked at those open source companies and how they went about creating an open community and an open adoption mechanism. I think what was available to these companies, call it in the late 2000s and the early 2010s,

is likely unavailable today. In the late 2000s, it was a totally viable business model to say that I'm going to have a completely open software and the way that I'm going to monetize is offer services and quote unquote enterprise tooling for enterprises that they can run on their own data centers or their own servers and as startups try to build up their own data centers, I'm going to help them get up to speed with this open source project

and then that's a potential way for the commercial entity to support the open source project. And as we have all become very aware of, the cloud has become its huge powerful force in the enterprise software market. And if you just look at the three, large cloud vendors of AWS, Azure, and Google Cloud, public cloud is becoming such a big market. Open source companies have had to evolve in how they think about not only licensing,

but also how they think about going to market. And I know this is something that Jeremiah thinks about on a daily basis. And if you look at somebody like a MongoDB, the way they've thought about it, is that there is an enterprise product that you can run if you choose to operate your own data centers. But they have another product, called Atlas, which is MongoDB's cloud, which essentially allows you to run a managed MongoDB where MongoDB, the company, takes care of all the sort of administrative things that come along with an operational database like replication, security, auditing, scaling, provisioning, etc.

And through Atlas, your company or customers, able to provision and run and manage MongoDB clusters across Google Cloud, Azure, and AWS. And so they can run it in multiple regions. They can run it across multiple clouds, and they provide that service. And if you look at MongoDB's business today, Atlas is by far the fastest growing segment of the company. The introduction of cloud and how fast cloud has come on the scene has introduced not only more opportunity, but it's also forced an evolution in how we think about open source and

how we think about the business of open source. How do you react to that, Jeremiah? I'm just curious if that lands for how you think about prefects, pricing, and business strategy. It absolutely does. I mean, I don't think I just think about that daily. I think about like hourly and minutely too. I was talking with someone yesterday whom I respect incredibly as a businessman, but to whom open source is a new idea. And he said to me, he said, I may be old fashioned, but it seems to me you make a lot more money if you charge for your software than if you give it away. And I think the extension. of that from what Chaitan was just saying is you have to actually know what you're selling. And the answer is you're not selling the same source code that you put up. You're selling some extension of that. So in the case of Atlas, what you are selling is the convenience of the managed infrastructure or to put it differently, the opportunity cost or the pain of figuring that out on one's own.

So essentially, as an open source business, you're looking to profit from where you can deploy expertise in the form of convenience that someone would otherwise have to incur cost anyway. How you do that and how you do it in a genuine way, I think is one of the challenges. Because if you think about it, there's a bit of perverse incentive there. And I think we can all think of open source projects where it certainly seems like they went out of their way to make it hard. And of course, so that you can be sold the easy version. And I think at the end of the day, especially with the explosion of open source and, as

Chatham pointed out, the explosion of readily available computer resources. to spin these things up, people aren't dumb. They don't fall for this. We talk about dark patterns and websites all the time. There are dark patterns in open source software as well. Avoiding that is, I don't even want to suggest that we think about this as something we need to avoid. It's something that we're sort of committed to making sure that we avoid because you never want a customer to feel like they're held hostage for any business, not just open source.

Customers will always pay for something that alleviates some pain. You just need to make sure in a genuine way that you're not delivering that pain in the same moment with the other hand, you take money to alleviate it. And so this is one of those weird dynamics of the open source world where I think going back to some of those ideas from earlier about just building trust, building a welcoming community, making it clear that you have your user's interests in mind, even as you build a business, is really important.

So I firmly agree with everything, Jay from saying, I think that this is sort of the great conundrum of building open source companies. And then to pivot that a little bit, if you think about other perverse incentives or something analogous to it, starting an open source project is less than free, by which I mean anyone can put up any code that does anything and just say, hey, this is my open source project. We'll figure out the business model later. So it's not just that the barrier of entry is low for a software. The barrier of entry is negative for young open source projects because I love shiny new software. I love to play with it, but you'd have to be out of your mind to use something that was just put up by somebody. You don't even look at the code. These same things that I was talking about earlier, having the code available creates trust. creates an environment where you can demonstrate goodwill, it can also be abused. Many times when we talk about open source companies, we look at the ones that were successful or that worked, we're cherry picking a small number of outliers from probably a much larger

denominator than we would even see in a more traditional environment because we can actually wait and see the cost of doing this is so long. Just wait and see this is gaining traction or that's not, if we're a VC, we can invest in this. For users, we can begin to adopt it. It's just a very different than even what we'd see in a more traditional software world. I'm curious how you guys think about Chathen, especially, defensibility of these companies. So it seems like in the early days, they could be really useful tools,

have powerful and loyal communities, solve very specific, maybe developer facing problems. But once they start to grow, I would think that some of these bigger players, literally the source codes available, like it would be especially easy to fast follow or co-opt or just replicate some of these services

and stash them on AWS. or something like this. So how do you think about the defensibility of open source businesses as they scale, Jathan? We have now gotten the most uncomfortable topic, I think, in the business of open source, which is how do you coexist as an open source company in this new world where you basically have three extraordinarily dominant public clouds? The open source theme of what does it mean in terms of IP and what does that mean in terms of defensibility from an IP perspective? What does it mean from a technology perspective and what does it mean from a customer retention perspective? I think we have to take a step back and really think about that's sort of like huge tailwinds that are happening

in enterprise software and then aligning those tailwinds with core strategy. Ultimately, what is the point of an enterprise software company is to provide a utility to a customer. When a customer engages in enterprise software company, they are in essence hiring that enterprise software company to do a job. And so ultimately, whether you're an open source company or a close source company, you have to fulfill a task for a customer

and help the customer accomplish something. Now, that is if you want to create an open source business. Now, if you just want to create an open source project that's just neat and you want to just put out in the world, you have completely different considerations. let's just talk about the bucket of just thinking about open source as a business itself versus open source as a community project. So open source as a business, you have to think about the tailwinds that are happening in the enterprise software world that you can then align yourself

with to ultimately deliver a service that is extraordinarily much better than the close source alternatives. And I do think that the open source companies that have broken out, and what Jeremiah just said is absolutely correct, which is that the number of open source companies that have become very successful businesses as a percentage of total open source projects is very, very small. So it's actually very rare for an open source project to lead to a great open source business. So how do we think about this tailwind? I think using the cloud as sort of a macro example is actually the right one, because we can talk about all the IP issues and the modes and all that stuff. So if you just think, and then we can just go back to Mongo.

So if you look at how Mongo thought about its cloud product, MongoDB launched Atlas, which was its base of the service that runs in the cloud in June 2016. And Atlas, in terms of revenue run rate, has grown from like zero to $147 million of annual run rate revenue within three years after launching. Based on their Q1 results that they launched, they announced a few days ago, The Atlas product is now at a $210 million revenue run rate. And so that's with less than four years' time, the Atlas product has gone from zero to all over $200 million of run rate revenue. And the number of customers Atlas now has is pretty astonishing.

So within four years, it's gone from obviously zero customers at launch to now they announced that at the end of Q1, Atlas had 16,000, 800 customers on the service. So that is actually a huge macro trend that we can all think about that open source can certainly take advantage of, which is that there is huge amounts of interest in thinking about rewriting infrastructure in the cloud world and using new components in this cloud world. And if you can provide a service or an offering to customers that is a dramatic improvement to the alternatives that are available, it will lead to becoming a great business.

And that service itself does have value, does have defensibility and all of that. And now I think the part where I'd love to hear Jeremiah's perspective from an entrepreneur's perspective is the three public clouds have taken dramatically different positions and postures about how they think about running their own services on top of open source projects. Look at what Google and Microsoft have done versus what EW. US have done, they've taken sort of like different approaches and how they think about open source, open source partnerships, and how open source is monetized across the three clouds. It's a fascinating dynamic. And one of the interesting things is that we're still in the

very early evolution of what that means. I think ultimately as long as you align with this massive macro trend of the cloud and continue to keep in mind that just because it's an open source software, you can never forget the fact that at a enterprise customer will hire you to do a job. And it has to deliver that job in a delightful and amazing way. I totally agree. I think this is going to be my drum to beat here. But the job you're being hired for is ultimately not the lines of code. It's what the lines of code do or some extension of that. And just to go back to the public cloud source, I certainly do spend a lot of time with this and can certainly attest the idea that they have all adopted very different

approaches on some range of antagonistic to friendly towards open source companies. my idea here is the public clouds ultimately sell two things. They ultimately sell compute and they sell storage and everything else is to facilitate that. Every tool that they host, every product that they launch is a convenience layer to basically entrench one of those two things and those are the flagship products that these clouds have. When you think about an open core company, which is a company that has an open source product and potentially built closed source or a proprietary product on top of it, If the version of the proprietary product that a company offers is nothing more than managing their open source software, then their chief competition is actually the public cloud.

Because the thing that they are selling over their software is CPUs. It's just the management of it. And this is where we go back into that sort of perverse incentive, unless it turns out it's really hard to get it onto a CPU, in which case they're also selling the convenience factor. But I think, as I said earlier, I think people look through that. So it becomes even more important, due to the explosion in just the popularity of the public clouds, it becomes even more important to differentiate software, not just by managing it,

but by offering some degree of functionality that is reflective of the expertise that the software manufacturer has by virtue of servicing many use cases or working with many customers or just knowing how the code works and best practices. And there are all these other ways to layer these other jobs to be hired for on top of just the fact that at the end of the day, you have this raw CPU delivery. At Prefect, we went so the other way on that. We designed this whole system where we don't run code for our customers. We ask them to provide the CPUs wherever they like. It's a huge advantage for us.

It gives us privacy and security benefits. And speaking of defensibility, we patented this business model. I strongly believe that if you want to build a defensive business here, you need to find a way to work with these clouds, at least as a startup, not put yourself in a position where fundamentally your business model is a directly competitive with their desire to sell CPUs and more specifically provide software that runs on those CPUs. So that alignment can be hard. And I think we love Google. Google Cloud. We were closely with folks there. And it's just been a very pleasant experience, how they've decided to

approach this. Let's speak to that. Chaythin, one interesting way of kind of framing this whole thing would be if you meet, let's say, a young entrepreneur and they want to build software, and maybe they're sort of agnostic as to whether they take a open or closed source approach. How would you talk a would-be entrepreneur through the trade-offs of that decision? Are there certain types of software that you think lend themselves more to the open approach versus the closed approach? Yeah, absolutely. I think it all comes down to ultimately what Jeremiah described, which is, what do you ultimately envision a customer doing with this piece of software? And is there value for a customer to experience the software in components or modules.

If you think about the standard application, there are very few call it SaaS applications where you can say, oh, if I had just this part, it's pretty valuable and I'd like to build sort of custom tooling around it, and that is actually a valuable application. Whereas, like, most applications deliver value when you get sort of the end-to-end experience.

And so I think that's part of the reason why there haven't been, at least to date, a number of commercial open source applications that have turned into big businesses. Certainly that can change in the future. And where open source businesses have been successful is infrastructure. And the sort of idea there is that the open source infrastructure that you put out there is actually differentiated than existing solutions. people can pick up that open source project, get a ton of value out of it, build custom applications, in-house applications, whatever, on the open-source project itself,

and then contribute back learnings, whether it's through talks at user conferences, content back into the community, or code back in the community. Often it's more the first two than the vast majority of people that are in the open source community will not contribute a tenant code back into the open source project, but they will contribute a lot of knowledge. And as Jeremiah described, the open source community will sort of guide the company in terms of what the community actually needs, what the community desires. And then you can also glean

a subset of customers that have very specific needs that is perhaps expensive to build, but also delivers a lot of value to the customer. And that's sort of the commercial pieces that you can build around an open source project, but primarily that's the way that I personally think about it, which is that if you think about a project, is there value from the core itself that can be delivered that's dramatically better than what's available? If so, then it makes sense to have an open source project with sort of commercial bindings that's either through cloud or through enterprise or through services or whatever that you can build over time. But without that distinction, it's really hard to make the case of putting yourself through building an open source

business, because building an open source business is actually very, very difficult. All the data over the last 25 years indicates that the vast majority of open source projects don't end up being good businesses. They just end up being great projects. If you think about it in that lens, you have to really make that case that this open source project delivers significant value. and from that significant value, you can then derive additional value with proprietary features or proprietary features or modules that you can then offer

that creates even more value that you can then monetize and it ends up becoming a good business. I was just going to jump in and actually be more emphatic than Chathen. Building an open source business is really, really hard. Billing an open source project is really, really hard. Forget the business.

I think it's, in as much as we've talked today about open source as driving certain values and whatever. The truth is it's open source. That means it is open source. That means if somebody doesn't like it, there's a record of that. That means if people don't contribute to it, there's a record of that. The absence of engagement is as visible as everything else that we've been talking about. And that can be very frightening. That can be very intimidating. There's not really a place to hide. I can't pretend that Prefect has any different adoption than it actually has because it's open source. You can see the engagement of it. Starting it, the day we launched it and we launched the Slack Channel

20 people a year ago, it's going to cross 1,000 next week. That's amazing. We love to see that. But if it hadn't done that, that would be very visible as well. I think that that level of transparency can be deeply uncomfortable to people, even if they think they want the benefits of it, because you have to deal with this potential downside as well. I believe that there are steps you can take to do a better job here. By the way, I think it's no coincidence that many open source communities have a reputation for being toxic. To be blunt, I think that's because many open source maintainers end up running popular products, not because they set out to run a popular open source product, just because it just happened to be useful. But managing and working with an open source

community is hard. I remember when our first employees and our CTO, Chris White, joined the company. Yeah, we talked all about cool stuff we wanted to build, but we agreed on one rule immediately. And number one rule is we're going to be nice. And that's it. Today, we can trace a line back to that. We have customers who are our customers specifically because they know that if they go and ask a question on Slack, they get a full answer in about 10 minutes. Can that scale like forever at Prefect? I don't know. We do our best to put processes in place to deliver that kind of experience. I don't know. I hope so. At the nascent point of an open source community, you have to commit to building this community as much as you commit to building the software because the moment it lags, the moment

you don't see that and the tide goes out. And this is not something that you want exposed if you don't have to and you have to be willing to embrace that transparency or it will fail. I'm curious then point taken. This is hard to do. It sort of begs the question both from an investing and a building standpoint. So same question for each of you, which is, why bother? Why not start Prefect as just a traditional software business that solves the same problem? Why not invest Jathan only in companies that do it the standard way and don't have to face all of the scrutiny given the failure rate and the uncomfortable nature of that. Maybe Chathen, I'll start with you. One of the great things that I'm sure Jeremiah will agree with is that, If you've ever developed applications on your own, and especially in the early 2000s or mid-2000s, if you were trying to develop applications on your own as an independent developer, one of the truly frustrating things at the time was how little was available in the open source community that enabled you to get going quickly. And it was pretty clear that the large software company,

companies, especially on the consumer side, that had built a whole bunch of proprietary tooling and a proprietary infrastructure, had real distinct advantages from the independent developer in terms of just how fast they could build things up and how quickly they could build things up. And it was pretty obvious that developers inside companies like Google or Facebook or any of the large consumer internet companies had a distinct advantage in building a net new product because they just had these gigantic software, internal software projects that were unbelievably enabling of sort of the development internally.

What really, I think, changed all of that is you saw an incredible explosion of open source projects in the late 2000s and early 2010s, and that really changed the landscape of how productive developers could become and how fast you could build applications and how fast you could build technologies. And fast forward to today, to 2020, with the last 15 years of this amazing explosion

of really great open source projects, building an application today of extraordinarily high quality, you can do it actually much faster than some of the large consumer internet companies, primarily because of the number of open source tools that are available, and the advent of public clouds, which makes running these applications at scale pretty easy. So that movement has been, I think, frankly, as someone with limited development capabilities,

it's just incredible to watch. And the amount of creativity that you unleash behind that and the amount of sort of economic and innovation opportunity that you unleash behind that is really remarkable. And I think it's set us up for what we're really watching in the enterprise. which is basically a trillion dollars a year that's spent on the entire enterprise market, now sort of unlocking itself as more people starting to see that you can reinvent whole parts of the infrastructure stack and the application stack. And part of that movement is going to be driven by open source.

There is a large economic opportunity if you can get it right. And I talked about the MongoDB numbers earlier. And then if you look at the financial figures, of all the really successful open source projects, you quickly realize that when it works and when you do get it right, it works in an extraordinary way and delivers value to not only the open source users, but also the users of the cloud service or the enterprise product or whatever. And that pushes sort of the innovation economy forward. And I think the economic opportunity, when done right, is pretty terrific too. Yeah, I echo that, but I guess in an attempt to be still relevant on this podcast, because it's hard to follow you, Chaypin.

I'll talk about the more pragmatic decision, like at the moment of starting the business, should you go open source or closer. It's a very permanent decision point, and without the luxury of knowing how things will play out. I think a big piece of it is sort of knowing your user, knowing your customer, knowing what they expect and what they'll be excited to use. So I come from the Python data world. I'm struggling off top of my head to think of a Python package that's delivered in a closed source form. there's an expectation that people have, that users have that will lead to their adoption in an open source way because they're familiar with it because it feels familiar to them. And then there's also a growing just ethos within, again, within that same community that this is a good thing, that they want this, that they'll choose this. I don't think it's enough, though.

I don't think it's enough just to be open source. Close source competitors that are terrible. And I have open source competitors that are also terrible. It's not enough just to be open source, but going back to what we said a moment ago, it is a bit of a gamble. If you can get it right, there's an opportunity. to have this massively compounding effect as it ripples out. We've seen this. I said I was going to say take us back to the moment of deciding how to start the company, but we actually, two months ago, in the midst of COVID, we decided to open source even more of our stack, make it more available to

more people. And our adoption numbers took off again because fundamentally nothing was different. We were actually delivering the same product that we made available for free through managed service, but the fact that it was open source sparked something, sparked some interest, even if these are people who aren't going to use the code or aren't going to contribute to it. So you can tap into an ethos in that way and you can find goodwill in that way. I think at the end of the day, it's sort of like, could you deliver an effective product in a closed source form or open source form and different businesses, the answer will be yes or no. For us, I'm not sure how we would actually deliver a product that does what we do,

which is to say interfaces with a customer code in the Python data world without it being open source. So it was a, in all honesty, it was a fairly easy decision. I'm curious what you both have learned about digital community building. You both mentioned it as a key component of an open source project and therefore open source company. And I think in the COVID era, it's an especially interesting question because community is such a popular word concept. We all want it. We all crave for it. We're social creatures.

That's in large part been stripped away from us. And for open source in particular, community is really important. At Prefect Jeremiah and at the companies that you've been involved with, Chathin, I'm curious, what you would say are the most effective ways of building a strong community. in addition to just being nice, Jeremiah, which I think sounds simple, but probably a powerful thing. I mean, you just have to be nice. I know it sounds ridiculous, but I've probably poked around more open source communities than you guys have. And not being nice is a real problem. It's a real problem in many software communities. And I know it sounds fluffy. And I'm not saying this in a fluffy way. I mean, in a very real way, if someone takes the time to join, in our case, Slack and ask a question

which, first of all, takes a certain amount of bravery or humility, if they're going to take the time to do that and they're going to be met with silence or a brusque response or anything other than welcoming them and thanking them for taking the time to use this thing that you put into the world, I mean, it's just crazy to me, but it takes enormous effort and dedication and willingness to do that, to provide the other end of that connection.

But a majority of our customers started that way. That is in the beginning. That's how we convinced people. That's how we earned their trust that we were worth working with. And so being nice, I really do think it is so hard to do. It is so alien to so many open source communities where the maintainers have an attitude that they are volunteers. They are unthanked.

And by the way, that's true. Most maintainers are un thanked. They get an unending series of people showing up to ask why they didn't do this or how this doesn't work this way or how dumb is it that you didn't think to do this? That is true. There is an unending parade to that. But if you want to run a community that is truly open, you have to run a community that's truly open. You have to make it welcoming for the people who choose to participate in it. And then that's self-reinforcing behavior. I think it's a challenge to be completely frank about it. In the case of Elastic where I'm on the

board, our products, we disclosed this in the S-1, which we filed, I believe, in 2018, coming up on two years ago. We disclosed that our products have been downloaded on the order of 350 million times. The community that we had built up, over the period, we had something like 100,000 meetup members across nearly 200 meetup groups across 46 countries. Take a step back and you realize sort of the enormous size of the developer community that actively engages with your projects. and that's not only sort of concentrated in any one geographic area,

but it's a global community that's engaging with you. That then creates quite a bit of responsibility on your shoulders to create avenues of engagement, as Jeremiah said, that are additive and positive. And so it takes a lot of investment in developer communities and being very sort of purposeful about thinking about creating spaces and avenues for people to share, how they're interacting with the open source project.

I think you see that also not just in the open source community, right? You see that in the rise of like the developer advocacy role and movement really about access to even proprietary software. And it's a way of welcoming people in and using them. And yes, it may have a business objective behind it in some cases. But this idea that reaching out to these developers who are the ultimate users of the software has certainly taken root on like a wider scale. And so I thought I'd give something more concrete in this case,

which is, I'll tell you exactly how we measure all the things that we're talking about right now, or at least how I do. All of this idea of compounding in community and all this stuff. For me, it's very simple. The metric is how many times does someone who doesn't work for our company, who isn't paid to do this, respond to someone who asks a question? And if that number keeps going up, then we are achieving this, whatever you want to call, this flywheel, this compounding effect, whatever it is.

And if that number stagnates, then we are failing. going down is very, very bad. Because at least you hope someone maintains a level of engagement. But that is a way to actually capture and track. Remember, like I said earlier, it's open source, it's open source. You can see everything. There's nothing that is hidden. That is a very tangible way to actually measure the degree to which this is happening.

And by the way, you can feel it. You can feel it in these communities. If you're not getting a response, if the community is not actually there, if the community is just a mob asking questions, very different feeling. In addition to this community aspect, which I'm just endlessly interested, in and think is a powerful concept to be deployed in lots of different ways, not just in software. Are there other elements of this business model or this building approach that you think more traditional companies could successfully apply, whether that be mindsets or best practices

into their own businesses? It's a tough question. Well, let's point at OSAM for a second. Why don't we turn this around for a second? Nobody ever asked you any questions. You have a motto that involves the word share. learn, build, share, repeat. Is that right? Yeah. Yeah. So this is an idea. I don't think anyone would call

Osam an open source business, but there certainly is an open source element to what you're doing. You just have this idea of like open source knowledge. And by making that available, by making that raw material available, you are creating an externality from the work that you do. You're inviting other people to participate and observe and draw conclusions and maybe agree with you and maybe disagree with you. I think your challenge, In some sense, if you want to apply not just the open source ideal to that, but the open source business ideal to that, is to figure out, as we said earlier, what job do you provide? What do you do by virtue of the fact that you are the curator of all that information and how do you deliver that? I think you really can see this idea that by looking for compounding effects, other flywheels within a business, you don't have to give away literal source code to have an open source to everything that we're talking about work for you.

you just have to find ways to involve people and bring them into an ecosystem in a constructive way. I've been thinking about this recently, which is a simple litmus test, where if something is, I'll call it low cost or free to produce and free usually to share, so no marginal cost of distribution, that by definition it should be free. And I just wonder the implications of this. So obviously like a Netflix show, which is free to distribute, should still cost something because it's really freaking expensive to make, but that if something falls in that category, at least answering your question, Jeremiah, I'm trying to come up with a standard with an operating

principle for when we decide whether or not to share something, because my experience teaches me that the best things to share are the ones that you have to think hard about whether or not you want to because they feel like they give you an advantage or their proprietary or their IP or something like that. But almost every time that we've always made the mistake if we try to keep it close to the best versus share if it falls in that category of relatively low cost to find or produce and free or near free to distribute. So I'm curious if that's a litmus test that maybe more traditional businesses might try to inject more value into the overall ecosystem of their industry versus keep something proprietary. I think it comes back to the same idea of what is the value you

provide. And again, trying to extend this, we don't need to purely stay in the open source world. We could talk about a completely close source business as well. But really knowing what the value is, and knowing what you are providing to your customers is critical and helps you make this decision. Obviously, in an open source context, it has massive permanent ramifications as well, because you're actually going to make it available. We've sort of said that this isn't strictly true, but in some sense, you're going to forego your opportunity to profit from what you open source. You're going to profit in a different way versus keeping a close source and just selling access to it.

So in our case, this is the knowledge of what is for workflow management. We're going to open source that and what is for insurance. We're going to keep that as a product that we sell and that we provide. And drawing that line, I won't lie to you. There's moments as we choose what we're going to open source and what we're working on. There's fraught moments there. These are very permanent decisions that we have to make and you worry a little bit. Is this a thing people are paying for?

Are we about to release the thing? Have we completely misjudged our customers? Are we about to give away the thing they're paying for? The good news is you don't have to actually wonder this thing. You can ask people. We did. I know exactly what someone thinks they pay for when they purchase our software. And I know exactly what they learn that they're paying for.

when they buy our software. And by the way, they're not the same, which is frankly a challenge we have at our businesses. How do we align those things? How do we better educate the value we can deliver at the time of the purchase? But that understanding and knowing what you produce that is a value

and then second order, how does your customer perceive that value and receive that utility? I think is a really critical question for any business. I think it's a little bit harder to hide from it in the open source context. And I think that every business

that is engaging in public learning open learning, ends up deriving tons of benefit. If you think about, I talked about sort of the explosion of sort of open source communities, especially on the software side in the late 2000s or early 2010s, one of the companies that engaged with open source very early on was Google. And they simply were putting out these white papers that were talking about all these proprietary technologies that they had come up with internally. And I think if you think about what value that ended up creating to those companies, and we've talked about this before, is that it turns out that engineers, and this is a fairly obvious thing to say, is that engineers want to work on really

interesting problems and really challenging problems. And I think that not only applies to engineers, but most of us that are engaged in our jobs is that we want to work on interesting problems. And sort of engaging in this open learning system and open feedback system where you're putting your work out and you're putting out sort of the ideas that you're exploring, really then encourages really great and bright people to engage with you as a company and engage with your ideas. And I think the sort of open source ethos, if you will, of sort of putting ideas out there, putting projects out there, and sort of engaging the community at that sort of level of here's something that we've tried that's pretty interesting, here are some lessons we learned,

and then collecting the feedback, ends up creating immense value not only in terms of improving the business's products and offerings, but it also has a second derivative effect of being an enabler of attracting really great talent to the company because you are now essentially showcasing really interesting problems that you're contemplating publicly. And I think that's more and more companies are starting to realize that and you see companies that maybe 15 years ago you would have never imagined engaging with an open source community being huge proponents of it. There's perhaps no better example of this than Microsoft, which famously called Linux a cancer many years ago, but is now one of the biggest contributors in the open source world.

I think that shift that we're all experiencing, which is that sort of learning in public and learning very openly and open source is a great way to do that, ends up being not only a way to improve your products and services, but it also ends up becoming a great source of talent for the company itself. One of the things that I've experienced for sure that everything you guys have said rings true for me is this, you can almost think about building a magnet versus building a megaphone, sort of create this inbound gravity through community building and through open learning.

It's a hard strategy to pursue in the early days because the returns don't show up quickly. It takes a couple of years for that convex payoff curve to really be visible and be felt, but ultimately is way more powerful than even the most powerful megaphone because stuff's rolling downhill in your direction. I always think of that metaphor, Chathen, that you taught me to go slow to go fast. I think that describes this extremely clearly. I see that in our business, we say our job is to deliver value, not to extract it. And it's just trying to bring that community ethos in.

Obviously, we are our business and we do need to deliver and receive value in turn. I should have mentioned this earlier way. It didn't come to mind. We actually named our sales strategy, open source sales, because we tried to bring some of the learnings from our open source engineering effort into our sales effort. And so that manifests in some ways. And Chathen, don't listen to this for a second. because he'll be horrified.

Like, our sales team doesn't really call people back. They say very genuinely, they say, oh, no, I'm horrified. Well, you're not going to hear from me again under some circumstances. This is horrifying to our head of sales as well, the first time we came up with it, but we can point, again, we can draw a line to customers that resulted from that. From that, obviously we need to be smart about that. We need to be smart about our sales strategy.

But looking for ways to bring this idea, seems so silly to say it comes down to be nice, but looking for ways to leverage that elsewhere has mattered. Can you take that too far? Can you be really stupid about it? Yeah, you absolutely can. We try not to be. But finding that balance isn't anything. Finding that balance is critical.

That's the exercise. What major aspects of open source, the philosophy or the business model have we not touched on that you think it's important for entrepreneurs and investors to consider when looking at these businesses? The sort of opportunity set that's available to businesses at the moment is much greater than it's ever been.

And I think new industries and new workflows are unlocking. And I think it's the macro transformation that we're a part of, which is that we're seeing just previously sort of locked up spend and core functions coming online now, where enterprises large and small are now of the mindset of what, well, if it's been done that way for 20 years, why has it been done that way? Can we do it better, faster, cheaper? And there's just much more openness to think about new tooling, new solutions, etc. The number of opportunities that are available to open source companies to sort of rewrite fundamental infrastructure components and address them in really unique ways,

I think, frankly, has never been greater. And so what ends up happening is that you're seeing just really unique solutions. and really unique projects come out of not only sort of your traditional pockets of technical talent, but they're really coming out all over the world. From an investment perspective, I think the investment opportunity is massive. And I'm certainly very optimistic that some of these projects will end up becoming really incredibly big businesses in the future. One of the more frustrating questions that we get is how do you compare to X? The reason that's a frustrating question is not because it can't be answered, but because it rests on such a

subjective need that the user has. And we don't know what that is now. We've got in the habit of saying, use us and use X, and you decide. Whichever one feels right to you, just use that. Which everyone solves your problem, just use that. And we're not going to sort of waste time trying to pretend that we know we have this Venn diagram of features and you have that Venn diagram of features and we overlap here and we differ here. And if the thing that we differ in is critical to you, then you don't have a choice to make. And if the thing that we overlap in is critical to you, then I can't defend the choice that you have to make because I don't know what's valuable to you. And so that's one of the things that I think is challenging for those of us with younger companies in the space is it can be very

tempting to say, oh, these six companies do X, Y, or Z. But if we're all honest, especially because we're open sourced and that creates a very rapid pace of evolution, I don't think any of us know precisely what X, Y, or Z are. As companies, as entrepreneurs, and it would be quite a stress to think that our users do too. So people are always going to look for the best tool that meets their needs. And the challenge is to, again, I guess this really is my drum to beat. The challenge is to really know what problem you solve and not be seduced by this expanding circle of, well, customer X or user Y wants this, let's build it. It would be easy for us to bolt it on. I think instead you want to think in the opposite. Competition, if we all pretend this is a business school for us. Competition is a good

thing because it makes companies focus on what differentiates them, makes companies stronger unless they can't and then they die. This idea is something that we think about a lot as a young project that's emerging, that is evolving, that looks like other projects. How do we maintain our competitive advantage both from a defensibility perspective, from a utility perspective, from a value perspective? It's challenging, but part of the game. My closing question for each of you is to ask, what has you most excited about the future in this space. Maybe Jeremiah will start with you. I have benefited so much from open source software in my career. I mean, my career spans risk management and machine learning. So I was building machine learning models in 2011 when you say machine learning somebody,

they kind of ask you, well, what's that? That was based on open source software. That progression has exploded. As a research scientist, open source availability, open source research, open source tooling the explosion of AI applications is grounded in this idea that we can learn cool things, build cool things, and share them and build on top of them in this amazing way. I love seeing the research. I love keeping up with the latest research that's coming out, that's built on open source tools that has code available. That lets me, if I choose, replicate these otherwise unreachable algorithmic advances on my laptop,

just because someone was kind enough to share it. make that available. And so I have loved seeing that. I look forward to that continuing, and I think that that is just in its infancy. I would say that the main thing that I'm continuing to be really, really excited about is very similar to what Jeremiah talked about, which is that, one, we've seen over the last couple of years, infrastructure components start to change. We're seeing cloud happen in a real way. And then what's also happened behind that is that data has exploded within sort of enterprises. So data across applications, data, across servers, data across infrastructure, etc., tooling and new components of infrastructure

to handle all of that data, whether it's at the storage layer, at the database layer, at the analytics layer, or at the processing layer. And then how all of that enables machine learning and how that enables faster and more efficient processes are all opportunities available to open source software and to people that are looking to build open source projects right now. And I think that the opportunity set is also really valuable because enterprises are very ready to engage new solutions to help them solve these problems. If you look at enterprise workflows still today and how many of them are done manually and how many of them take a really unreasonable number of hours to accomplish, you can just quickly zoom out and realize that the opportunity set is quite large. All of these components offer huge opportunity for new companies.

And in addition to that, and it's something that I've talked about on Twitter, is we're starting to see this new trend of what I like to call, quote-unquote, super infrastructure, which is essentially API-enabled infrastructure that enables you to outsource a core function to an API call. And in the world of e-commerce, we've seen that with sort of new components like Shopify and Patrick, you had Toby on, and that interview was absolutely fantastic. You see it with Shopify, you see it with Stripe, and then you're starting to see it with brand new components. We have companies like Contentful and Commerce Layer,

which are both open-source companies, that then enable API super infrastructure for companies to then go leverage. So much like we saw in terms of super applications where these applications did tons of stuff, stuff for the user. We're now starting to see these new generation of what I like to call super infrastructure companies, which are really being developed to do a lot more than sort of like a single infrastructure thing. They're starting to do lots of things with one API call. I think that's a really

fascinating trend that open source companies can really, really take advantage of that I'm pretty excited about. Anything else to add Jeremiah there on the API side so you can tell, like I'm honing around this same API-first business concept as one of the most fascinating business models out there. Any closing thoughts on that, Jeremiah? What this represents is certainly the epitome of everything we've talked about today, where if open source is about delivering more than lines of code, it's about delivering a convenience or solving a problem or something like that, then the API call represents a way to bundle up what might otherwise be disparate open source lines of code and turning them into business logic.

And potentially that's the negative space that if you have an open source business, where Patrick, you and I have talked a lot about the metaphor, the prefect workflow kit is a bunch of Lego bricks. So that's great if all the Lego bricks are open source, but someone needs to first come up with and then follow the instructions to create something with them. And that can be something that someone can choose to do themselves, fully partake to the open source, or that's something that someone might want a company to provide.

And an API, in a simple sense, is a way for us to take that business logic, take those instructions, bundle up the building blocks behind them, and expose something that is semantically aligned with the business's objective, as opposed to asking the business to learn it themselves. But that to me is what the API represents. It's not just the fact that you can hit an endpoint and get something done, but in an open source context, it's more than that. It's an opportunity to layer semantic knowledge and expertise and domain expertise over the otherwise individual components. Well, as somebody that is, again, not technical, but using a lot of these tools and building software, I can attest just to end the conversation in a very tangible place. It is amazing how fast and efficiently you can build stuff now with a relatively small team to accomplish your business goals without having to recreate the wheel each time. And I think fundamentally that is why I wanted to. to have an hour and a half long conversation with you guys on something like open source,

which can appear to be a sort of wonky topic. But I think is in many ways unlocking creativity in the business world in ways that nothing else before has. It's a remarkable thing. Well, thanks for having us, Patrick. This is so much fun. This has been great, Patrick. The three of us talk quite often. And so I'm glad that we're able to do this podcast.

It's been awesome. We really take learning in public to a whole new level. You know you are my two go-to references on all things. area, so I appreciate your time today. I learned more, as always. Thank you so much. Thank you. Thank you. If you enjoyed this episode, you can sign up for a new email newsletter sent out each week called Inside the Episode. Each week, I condensed that week's episode to my favorite big ideas, quotations, and more. I've been recommending books to members of this email list for years, and we'll keep doing so in this weekly email. You can sign up at investorfieldguide.com

forward slash book club