noe

August 25th, 2020 | Episode 188

Chetan Puttagunta and Jeremiah Lowin –

Open Source Crash Course
LISTEN TO PODCAST GET THE NEWSLETTER

CHAPTERS

1. History and background of open source software

2. Understanding the business model of open source
3. Defensibility of the open source business models
4. Building an open source community
5. Lessons traditional businesses can learn from open source
6. Future of open source software
EPISODE 188 IS BROUGHT TO YOU BY:
Canalyst is the leading destination for public company data and analysis.
Founded by a former buyside analyst who encountered friction in sourcing,
building, and updating models, Canalyst 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 4,000+ equities, Canalyst’s

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.
Try Canalyst for yourself at canalyst.com/Patrick.
EPISODE SNIPPETS
OPEN SOURCE BUSINESS MODEL

• Open source businesses provide proprietary services on top of free, open source code that
anyone can run. They work particularly well in infrastructure businesses where you can use open
source and your open source community to drive trust, engagement, and top of funnel acquisition
for your paid, proprietary service.
• Proprietary product cannot just manage the open source software but must bring unique
value – a company that has an open source product and builds 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 (AWS/Azure/GCP)
because the thing that they are selling over their software is CPUs. It's just the management of it.
JUMP TO SECTION

BUILDING AN OPEN SOURCE COMMUNITY

• They key lesson on building community: “be nice.” It may sound obvious but so many open
source communities are volunteers and the job can be thankless so there is not an ethos of
“niceness.” A lot of Prefect’s customers started as open source participants and become paying
customers later.
• How do you measure if you are building a strong community? 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.
• What to be aware of – there is no place to hide in open source. If people aren’t responding to
questions or contributing to the code base, that is public for everyone to see (contributors, investors,
and customers).
JUMP TO SECTION

LESSONS TO LEARN FROM OPEN SOURCE AND ITS FUTURE

• Key lesson for other businesses to take from open source companies – learn in public! Develop
an open source ethos of putting your ideas out there, putting projects out there, and engaging with
your community as a way to build trust among your users.
• Future opportunity – there has been an explosion of data inside enterprise companies in the past
decade so there is a massive opportunity for open source companies to rewrite fundamental
infrastructure and to target API “super infrastructure.” Essentially, building APIs for companies
to manage their data and outsource core business processes.

JUMP TO SECTION
INTRO
Patrick O'Shaughnessy (00:01:46): 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'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 Chetan 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 is become a category that I'm personally fascinated in. I know obviously Chetan
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.

HISTORY AND BACKGROUND OF OPEN SOURCE

As a jump off point, Chetan, 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.

Chetan Puttagunta (00:03:12): 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.

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 history, but Red Hat had I think like
the eighth biggest or the 10th biggest first day gain in the history of Wall Street.

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 Sun [Microsystems] bought.

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 and 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.

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 fire starter for thinking about open source as an incredible
commercial business model in software.

Patrick O'Shaughnessy (00:05:52): 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.

Jeremiah Lowin (00:06:10): 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-sourced more of our stack, we certainly experience that and I think if you think
about marketing budget versus the fact that we have an engaged open source community, one is a
compounding activity and one is just the pursuit of ROI sort of blindly.

I think the critical thing about open source

software is actually not that the source
code is available, it's rather what that
represents.
If there are dollars at this, maybe people see it, maybe they'll buy my software. 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. 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.

Patrick O'Shaughnessy (00:07:41): 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, 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.

Jeremiah Lowin (00:08:14): Sure. So Prefect's open source project is a workflow engine. It's a workflow
management system. You use it to achieve a goal a you have which is to make sure that code is run at a
certain time in a certain place and 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 and Patrick as you know I spent my whole career looking at risk management stuff. The devil is 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.

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 is 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."

Jeremiah Lowin continued (00:09:46): It's this very real moment where without the software in place and
being governed by us, 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.

OPEN SOURCE BUSINESS MODELS

Patrick O'Shaughnessy (00:10:28): Chetan, 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?

Chetan Puttagunta (00:10:36): There have been four companies that have invested in that have had in our
sort of like venture capital world, we think of as "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 dollars and then I was also involved in Acquia 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 "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 a huge powerful force in the enterprise
software market. 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.

Chetan Puttagunta continued (00:12:28): If you look at somebody like a MongoDB, the way they 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,
et cetera.

Through Atlas, your company or a customer is able to provision and run and manage MongoDB clusters
across Google Cloud, Azure and AWS. So they can run it in multiple regions, they can run it across multiple
clouds and they provide that service. 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.

Patrick O'Shaughnessy (00:13:36): How do you react to that, Jeremiah. I'm just curious if that lands
for how you think about Prefect's pricing and business strategy?

Jeremiah Lowin (00:13:44): Yeah, it absolutely does. I just think about that daily. I think about 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, "It 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." I think the extension
of that from what Chetan 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 and you're selling some extension of that.

“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 and 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 a 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.
I think at the end of the day especially with the explosion of open source and as Chetan pointed out, the
explosion of readily available computer resources to spin these things up, people aren't dumb. They won't
fall for this. We talked 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 we never
want a customer to feel like they're held hostage for any business, not just open source.

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 users' interests in mind even as you
build a business is really important.
Jeremiah Lowin continued (00:15:25): 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 that you take money to alleviate it. 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 users' interests in mind even as you build a
business is really important.

So I firmly agree with everything Chetan is saying. I think 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, "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 company, 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 do 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. So let's just wait and
see this is gaining traction or that's not... For a VC, we can invest in this. For users, we can begin to adopt
it. It's just a very different dynamic than even what we'd see in a more traditional software world.

DEFENSIBILITY OF OPEN SOURCE SOFTWARE

Patrick O'Shaughnessy (00:17:05): I'm curious how you guys think about, Chetan 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 code is
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 that. So how do you think about the defensibility
of open source businesses as they scale, Chetan?
Chetan Puttagunta (00:17:38): 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 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? It is to provide a utility to a customer. When
a customer engages an enterprise software company, they are in essence hiring that enterprise software
company to do a job. 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 it 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 closed source alternatives.

Chetan Puttagunta continued (00:19:24): I do think that the open source companies that have broken out,
and what Jeremiah just said is absolutely correct, which is 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 the right one because we can talk about all the IP
issues and the moats and all that stuff. 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 basic service that runs in the cloud
in June 2016. And Atlas in terms of revenue run rate has grown from zero to $147 million of annual run rate
revenue within three years after launching. Based on their Q1 results they announced a few days ago, the
Atlas product is now at a $210 million revenue run rate.

With less than four years time, the Atlas product has gone from zero to well 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,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.

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 in 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 AWS have done, they've taken sort of like
different approaches in 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 an enterprise customer will hire you to do a job and it has to
deliver that job in a delightful and amazing way.

Jeremiah Lowin (00:22:29): 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 clouds for a second, 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 builds 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. 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
cloud. 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 used cases or working with many customers or just knowing how the code works and
best practices. 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.

When you think about an “open core”

company, which is a company that has an
open source product and potentially builds
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.
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 defensible business here, you need to find a way to work with
these clouds at least as a start-up, not put yourself in a position where fundamentally your business model
is directly competitive with their desire to sell CPUs and more specifically provide software that runs on
those CPUs. So that alignment can be hard. I think with Google Cloud, we worked 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.
Patrick O'Shaughnessy (00:25:02): Chetan, 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 an 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?

Chetan Puttagunta (00:25:27): 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."

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. Where
open source businesses have been successful is infrastructure and the sort of idea there is, 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 in the community or code back into the community. Often
it's more the first two. The vast majority of people that are in the open source community will not contribute
a ton of 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.

Chetan Puttagunta continued (00:27:46): 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 drive additional value with proprietary features
or modules that you can then offer that creates even more value. You can then monetize and it ends up
becoming a good business.

Jeremiah Lowin (00:28:43): I was just going to jump in and actually be more emphatic than Chetan. Building
an open source business is really, really hard. Building 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 at the day we launched it and we
launched the Slack chat with 20 people a year ago. It's going to cross a thousand next week. That's
amazing. We'd love to see that. But if it hadn't done that, that would be very visible as well.

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

Jeremiah Lowin continued (00:30:06): I remember when our first employees and our CTO, Chris White
joined the company, we talked all about like 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 the 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, then once you don't see that and the tide goes out. 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.

Patrick O'Shaughnessy (00:30:54): 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, Chetan 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,
Chetan I'll start with you.

Chetan Puttagunta (00:31:19): 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 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.

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.

Chetan Puttagunta continued (00:33:26): 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 you unleash behind that is really
remarkable and I think it 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 in 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 these 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. I think the economic opportunity when
done right is pretty terrific too.

Jeremiah Lowin (00:34:48): Yeah, I echo that, but I guess in an attempt to be still relevant on this podcast
because it's hard to follow you Chetan, I'll talk about the more pragmatic decision like at the moment of
starting the business should you go open source or close source. 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 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 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. I said I was going to say take us
back to the moment of deciding how to start the company, but 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 close source form and open source form in 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 customer code in the python data world without it being open source. In all honesty, it was a fairly easy
decision.
BUILDING COMMUNITY IN THE OPEN SOURCE WORLD
Patrick O'Shaughnessy (00:36:42): 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, Chetan,
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 is sounds simple but probably a powerful thing.

Jeremiah Lowin (00:37:19): 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. 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 in 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. In the beginning, that's how we convinced
people. That's how we earned their trust that we were worth working with. 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.

All of this idea of compounding and

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 it,
this flywheel, this compounding effect,
whatever it is. And if that number stagnates,
then we are failing.
By the way, that's true. Most maintainers are unthanked. They get an unending series of people showing
up to ask why they didn't do this or how come 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.

Chetan Puttagunta (00:38:58): 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 S1 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 200 meet-up 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. 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.

Jeremiah Lowin (00:40:11): I think you see that also not just in the open source community. 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 a wider scale. 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 and 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 it, 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, open source is open source. You
can see everything. Nothing 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.

WHAT CAN TRADITIONAL BUSINESSES LEARN FROM THE

OPEN SOURCE MODEL
Patrick O'Shaughnessy (00:41:32): 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?

Jeremiah Lowin (00:41:55): It's a tough question. Well, let's point out OSAM for a second. Why don't we
turn this around for a second. Nobody ever asks you any questions. You have a motto that involves the
word share. Learn, build, share, repeat. Is that right?

Patrick O'Shaughnessy (00:42:06): Yeah.

Jeremiah Lowin (00:42:06): 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.

Patrick O'Shaughnessy (00:43:05): 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.

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 I'm answering your questions, 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 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?

Jeremiah Lowin (00:44:16): Well, 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.

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.
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? 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. And 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 business is 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 do 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.

Chetan Puttagunta (00:45:52): And I think that every business that is engaging in public learning or open
learning ends up deriving tons of benefit. I talked about sort of the explosion of sort of open source
communities especially on the software side in the late 2000s, 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. 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 fairly obvious thing to say is that engineers want to work on really
interesting problems and really challenging problems.

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

Chetan Puttagunta continued (00:47:05): 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 businesses 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.

I think that 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
also ends up becoming a great source of talent for the company itself.

Patrick O'Shaughnessy (00:48:24): One of the things that I've experienced for sure that everything
you guys have said rings true for me is this. You can always 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, takes a couple 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, Chetan that you taught me to go slow to
go fast. I think that describes this extremely clearly.

Jeremiah Lowin (00:48:59): 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 a business and we do need to deliver
and receive value in turn. I should have mentioned this earlier, but 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. So that manifests in some ways, and Chetan, don't listen to this for
a second because you'll be horrified, like our sales team doesn't really call people back. They say very
genuinely, they say, "You expressed interest."

Chetan Puttagunta (00:49:28): Oh no, I'm horrified.

Jeremiah Lowin (00:49:31): "But 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 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 part
of 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. As in anything, finding that balance is
critical. That's the exercise.

Patrick O'Shaughnessy (00:50:04): 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?

Chetan Puttagunta (00:50:18): 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. 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
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 and et cetera.

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

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

Jeremiah Lowin (00:51:37): 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. Whichever one 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 features and we overlap here and we
differ here. If the thing that we differ in is critical to you then you don't have a choice to make. If the thing
we are overlapping 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."

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.
Jeremiah Lowin continued (00:52:43): 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.

Competition is a good thing because it makes companies focus on what differentiates them. It 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 is challenging, but part of the game.

FUTURE OF OPEN SOURCE SOFTWARE

Patrick O'Shaughnessy (00:53:34): My closing question for each of you is to ask what has you most
excited about the future in this space? Maybe Jeremiah, we'll start with you.

Jeremiah Lowin (00:53:41): 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, "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 to replicate, these otherwise unreachable
algorithmic advances on my laptop just because someone was kind enough to share it and make that
available. So I have loved seeing that. I look forward to that continuing and I think that that is just in its
infancy.

Chetan Puttagunta (00:54:43): 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 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, et cetera. 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.

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. 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 "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 Tobi on and that interview was absolutely fantastic.

Listen to the podcast with Tobi Lutke, CEO of Shopify, here.

You see it with Shopify, you see 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 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.

Patrick O'Shaughnessy (00:57:25): Anything else to add Jeremiah there on the API side? As you
can tell, 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?

Jeremiah Lowin (00:57:38): 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 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 particularly open source or that's something that someone might want a company to
provide.

Then 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.

Patrick O'Shaughnessy (00:58:58): 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. I think
fundamentally that is why I wanted 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.

Jeremiah Lowin (00:59:34): Well, thanks for having us, Patrick. This is so much fun.

Chetan Puttagunta (00:59:36): This has been great, Patrick. The three of us talked quite often and so I'm
glad that we're able to do this podcast. It's been awesome.

Patrick O'Shaughnessy (00:59:43): We're really taking learning in public to a whole new level.

Chetan Puttagunta (00:59:46): Right.

Patrick O'Shaughnessy (00:59:46): You know are my two go-to references on all things in this area,
so I appreciate your time today and I learned more as always. Thank you so much.