open source software

Intro

Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Michael
Schwartz, and this is episode 47 with Tracy Miranda, Director of Open-Source
Community at CloudBees.

CloudBees is a company behind Jenkins, the famed
project, which is used to automate building, testing and deploying software.

Many commercial and open-source projects use
Jenkins as part of their continuous integration and delivery infrastructure,
including my company Gluu.

Jenkins was forked from a project called Hudson,
started by Sun Microsystems in 2005. After Oracle acquired Sun, Hudson was forked
and rebranded as Jenkins.

Tracy has been an entrepreneur, a developer, a
technologist for around 20 years. She was active in the Eclipse community, serving
on the board of directors. She’s also one of the founders of the Continuous Delivery
Foundation, which operates under the Linux Foundation.

Hopefully that gives you a little background, so
let’s get on with it. Here’s Tracy. Thank you so much for joining today.

Tracy Miranda: Thanks, Mike. It is my pleasure to be here today.

Joining CloudBees

Michael Schwartz: For 10 years, you founded and ran your own consultancy,
specializing in Eclipse development – how did you end up getting involved in CloudBees?

Tracy Miranda: Yes. I think the
common thread there is definitely open source. So, I think that’s something
early on in my career I’ve always been drawn to, especially because of the innovation
that you find with open-source communities. And it came at a time I was looking
to just make a change in the career and focus a bit more on some of the
community building aspects.

And as I was talking to people out in the industry, I got introduced to Kohsuke Kawaguchi, who’s the creator of Jenkins, and at the time was the CTO of CloudBees. And the more he talked about the next stage of CloudBees, and what he wanted to do with Jenkins, the more exciting it sounded to me, so I could not resist the opportunity to join his team and lead the open-source team and try that future direction.

History of CloudBees

Michael Schwartz: So, for the non-geeks in the audience, can you talk a little bit about the history of Jenkins, and how that impacted the development of CloudBees?

Tracy Miranda: Yes, yes. So, Jenkins is a built automation server. It is most
commonly used for continuous integration and continuous delivery, which are big
parts of delivering software. So, it’s a tool that’s been around for 15 years.
Many might know it originally in its first incarnation as Hudson, but it
evolved over the years and became Jenkins and became very rapidly adopted by
developers and focused on delivering software everywhere, just because it gave
you a lot of flexibility.

And it was the first tool that sort of helped
you integrate and build your software. And it was really what we’d say is the start
of this whole field of developer productivity engineering.

And around it, so companies like CloudBees
emerged, offering more Enterprise version. So, when it came to scaling or
features around governance and securities, and CloudBees would offer Enterprise
Jenkins. And that’s just sort of evolved and evolved, and now the whole space is
currently really doing very well as we deliver more and more software every
day.

CloudBees Products

Michael Schwartz: So, CloudBees has a number
of products and services. For 2020, what are the most important products,
with regard to revenue, and what are the most important projects for your
future growth?

Tracy Miranda: In 2020, well – let me talk about the direction
we’re going first of all, and then I can bring that back to the present – so,
we see just everybody’s delivering a lot more software, and software has become
critical to every industry. So, you know, whether it’s a bank or a travel
company or insurance company – you name it – software’s a differentiator for
them. So, the more software we have, the more we kind of start to talk about
like software factories. And you can use the factory metaphor as well to apply
it to this.

So, in that model, we
talk about Software Delivery Automation, and Software Delivery Management
automation is just – the name says it all – it’s everything you need to do to
get the software delivered, pretty much like a factory. And then, the Software
Delivery Management, or SDM, is the part where you have the business
intelligence coming in, how do you make the decisions, what to release when, and
to who. So, that’s the direction we’re headed in, and we’re building out all
the different parts that contribute to integrating all the tools.

Today, what a lot of companies have is basically focused on continuous integration and continuous delivery, so, tooling around tools like Jenkins, we also have SaaS versions of CICD tools, and then, any tools that help you deliver faster. So, we’ve got a whole kind of portfolio, depending on your flexibility and what you’re trying to achieve.

Market Segmentation

Michael Schwartz: CloudBees is in a very horizontal market. As you mentioned,
you are serving customers in basically every industry. Given that, does
CloudBees segment solutions or the marketing effort, either vertically, or by
use case, or in any other way?

Tracy Miranda: I think probably the most clear segmentation, which we will kind
of see, is whether people want to manage it and have things kind of on-premise
themselves, or whether they want software-as-a-service. So, that tends to be a
key differentiator.

And oftentimes, it will depend on the industry. So, certain industries might have very strict compliance or governance around it. So, perhaps, it always has to be an in-house solution. But then, perhaps some new startups, so, in different segments can afford to go with much more as a service model, where they don’t really want to deal with the nuts and bolts, and the upgrades and the security patches – they’re just happy to focus on what they need to do to get their software out the door.

Why Open Source

Michael Schwartz: Without open source, there probably would be no Jenkins, at
least as it currently exists. And
therefore, I guess perhaps no CloudBees. But going forward, why does continuing
to invest and contributing to an open-source community materially help the
business?

Tracy Miranda: This is my key
role at CloudBees is, it’s kind of overseeing the whole open-source strategy.
So, you’re absolutely right, CloudBees is based on this massive open-source
project, and as we grow and continuing to evolve, we’re going to do a lot more
in open source and in different ways.

I think there’s lots of different benefits we
see to open source, so, on one side, if you take kind of just the engineering
side, there’s obvious benefits from working with the community – you’d get fast
feedback, you’d get people contributing.

A lot of the developers we hired in the early
days would come from open-source communities, and then they’d even have the
advantage of they are already up-to-speed with the processes and the ways of
working and the code base.

But then, there’s also other kind of strategic
science to open source as well. Open-source projects tend to spread like
wildfire, I had someone using the term, kind of the open-source tsunami. And
they have a tendency to change the direction of industries, to take something
like Kubernetes, which caused a big shift in the whole sort of cloud
infrastructure.

So, in that way, we also kind of look at technologies for them to be open and for them to drive the future direction of the industry and help us to get to an innovative place. So, we always want to be involved with open source and find ways to just create those kind of win-win situations for both the community and the company.

Open V. Commercial Features

Michael Schwartz: You mentioned previously that it was an Enterprise version of Jenkins, and I’m wondering about, today, is there still software that’s non open source, and if so, how do you decide what to open-source and what to keep private?

Tracy Miranda: Yes. I know that’s a key thing, and it’s constantly evolving. So,
we have an internal process, and we’ll kind of look at the way things are
evolving in the market. In general, like you take something like Jenkins, and
we have a lot of plugins added by different groups and different individuals in
some cases.

One thing that CloudBees do is, for the software
like CloudBees Core, or CloudBees CI built on top of Jenkins, is we also offer
kind of tiers of plugin, so we know which ones meet a certain level and meet
the requirements for Enterprise type customers.

So, this is focused specifically on things like security and governance and running things at scale. So, typically features in those areas, or verifying plugins, will be the areas we’ll tend to kind of have as the more closed source. And anything developers tend to use, this tends to be pretty open.

Open Source Strip Mining

Michael Schwartz: I’m sure you’ve heard this term “open source strip mining”, where large companies take open-source software projects and commercialize them. You know, you have a SaaS, you are offering themselves, but is this something that you’re concerned about, or any thoughts about this sort of phenomenon?

Tracy Miranda: I’ve definitely heard the term, yeah, it’s a pretty controversial one. But I think it is something that is always a consideration. So, you take something like Jenkins X, which is a new open-source project. It’s not related to Jenkins, as the name might indicate, but it’s actually a complete new CICD tool based on Kubernetes. And it’s one of the best ways to do Cloud Native CICD.

So, a lot of Jenkins X is open source, and you
could conceivably imagine another company taking it and wrapping it up and
delivering it in a specific way, but I think the reality is that open source is
always evolving. And it’s more about kind of the vision in the direction it’s
going. And the key thing I guess from CloudBees’ perspective is, we have a lot
of the people who are driving that direction working for CloudBees.

So, I guess that the people, at the end of the day, are a secret source. So, even if other people want to come and extend it or do it in a different way, I think we’re always kind of focused on what’s the vision, how is this going to evolve, how we’re going to keep pushing the industry forward. It’s a concern, but we try not to spend too much time focused on that, just more time focused on what do the users want and where are we headed.

SaaS V. License?

Michael Schwartz: In terms of monetization strategy, is the Enterprise license the majority of the revenues, or is SaaS the biggest part of the revenue stream?

Tracy Miranda: Yes. Enterprise licenses are definitely the main focus. I think that will evolve over the next set of years, but, for now, that’s certainly the case.

Pricing

Michael Schwartz: Few questions about pricing, which is hard for a lot of startup entrepreneurs. Many organizations are using Jenkins for free – is it hard to move these customers to a paid offering? What type of gates do you define? Is it per developer? And is pricing still evolving with new offerings, or have you achieved some stability in the pricing area?

Tracy Miranda: Yeah. No, I think this is an area constantly evolving. You know,
Jenkins is a great tool, and a lot of people can do a lot of things with that
anyway. So, we’re always looking to add value on top of that. So, we find a lot
of the customers who see the value of CloudBees, they’re focused on what they
need to do as a business, they don’t really want to be messing around CICD is
not their value add, so they want kind of the complete package. And that
includes the ability to get support and the ability to know things are going to
work for them.

When you are sort of doing things in open source
by yourself, you tend to run the risks yourself. You can pick up plugins and
you have to decide, are these going to work for me, are they going to have the
security patches attached. And what happens if something goes wrong? You know,
you can’t pick up a phone and kind of call up the open-source community and ask
them to fix your thing in a timely manner. That being said, it is a constantly
evolving space.

So, I think kind of the offerings and the bundling and the way that works is always evolving. And like we will do things as well, like offer kind of more analytics on top of that, which give people sort of more insights in what they can do with their systems, and yeah, that’s just constantly growing,

Partnerships

Michael Schwartz: What have been some of the more important partnerships for CloudBees in terms of specially impacting the business?

Tracy Miranda: In today’s world, I think you really can’t succeed as a company
on your own – we had a recent kind of partnership program, which I think we’ve
got a whole bunch of companies who we were working with. My
main tendency is to be on the open source and on the
Continuous Delivery Foundation – it’s not partnerships in the traditional sense,
but a lot of companies on the open-source side we’re working with closely.

And the other big one today is the partnerships with the cloud providers, and with those we have really strong relationships. I think every cloud provider has a marketplace out there, and you can easily access all CloudBees products very easily from the cloud marketplaces. I think this year we’ve also named the Google Cloud partner of the year, so, yeah, a lot of strong relationships, especially towards a whole Cloud space.

Project Governance

Michael Schwartz: You have a lot of experience in this area, so I can’t resist asking, but companies can host their own open source and build their own governance infrastructure around their project, or they can move to a foundation that can help maybe attract a larger community. What’s the strategy of CloudBees there, and how’s that evolved over the years?

Tracy Miranda: Yeah, a great question. So, Jenkins itself pretty much had its own governance, and that worked well and served the community really well for the first kind of ten, fifteen years. You know, it is very alike with model software in the public interest, it provides some great services. But, eventually, it got to a point where there was some kind of sticking points in the community. These were things sort of shared widely with the community.

Some key things like just having a business
entity so that we could get signing certificates, having a more kind of ability
to hire for roles that want developers, but other kind of things that are key
to software projects, but you don’t necessarily get contributions for. And
again, the ability to build a bigger community.

So, these are kind of some of the limitations
that we hit. So, Jenkins got to a scale, where it needed to grow past that and
to get companies interested and understanding it, they needed a really kind of
known model, which is why it then looked at setting up Jenkins in an
open-source foundation. And that led eventually to the Continuous Delivery
Foundation forming, which is, as the more we talked to folks, the more it made
sense, not just to have a single project foundation but to have something where
a bunch of folks could come together and work towards a bigger vision.

So, that’s been the key thing. The creation of the Continuous Delivery Foundation is what have helped launch over the last year. And that’s been a major kind of change, both for Jenkins and for CloudBees as a business.

Fostering Diversity at CloudBees

Michael Schwartz: You have been an advocate for a
diversity. And I am wondering have you been able to have an impact on how
CloudBees builds the team?

Tracy Miranda: Yeah, I think diversity is super important for all sorts of
reasons, but especially for business ones. I am very lucky in my position, I
head up the open-source team, I’m a hiring manager, so, in a great position to
kind of influence that at CloudBees.

So, I have a great team, and I’m happy to say
very diverse on kind of multiple accesses. You know, gender and age, and from
where we are across the world. So, that’s been really nice.

We also have lots of initiatives at CloudBees. One of the things I’m pleased to say is, there’s a lot of people doing things like CloudBees, and kind of constantly changing the status quo, which is nice, because it’s not always something I have to do, and then I can just kind of focus on my main job. But, yeah, a lot of great folks pushing things in the right direction.

Pandemic Impact On Diversity?

Michael Schwartz: We’re recording this episode in May of 2020, so the pandemic
is on everyone’s mind. It’s easy to look at all the negatives, but being an
entrepreneur, I think I’m inclined to look at positives. Is there any way we
can spin the pandemic as a positive around creating more diverse teams?

Tracy Miranda: That’s really interesting. But I think by moving online and by a
lot of companies had this almost artificial limit on, where people can be hired
from and all having to live in specific areas, which are often cities, which
often have big barriers to entry in some cases. I think by going virtual, you
do remove some barriers, you do make it easier for people to be hired from
wherever they are, and all of a sudden, that does open up the field for people
you can hire from. So, I think, in that way, it can be very positive.

How To Catalyze Gender Diversity In Tech?

Michael Schwartz: Just speaking from my
own personal experience, my company is very globally distributed in terms of
team members, we have team members from like every continent, except
Antarctica. So, we are doing an okay job in terms of diversity, but in terms of
getting more women on the team, we’ve faced some challenges.

I know you’ve talked a little bit about this topic, but maybe you can share why do you think there aren’t more women in tech, and what are some of the challenges that women face? And how can we maybe help more women get into the tech business?

Tracy Miranda: I spent a lot of time over the last three or four years trying to
understand for myself, because I think at the beginning of my career, I took it
a bit for granted. I thought this is just the status quo, this is how it is, but
I think it is down to kind of a number of factors all coming together. And you
know, unconscious bias tends to be a big feature.

We’ve got just a ton of research that shows how lots
of different things have compounded things over the year. I think there’s a
great NPR Podcast as well, which talked about the times of women started
dropping out of computer science courses. And it was almost because computers
in general were marketed towards boys. And it was very difficult for them to
sort of coming disadvantages to the
courses, and there was not a lot of empathy for that. So, I think that that’s
kind of one factor, but there’s a lot of other things in general that play out,
just networks and how people bring people into companies.

So, the good news is I think we have more
awareness than ever before of what it takes. And then, there’s a number of
things we can do. The bad news is, you almost have to keep at it constantly,
and things change very, very slowly. But we know, for instance, just
representation matters hugely. So, having more women voices, having more women
in higher position kind of modeling — I think there’s a great expression “You
can’t be what you can’t see.”

And then, just having more not just mentors for women but sponsors who are ready to kind of pull them up in the right channels, help them to get and meet their goals much faster. And I think we’re getting a lot more systematic approaches in place to do this. And actually, I was really glad to see with your podcast, you have a lot of the recent guests have been some very frankly incredible and awesome women. And I think that’s places you start, just having that representation, having those people talking and telling their story.

Advice For Open Source Startups

Michael Schwartz: Thank you. We are doing our best. So, last question, you run
your own company for a decade, and you’ve been around open source for a long
time, so I’m sure you’ve seen some successes and failures of entrepreneurs who
have tried to use open source as part of their business model. If you were
starting out from fresh today, you wanted to use open source and build a
business around it, do you have any advice for that person about how they
should go about it?

Tracy Miranda: I think there’s a lot that gets said about kind of open source
and the relationship with business models. I think I completely buy into it.
Building off open source has so many efficiencies and so much kind of leads to
a lot of serendipity.

I think you see a lot of startups today embracing
open source and understanding that it’s not just open source in the sense of
code, but what you’re really doing when you embrace open source is building out
a community. And I think people understand more than ever how key developers
are to any product and how key that community is.

So, not that open source is the only way to do it, but it’s such a great way to do it, and I think the main advice would be: if you’re doing it, you have to commit to it completely. You can’t kind of be half-hearted about open source, you have to commit to the vision and to the community and constantly growing it and tending to it like garden. And then, it will play huge dividends. And we have seen the companies who have done really, really well off open source. It’s just kind of really sort of impressive.

Closing

Michael Schwartz: Tracy, thank you so much for spending some time with us
today. And best of luck with CloudBees and with the Continuous Delivery
Foundation.

Tracy Miranda: Thanks very much for having me. It’s been great.

Michael Schwartz: Thanks to the CloudBees team for helping us to promote this episode on social media. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics by Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

James Watters, SVP, Products at Pivotal Software, is a veteran of the unix and open source software business. With a broad breadth of products, including Java Spring and many other essential tools for developers, Pivotal has built a business of enormous scale in record time.

Intro

Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 40 with James Watters, SVP of Products at Pivotal.

Pivotal is probably best known for the success
of Spring, the most popular way for developers to write Java applications, but
they built a great business around the Pivotal platform, which enables large
businesses to manage a unified, multi-cloud software infrastructure.

Pivotal is a little different than your typical
open-source startup. Spun out of EMC and VMware in 2012, and IPO in 2018, and
shortly before I recorded this episode in August of 2019, VMware announced the
definitive agreement to acquire Pivotal, a combination that’s expected to close
in 2020.

James makes the case that open source is winning
because it’s innovative feature-rich and enterprise-ready. He has a deep
understanding of both the technical and business mechanic that make open-source
companies tech. I’m sure you’ll enjoy this interview, so without further ado,
here we go.

Pivotal Background

Michael Schwartz: James, thank you so much for joining the podcast today.

James Watters: Great to be here, Mike. Hi.

Michael Schwartz: So, you were trying Pivotal in 2012 when it was formed, and for the listeners who don’t know the backstory, maybe you could just drive a little bit about how that came about, and perhaps about how it’s coming full circle to some extent.

James Watters: I was fortunate enough to join a open-source research and development team at VMware in 2010, working on an open-source project named Cloud Foundry, and we didn’t really know what it would become as a business. It ended up, they decided to spin that out along with another open-source project called Spring Source, or Spring, into its own company, and that was one of the foundational product elements of the company called Pivotal.

Michael Schwartz: What’s your current role with pivotal?

James Watters: I’ve done a lot of product work at Pivotal. I’m currently SVP of Strategy, focused on new parts of our product. I’ve been focused on things like streaming, container-as-a-service, function-as-a-service, all the emerging areas of our product.

Size Of Product Team

Michael Schwartz: Just to give everyone a sense of the scale, could you give a rough estimate about how many product managers are Pivotal, and the total size of the product team?

James Watters: It’s pretty expensive. There’s hundreds and hundreds of engineers that work on the platform at Pivotal, and I would say 50 full-time product people working and supporting them.

How The Product Management Has Changed In The Last 15 Years

Michael Schwartz: When you were at Sun a while back, you were a product manager of Solaris, which is a pretty epic assignment for those of us geeks who revere Solaris. Since then I’m wondering, could you comment about a little bit about how has been an open-source project manager evolved? Like, what’s different now?

James Watters: That’s a great question. The cycle time was so different on Solaris. And that was an 1100-person engineering team. And then, on the kind of customer-facing product front, I think we were under 10 people. It was very much engineering organization, product provided a bit of input and amplification of key customer themes. We worked on often multi-year release cycle.

In the new world of open-source, the community input comes so fast. It’s a different release cadence. Our core platform PCF at Pivotal, we released every quarter. And that was a big mindset change for me versus some of the older world at Sun. It was just how fast everyone expected you to respond. It’s not uncommon now to meet with a client. And in a matter of weeks, we will have a feature changer update shipped to them. It’s a completely much more iterative world of continuous delivery, both at the platform as well as what we’re trying to inspire our customers to do for their end users. So, I think that’s dramatically changed since.

How Smaller Organizations Can Improve Product Management

Michael Schwartz: If you’re not Sun, you are VMware Pivotal, but you are so much smaller. Do you have any suggestions for some of the little things that you can do, or that it open-source company might do around product management?

James Watters: I think that’s really opening a question, and I don’t want to speak conclusively on it, but I think what I’d say is, there’s kind of two ways of coming at it. And my specialty is always being understanding the enterprise organization that the product fits into.

There was a point in our journey, where we felt adding
additional features around security would probably be neutral to the developer
audience that was using the platform, but what actually bring like the chief
security officer and her team deeper into the conversation.

Suddenly, we approached a few banks, and we
said, “What if we could rebuild this entire platform infrastructure every day for
security?” And we had a really brilliant product person at the time named
Justin Smith, who let this initiative to articulate the idea of the much more ephemeral
approach to the platform.

I think the reason I mention this is, you could
have gone deeper on just developer experience, but by finding that other
constituent in an enterprise that come to the negotiating table around why
we’re giving money to this company, that really changed the game for us and a
few clients, because the chief security officer was now also an advocate.

I think it’s challenging you doing open-source products because you might get a lot of feedback from your immediate community and immediate users. But in order to sell the products to a larger organization, you need to think about articulating investments to a broader set of constituents.

Pivotal Products

Michael Schwartz: You mentioned PCF for Pivotal, Cloud Foundry. For those who don’t know, maybe you could just tell us a little bit about what that is, or also walk us through some of the other product offerings at Pivotal.

James Watters: I’ve been fortunate enough, Palmer at VMware hired couple of Google engineers in 2009-10, to come build this platform out. It was really like what you might call the Cloud Native platform world today.

At the time, there was no such thing as
container-as-a-service, and at the application level, there really was no micro-services,
and continuous delivery was sort of a very radical idea of enterprise. It was
sort of the first platform built with the container first design, built to
enable continuous delivery of things that look more like micro-services than
monolithic applications.

And kind of was the first investment in this
Cloud Native space, in terms of application platform and culture, all coming
together in a platform.

That was really what PCF did, and we were able
to scale it from zero sales in 2012. Or the spin that was first contemplated to
hundreds of millions of dollars in sales, and ultimately the background of a
public company.

Market Segmentation

Michael Schwartz: Cloud Native is a broad horizontal market. Do you segment the market at all by vertical industry or use case?

James Watters: This is another thing around products. For me, products strategy is that I do think that vertical use cases are critical. I’ll give you two examples. In the banking world, there is a huge focus on Java, because it’s traditionally a Java-centric custom application world.

Banks were always willing to invest in the
high-end applications that often was built by Java developers.

When I first started and till this day, banks
are, I would say, the number one language in banking is Java. They are very
security-centric, they operate in a highly-regulated world, and they tend to be
very hybrid cloud. There’s very few banks that run public only.

They were a tremendous fit for the design of
PCF, both from support for Spring Boot as well as its core security
differentiation.

We absolutely thought of a lot about banking, insurance,
regulated industries. Then, manufacturing and industrial was a little bit
different space. There you had a lot of the IoT world, you had streaming data,
you had a completely learning how to build software for the first time way of
engaging, where industrial companies were just getting started on major
software investments.

I definitely think about vertical segmentation. I
think for anyone who’s contemplating a sort of customer first approach to
product thinking, vertical segmentation is a good early model to take on.

How To Decide What To Open Source?

Michael Schwartz: Pivotal has 73 projects in GitHub, and I’m sure that there’s more in private repositories – how do you decide which projects to open-source?

James Watters: I think, by and large, we tend to be an open first-style company, as I mentioned on the Andreessen Horowitz podcast awhile back, I am an advocate for sometimes keeping the UI, closed-source can be a simple way of differentiating between the pure-community efforts and the final enterprise products. But in general, we’ve tilted towards open source first.

That’s also been a key part of our relationships,
like I mentioned, with certain banks.

A lot of the core security infrastructure of the
platform was all kept open source, because the banks felt more comfortable
consuming a platform that was opened first, even in those core areas.

Value Prop

Michael Schwartz: When you have a lot of projects, is it difficult to position the value proposition of the company?

James Watters: That’s a great question. If you think about how many projects you want to take on, like say, MongoDB is a fairly focused company. One core thing, Elastic are fairly focused company, but you get into the platform world, companies like HashiCorp are very successful at doing multiple projects. I think Pivotal is probably one of the broader breadth open source company is out there, certainly Red Hat has a pretty broad breadth. You hit a point where you become the platform provider of choice for their next generation of design, and actually the pressure comes to do more and more and more.

One of the biggest pressure points for us was
always like, “Okay, we love this as an application platform. Now, provide us
the whole universe of data services on the platform.” And so you have to
achieve a certain critical mass to have the scale to invest like that.

But I do think that in enterprise segmentation,
it’s powerful when you can start to have people accept the offerings you do
have. And then, the biggest pressure is, “And now add this, so I can have one
coherent approach. And I think that that’s something really important for open-source
companies to think about it. Like, “Look at how Amazon operates. They are not a
federation of hundreds of little hosting providers all coming together. They
really have that sort of single point of interface to all of their abstractions.

I think that’s an interesting dynamic in the
world right now. Open source is like, how broad you should go in your
portfolio, do enterprise buyers favor that, is it better to be lower and single
products – that’s something we discussed.

Pricing

Michael Schwartz: With a lot of products, containers, Cloud Native services, it seems like it’s harder than ever to figure out how do you price. There’s more things you could gate on and the more elasticity is given, I know us, at my company Gluu, a lot of challenges because of CPU that depends upon the time of day. Can you talk about the evolution of pricing, and did you get it right initially, or did you have to make some tactical adjustments along the way?

James Watters: I think that’s a great question. I think it’s never easy or straightforward, we made a decision that we were going to go after the largest thousand companies in the world predominantly. We were going to supply a lot of technical resources to them, to ensure that they were successful with our product, and very much be an outcomes-focused company.

I think we intended to price at the higher end
of the market, and that was a very deliberate choice. And I think as we’re
growing now, we’re seeing more opportunity to start to segment the offer. To
have a more transactional approach, we reintroduced the container-as-a-service product
that didn’t have as many features as the full platform, but was something that people
were ready to pay for more on a transactional basis.

I think that there is this tension between the
desire to have a broader platform versus to be more transactional, and that
very much comes back to customer segmentation. I would think of pricing in
terms of how transactional you want to be, and then what the customer really
expects out of you to make them successful.

Like, what does customer success really look
like – it has to be at the core of your pricing model. If the prices are really
low, and they’re not successful, that’s actually not on either of your interest.

Competition

Michael Schwartz: Does Pivotal actually have competitors?

James Watters: I don’t think that Pivotal has a company that is assembled just like us. We have some unique assets, one of the reasons we were successful in enterprises is, we have the number one way that enterprises build apps in the Spring Boot.

So, when it comes to like
how enterprises are building applications in the Spring Boot, it’s probably
easily the number one, and it might be over 50% market share of net new enterprise
applications today.

There’s not another
company that has that. We also had a very big git, and we were owned by kind of
the Dell VMware family of companies ultimately. So, we’ve always been able to
go to market with them, but we really still did have to earn our own way. But we
could get introductions.

I think all of those
things came together in a way that allowed us to build a higher-end platform to
focus on the top 2000 companies in the world, and to go make them successful, and
to price and package accordingly.
I think one of the challenges right now for smaller open-source companies is, these
cloud platforms that are open-source, they keep adding features that are pretty
high rate. So, you may think that one day, you have a company, and the next day,
that’s a feature of a cloud platform. And I think that’s attention.

Certainly, in the
service mesh world, you see disruption of kind of traditional networking and
API management, coming in the way that people are adopting a service mesh, etc.
Is that a company, is that a platform – I think that’s a very dynamic part of
the market right now. It’s pretty important, and I don’t talk about it too much,
but I really do enjoy working on open-source projects because they can have a
breadth of impact that’s pretty unimaginable to something that you have to
commit a sales transaction and for software before someone can use it.
We have an asset at Pivotal, Spring Starters, and they’re the number one way
that people get started with a new job application. And that’s start.spring.io.
You start a new job project there.

Every two seconds a
developer on average is going there to kick off a new project.

And the top three
countries for it are China, United States, and India, but these are the kind of
impacts that open-source can have worldwide, deep into developer impact that
you can never do with closed-source only, enterprise sale only products.

I think just the
unimaginable breadth that open source can get you in ubiquity, that it can get
you in the modern world is stunning. So, that’s what I’m humbled to work on. I
think the challenge is then like, “Well, how do you make sure that the largest
5,000 organizations in the world are contributing to that?” And that’s where I
do have a passion for enterprise monetization of open source, and finding ways
of partnering with those organizations, and packaging, and pricing things, such
they feel that there’s good value. And partnering with these open-source
companies and making them their most meaningful platform.

I think I’ve got there two minds, number one, open source is super important just from a long-term impact the world, it’s harder to work on projects, they can have a bigger one than open source ones. And then there is the challenge of like, “Well then, how do you build the economic model around that when it’s so ubiquitous to begin with? That’s the kind of challenge that I’m taking on, and I’m humble to be able to work on open source for enterprises for that reason.

What Types Of Software Should Be Open Source?

Michael Schwartz: Do you think that certain types of software lend themselves to being open source?

James Watters: I would say that the developer workflow today – and that’s not my line but I like it – it starts with “Git clone.” And I think any saying, where a developer is initiating a project in this era, it better be either a really easy to use API, I think Stripe certainly has proven that, or, it better be something like start.spring.io. Or, git clone, something that a developer could just go grab in a permissionless kind of way. And Adrian Cockroft at Netflix said that, back when he was at previous companies, there were these big architectural debates for months before a project would start. And that in Netflix you really implemented the running code talks. It’s all about running code. I think that that is the reason why open source is really powerful for anything having to do with developers.

And then, on the infrastructure level, open
source has become the most profound way that large vendors collaborate. If you
look what’s happening in the Kubernetes community, where you have every major
public cloud contributing to Kubernetes, IBM acquiring Heptio to make major
contributions to Kubernetes, in infrastructure, open source has the way that
these, what you might have had standard bodies before, there’s sort of like a
running code way that large vendors are collaborating. Both, in the end-user
developer space as well as in the infrastructure space, open source had a huge
impact.

But if you think those worlds are slightly
different, the dynamics of start.spring.io, which is very end-developer focused
versus the way that every public cloud is normalizing how they run Kubernetes
are slightly different, they’re all open source but they have slightly different
behaviors and attributes. And it’s kind of fascinating to see database
companies like MongoDB a little bit different than the way that the Kubernetes
community is operating.

Do Enterprises Care About Open Source?

Michael Schwartz: Do you think that customers actually care about open source? I mean, large enterprise customers?

James Watters: I think large enterprise customers absolutely have seen the tremendous benefits in just frankly the innovation velocity of open-source products. And I think the biggest change is that in the early days, open source was a cheaper version available for free of the enterprise products. That’s what I think it was especially hard to monetize.

If you’re just going to
be the cheaper thing and the low-cost provider, and not the premium product, a
lot of enterprises might look at that and say, “Hey, we’re an enterprise, we
can afford to buy whatever we need. We just really want innovation leverage, like
we want the best product.

But I think there’s a
new whole category of products, or there’s only an open-source player that is
creating it. Like PCF was the kind of first micro-services platform in the
world for enterprises. And it was built a 100% open source. It was both the
market leader in terms of features and the open play.

I think the open-source
market is changed, where there is room to be both innovative, or the
expectation is that they’re both innovative, higher-end, feature-rich as well
as enterprise-ready – all of that is expected from open source today. I think
that’s where the innovation is happening.

If you look – here’s an
example – Amazon has a service Kinesis, which is how they were doing messaging,
and it did a pipelines. And now they’ve switched that to a managed Kafka
service. They had to do that because the innovation was really happening in the
Kafka community in open source. Even on Amazon scale, they couldn’t keep up
with it.

I really find that to be the best part of the market right now is that you can’t out-innovate the open-source players.

Cyclicality Of Centralization

Michael Schwartz: It seems like there’s sort of a cyclicality between centralization and decentralization. For example, a couple years ago, everyone was at full tilt towards “Go to the cloud.”, and now, it’s almost like with Kubernetes and other technologies – is there any shift away towards maybe bringing more of this type of functionality in-house, and does that help a company like Pivotal?

James Watters: When I talked to CIOs about this, I tried to help them deconstruct the current cloud market, and what I told them is, “Public cloud is not one thing. It’s really three different zones of features that you need to think about. The first is the commodity layer, which is, “Hey, I’m just buying virtual machines, networking disc, the basics, and that’s kind of where public cloud started.

There, you can use a platform like Kubernetes,
and run those system resources in similar ways, if not identical ways, across
public-private, hybrid multi-cloud. So, I think Kubernetes has done a
tremendous job of making those system resources normalized across all the
clouds.

Then, I think there is this emerging space
within the Cloud Native community around the open-source developer focused
projects that run on Kubernetes, like Kafka, like Spring Boot, really like Pivotal’s
platform. That’s where the developer innovations come. That’s like the open developer
innovation community, that’s number two.

And the number three is, they selectively are
these managed services like Google Spanner, Google Machine Learning, or you
might be ahead of the market, where there might not be an open play there yet, where
Spanner requires dedicated fiber networks between data centers to make the
database magic work. So, there are areas we are the managed cloud or head.

Our perspective is that innovation in the core, where
you are really arming your developers, continues to happen in open source. Commoditization
can be achieved through technologies like Kubernetes running in a normalized
way across clouds.

And then, technologies, like the Open Service Broker,
relay to buy these managed things. Long story short, I think what’s happening
is, the CIO’s are getting smarter about deconstructing cloud from this
monolithic idea of “I go all in one cloud.” to like, “How do I selectively use
what’s best about each cloud?” I think open source is playing a huge part of
that.

Should Open Source Be Less Expensive?

Michael Schwartz: You touched on this a little bit before, about how open-source software maybe should be cheaper. I think that there is a sort of perception for some reason that even though you get more rights with the license that the software should be less money – do you think that that is changing, or is that something that is an industry we need to work on with customers?

James Watters: I’m a maybe a contrarian here, my dream was always a very open product that generated a lot of value that enterprises were excited to invest in the platform partnership in. And, essentially, I don’t think that open source should have to have cut rates levels of investment into research and development vs. closed source.

My contrarian nature there says, “If you really
have the right relationships with these customers, they’re going to be just as
happy giving an open-source provider money as they are giving Oracle money.” I
mean, if anything, I think that open-source partnerships are valued in a more
profound way in the modern enterprise that might be even happier to give you
more money than Oracle.

I do think that that something is happening. That
also comes back to how these open-source companies engage with these large
enterprises, are they focused on them, do they understand their vertical needs,
do they put security first, are they able to measure the outcomes that are
achieved with their platforms?

Closing Advice For Entrepreneurs

Michael Schwartz: Last question. Do you have any advice for entrepreneurs who are starting new ventures based on open-source software?

James Watters: I think my advice would be, if you really develop a community around your open source, you’re one of the luckiest people in the world. That’s a tremendous gift. Save and invest in that community, but also spend some time understanding how that technology fits into the value chain, in the largest thousand companies in the world, and investments they are making in technology.

Try to balance the needs of the developer who’s approaching
it from a ‘git clone, let’s get started’ perspective, as well as the more
complex matrix or matrices of a large enterprise organization, and what they
need across security, operating, certainty SLAs, etc. If you can get those two
forces right, then I think you’ve got a remarkable opportunity. But I do think
that monetization, and ultimately funding a great R&D team behind your open
source project, takes a balance side towards both.

Closing

Michael Schwartz: James, thank you so much for taking your time today in this really pivotal moment in Pivotal’s trajectory.

Shannon Williams, Co-Founder and VP Sales of Rancher lays out how a great team with deep domain knowledge can actively identify a product market fit in a crowded space, and emerge a winner. It’s an inspiring story of a plan perfectly executed. This is a MUST LISTEN episode of Underdogs!

Intro

Michael Schwartz: Hello, and welcome to the Open Source Underdogs podcast. I’m your host Mike Schwartz, and this is episode 39, with Shannon Williams, Co-Founder and VP Sales of Rancher.

Let’s go for a minute
into the land of hypothetical. If I can ask all 38 previous podcast guests a
question, “Is monetizing support a good idea?”, I think there would have been
virtual consensus that support doesn’t scale. Except, Rancher is perfectly
executing a business plan to do just that.

I hope you’ll enjoy this episode. Tweet your comments at @fosspodcast, and we will asynchronously discuss in the Twitter sphere, but for now, here we go with the interview. Shannon, thank you so much for joining us today.

Origins

Michael Schwartz: Can you just fill us in a little bit about how Rancher got started and what was the mission?

Shannon Williams: We’ve been going now since 2014. In a lot of ways, it feels like we started before that, because my co-founder Sheng Liang, Will Chan and I, the three of us started another company called Cloud.com back in 2008. And, for all intents and purposes, we’ve been working together every day for 11 years now. That company was an early developer of open-source infrastructure-as-a-service software.

We built a product called CloudStack with the
founding members of the OpenStack foundation. I had a really fun run there for
about three years before being acquired by Citrix, and spending another three
years at Citrix.

In our work on CloudStack, we learned a lot
about, as you can imagine, managing infrastructure at scale, building out
private clouds, helping a lot of large companies build public clouds. At the
time, everything we were focused on was how do we deliver virtual machines to
developers quickly from anywhere.

But over the course of working on a lot of
private clouds, we noticed that we had a lot of conversations with people
trying to figure out how to blend their on-premise infrastructure with this
growing amount of cloud infrastructure.

One of our early customers was GoDaddy actually.
They were looking at building a public cloud, and Darren Shepherd, our fourth
co-founder of Rancher, was a Chief Architect there. We got to know Darren
really well.

We started talking in 2014 about what could be
done to bring together the on-premise infrastructure, the cloud infrastructure,
into something that overlaid it all, and to really allow people to treat
infrastructure like Cattle, like a disposable commodity. And Docker was just getting
started, the concept of Containers was emerging, and we thought there was a
really cool opportunity to look at leveraging that, to build out management tooling,
infrastructure services, and kind of imagine the next generation of infrastructure
management, which would hopefully enable people to do computing anywhere, with
really consistent deployment experience, management experience, monitoring
experience, all these types of things.

And so, Rancher was born. For almost 5 years now,
we’ve been working on continuing that journey, how to build open-source
products that are available to anyone, and really allow them to run workloads
anywhere. So, that’s really where we came from.

Value Prop

Shannon Williams: Rancher is open-source software, we have a number of open-source projects but our most famous is called Rancher, and it really sits at the management playing around Kubernetes. Organizations use Rancher because they are deploying and managing more and more Kubernetes clusters.

Rancher provides distros of Kubernetes. We have
one called RKE, which is a pretty typical, upstream distro, it’s really good
for deployment, automation. Then, we have one that’s optimized for the Edge or
other low-resource utilization called K3s.

We provide distros of Kubernetes to people that
need to run Kubernetes, but Rancher itself actually sits above those distros,
it’s the management client. What’s cool about it it’s really distro agnostic.
It actually manages any Kubernetes. And by managing, what that means is an
organization implements Rancher so that they can deploy and control, and then
grant access to dozens or hundreds of Kubernetes clusters – some running in the
clouds, some running as hosted services like GKE, and EKS, some running on
premise, maybe on the Edge.

By bringing all those clusters together, what
Rancher allows them to do is, dictate policy, control access, monitor
availability, manage deployment of applications, manage catalogs, attach additional
open-source services, like Prometheus for monitoring, or Fluentd for logging,
or Istio for service match, and so, Rancher sits at that next. So, how do I
manage Kubernetes everywhere according to my organization’s policies.

By doing that, it enables them to then really deliver their service reliably. For organizations, they think of Rancher as the Kubernetes platform, it’s Kubernetes as a service, it’s how they deploy apps and run anywhere.

Monetization

Michael Schwartz: The Rancher GitHub repository has 14,000 forks, which is really a lot. But there’s only around 60 something developers, which I could see is probably primarily being the people in your organization – can you talk about the relationship between the open-source project and the activity there, and the SaaS service?

Shannon Williams: Just to be clear, we don’t offer a SaaS service. Rancher is open-source software only. We only provide open-source software that people use, but what we sell is support for those open-source projects.

On any given day, there’s about 30,000 teams
around the world running Rancher. Those teams, they may be a smaller group that’s
deploying it for one application. There’s maybe somebody doing a Dev lab, or
test lab, but of those about 1%, about 300 enterprise customers, these are
companies that deploy Rancher, and whatever they are running on it, it’s
critical to their business.

They contract with us to provide
enterprise-grade support for Rancher, RKE, K3s, and really their whole
Kubernetes stack up and down. By providing that Enterprise-grade support, what
they get from us is the confidence to run really important workloads on the open-source
Rancher, but what they like is that we don’t have your classic open-core only
model, we don’t sell version that’s different to them. They just pay an annual
support subscription, and they use it.

A year later, if they are no longer using it,
they are not paying an annual support subscription. They can keep using the
software, but they would be using it again without support.

Our model is geared around helping organizations that need support, get the best possible support in the world for Rancher, Kubernetes, Prometheus, and Istio, and all the pieces of technology that we deliver to them.

Why Open Source?

Michael Schwartz: Has open-sourcing the code really made a meaningful contribution to the company?

Shannon Williams: It’s at the root of our success. By open-sourcing the code, we enabled a startup with relatively no name recognition obviously, to come into, in a lot of ways, it’s a very crowded market.

Think about the companies that are dealing with
application management platform as-a-service. When we started, you can imagine
Docker, Mesosphere, Red Hat, Pivotal, these companies were already out there.
You know, Docker, in their sense with having released the Docker project,
orchestration and building different types of management tools, and with enormously
more funding than us, much, much, much bigger brand recognition teams.

We had to find a route to market with limited funds,
we needed to let our product be our best piece of marketing, and so we took
that approach. We believed in this for a long time. In our last company, we had
a very similar approach. We made Rancher fully open source and free because we
felt that it was the best way to get adoption, to plant seeds in organizations that
would need this technology.

By putting it out there, we really bet on two
things. We bet that people would like it, and that they would want to use it, but
we also bet that this technology was crucial. And that at least a good chunk of
people who use it would find value in getting support for it and find value in
having SLAs that they can rely on for that application. And we’ve been
thrilled. I mean, our company’s now almost 200 people, we’re more than doubling
this year. In terms of revenue, it’s really worked out really well.

People really do love Rancher. It’s something
that makes me really confident with the model as you have to believe in your
engineers, you have to believe that products can be great. We also spend an
enormous amount of investment of time working with our open-source community.
We have a huge Slack community of thousands of users who come in with
suggestions and ideas on how to make the product better. We get thousands of
issues, and feature requests, and bugs filed by the community.

I don’t think we have more of a user community then of a contributor community. I love it because they come to us with real problems that need to be solved, and I identify them. Often, their use cases sometimes are pushing the boundaries that we may not see out of a Fortune 500 company that’s using Rancher. So, it all sort of pushes forward with the hopefully creating a great product for everyone.

More On Why Open Source…

Michael Schwartz: So, just to sort of dive a little deeper on that. If you made the software commercial tomorrow, do you think the 300 or so Enterprise customers, who are using the software, do they really care about it being open source? Or is it just a non-sequitur, or they just want the best software? So, if you made it commercial tomorrow, do you think that that would be bad from where you are today?

Shannon Williams: Yeah, I do. When I talk to organizations about our business model, they get really excited because there isn’t one of them which hasn’t been in a position of really limited leverage against their current vendors. Everybody has been staring at just massive renewal orders.

We closed, just this quarter, today is the end of
our third quarter, and we closed three deals with organizations that are
spending a lot with us, half a million a year in recurring revenue, for
example, to support environments. And their frustration in some cases was
platforms that they had built, PaaS platforms, where the cost had grown
exponentially. And they just had no ability – even though these were all based
on open-source, they weren’t themselves open source. I mean almost everything
is based on something, open source at this point.

What people really like is, they like an open-source
product, because they always have the option to leave it there, let it run,
support it themselves, hire some engineers and figure it out. In the end, if
you are running a proprietary tool, and you don’t pay, you have to yank it out
of production. And that is impossible for most companies.

I think our business model, yes, some people would still buy a Rancher, and be fine with it, but I think a lot of the smartest CIO’s I talked to are really excited to see a company like us, that embraces open source for commercial purposes, provides really good support, and is committed to building open-source products. For us, it’s allowed us to grow faster than any other approach I’ve been able to come up with.

Pivot To K8S

Michael Schwartz: Seems like Rancher made an epic pivot towards Kubernetes at some point, I guess, fairly recently – what did you learn from that process?

Shannon Williams: Well, the hardest part about getting into any market is making bets, and then figuring out where they come down. Rancher started about the same time as Kubernetes. Right around 2014, Kubernetes was starting at the same time we started our company.

At the time, we really thought Docker and their
Swarm and stuff were probably more likely to win out. They had so much
momentum. But it only took a year to realize that Kubernetes was actually
really well-built piece of code.

So, when we first started working with them, we
were kind of thinking we would be managing Swarm clusters and Mesos clusters,
and then, even before we launched our 1.0, we decided to support Kubernetes,
because it was a really good piece of software.

So, we released our 1.0, our first product to
the market in 2016, Rancher 1.0, at the time, if I was talking to them, I would
have said something like, “You know, it seems like different companies are
choosing different orchestration approaches to containers because they need
different things from them.”

Some people want to scale really big, like
Twitter. So, they’re using Mesos, other people really focused on the developer
experience, and they’re choosing Swarm. And it wasn’t really clear yet that one
standard was going to emerge, but what we started to see was some stability
issues with some of the other orchestrators that we saw as a manager. It was
like, “Ah, these things aren’t stable as I would have expected them to be.”
What we found is that Kubernetes is really reliable.

So, as we imagined our business, and trying to
support these technologies and helping companies implement them, we felt like
it was safe to bet on something reliable, and that did require pivot that moved
away from messaging, and product development had gone into supporting, we built
our own thing, we had Swarm, we had Mesos, we weren’t really sure what orchestration
was going to take off. But as we got more comfortable with Kubernetes, and
luckily, we started working on it early, it made it really easy for us to honestly
commit to something we liked.

By that point, by 2017, we were all in on Kubernetes
building on that. And since then, we already had a lot of people using it in our
1.0 product, we also had a really nice base installed, we didn’t just lose.

So, a lot of times, you have a pivot, and it
means almost starting from scratch. But actually, we didn’t really lose hardly
anyone because it was very much in line with the direction that most of our customers
wanted to go as well. Even if they maybe chose a different orchestrator, they
also saw the market going this way, so they were really, really appreciative
that we gave them a path to get to Kubernetes off of maybe something else they
had chosen when the market was still a lot less clear.

We found that that wasn’t nearly as big a
problem. Now, what is hard in pivoting, especially, one of the things we built
was our own orchestrator called Cattle, and one of the hardest things was
actually convincing our own engineers that the Kubernetes was actually superior
to what we had developed ourselves.

That’s a hard thing to do because no matter
what, if you built something, you’d always love it. And at the same time, in an
early market like we were in, lots of people loved the thing we built, a lot of
people telling us, “Hey, we really like this Cattle. It’s really good and you
should just keep improving that.”

But as an entrepreneur trying to build a
business, you have to be really, really honest with yourself, and you have to
really look at all the signals, not just the ones that maybe are giving you the
positives you want to see.

All the signals told Sheng, and I, and Will, and
Darren, that we needed to really focus our business on solving the problem that
we thought most organizations were going to have. And that was, how to take Kubernetes
to scale, how to bring together a really complex ecosystem around it, how to
build a platform that would work.

That meant really having long conversations with
our engineers, convincing them if they weren’t excited about this, that maybe
there are other things they could work on in our team and finding the team focused
on doing this.

It worked out great, but it was not trivial. We have a small team, I can only imagine when you see big companies today trying to pivot to Kubernetes, you’ve got years and years of customers install base, and how difficult that might be for them.

Pricing

Michael Schwartz: Great. It takes a lot of leadership. Most sizable organizations are using Containers today, so if you can sell to anyone, it becomes sort of challenging, so who do you sell to? I’m wondering, do you segment the market at all?

Shannon Williams: One of the nice things about open source is, it has allowed us to, give an idea most, I would say the 300 Enterprise customers, like every quarter now we’re closing about 50 new customers. Every quarter we are closing, we look at what the source of those are. I would say 30 of the 50 came from open-source Rancher users.

They started with open source, they used it at a
business-unit level, or line-of-business level, and it became important to them,
and they needed support. Those deals, they are not very competitive, they’ve
already kind of looked at Rancher, they have a relatively short sale cycle,
they’ve done the proof-of-concept – we don’t have to go in and prove that
Rancher is the right solution for them.

What we found is that we don’t really need to
segment that. The product pricing was probably the most important thing to
segment. We did find that with such a huge install base, one of the mistakes we
couldn’t do is, we couldn’t support everyone for free, for a small amount of
money. We needed to kind of keep a relatively medium-sized bar, to ensure that people
who needed support had to make an investment to get it.

For example, we could have gone with a lot of
SaaS models, $10 a month or something like that, but the reality is,
infrastructure and Containers, Kubernetes – these are all really complex. The
support is quite real. We provide a lot of advice, a lot of architectural help
with these organizations doing it. So, there was a real risk that we would
price the product so low, and that we would then be trying to do this for lots
of companies with very different levels of technical skills.

I’d say, the closest thing we came to segmenting
the market was providing a lot of free open-source support for people who are trying
to figure it out themselves, but then, charging a reasonably significant fee to
come in and get support. Our customers had to invest tens of thousands of
dollars on an annual basis to get support with us.

By doing that, it allowed us to work with companies
that really valued this. We’re investing their time and the money into making
it successful. That was really the best qualifier. It allowed us to focus on
teams that really could help us grow the business at the same time.

We’ve seen some industries become really big
with Rancher, but it’s more just a sign of who uses Containers. It’s companies,
and certainly the internet, and the technology industry, but there’s a lot of
financial services, companies, fintech companies, biotech companies, universities,
research organizations, we’re seeing adoption in government and military use
cases. It’s really broad now.

Retail, Edge’s driving, all sorts of interesting use cases, oil and gas, all sorts of interesting use cases in manufacturing, automotive – just lots of cool things that people start to imagine, a model where Kubernetes becomes this grand unifying theory for computer, where it runs everywhere. It runs in their single node, base station, it runs out in the windmill farms, it runs in Chick-fil-A shops, it runs in factories, it runs on cruise ships, it runs in data centers, it runs in the cloud. It’s a really exciting time to be working on tech, I would definitely say that.

Pricing To Value Ratio

Michael Schwartz: Normally, it’s really hard to get pricing right. Did you have to pivot your pricing model a couple of times? Or how was your experience like, figuring out what are the right price points?

Shannon Williams: Oh, man, that is a good one. We learned a lot from our last company. I made every mistake you can make last time. This time, we definitely had to pivot a little bit to be quite sure what the right element was to scale on with the number of clusters, or containers, or nodes, or CPUs, or things like that, but we decided pretty early on that the size of the implementation was probably a good way to judge how the cost should change from a small deployment to a large deployment, the number of hosts and servers, things like that.

Actually, I would say we learned a lot, we’re fortunate,
that were a lot of indicators from the market, as people talked to us I would
say. Your first 10 – 20 customers give you a lot of feedback on pricing, whether
you want it or not.

Usually, I think most people price to low, just
by nature. We all want to just make it both amazing and cheap prices. Like, who
wouldn’t love this thing? It’s the best and it’s the cheapest. But you have to
be realistic about what it takes to fund a business, what it’s going to take to
build a profit, and what you can do with those engineers you can hire, and then
you have to convince people of the value. It can be tough.

I remember I walked away from a lot of deals in
open source. I just said, “I’m sorry. I totally appreciate that you’re telling
me you could use the software for free, so you couldn’t possibly pay me more
than $10,000 or $20,000. But if I did that, I wouldn’t be able to build a
business, I wouldn’t be able to write open-source software, and I wouldn’t be
able to give you the level of support you demand from your other enterprise
software vendors. So, I’m sorry, we can’t do business with you.”

And sometimes they come back, sometimes they don’t, but being willing to walk away from deals – for our business model, it is absolutely critical to have to be able to do it. Otherwise, again, the car I’m selling you is available for free. You can take the same car with the exact same features, you’re not paying for a special version, it doesn’t have a better horn or better tires –it’s the exact same car. What I’m offering you is the confidence of working with me on it, and the world’s best support for that technology. If you don’t value those things, then, we can’t come to any business relationship between us.

Technology Partners

Michael Schwartz: Have you used partners to help you deliver to customers, especially globally? Or are there any other business partners that have been important for you to build a business?

Shannon Williams: Yes, yes, yes, yes. Over and over again – yes. The critical partners for us have been really two big buckets. We have found that the other companies who are building critical technology for teams adopting containers. It’s a company that’s called Portworx that builds a really nice storage, and a company Aqua that builds great security, Sysdig who creates monitoring, Gitlab who does really cool tools for CI and Git deployment – all really commonly chosen by our customers.

But partnering with those companies, companies
that fit into the same solution stack, we have been able to do two things:
we’ve been able to build a much more credible solution for our Enterprise customers.
And we’ve been able to align messaging and go-to-market together, and take maybe
a couple of other organizations who are our size, venture-funded startups, and
take our stories, and show them to larger organizations together.

And we would’ve done this through, we’d run online meetups, where our partners come and present to our users about their technology, and how they work with Rancher, and how they work with Kubernetes. That gives us a lot more credibility, and helps those company succeed, which helps the market grow because the market is vibrant. So, we invest a lot in partnering. We’ve also partnered really closely with the cloud providers.

We work really closely with Amazon, Google, and Microsoft in the U.S., and large providers around the world, to ensure that their implementation of Kubernetes works really well with Rancher. And that’s been fundamentally critical, especially because what we see is we see a market where, if you are in the cloud, you are probably going to use the cloud providers Kubernetes.

So, we want to make sure that we’re not trying to convince you to use Rancher’s Kubernetes on Google, take Google’s Kubernetes engine, which is great. Let us provide you with the common frameworks, whether using Google’s in Google, and Amazon’s in Amazon, on premise and Edge, or different types, everything is consistent, everything is managed the same way, everything is deployed, monitored, upgraded consistently. And you have a platform that really is this UberCloud we set out to build in the beginning anyways.

Integration
Partners

Michael Schwartz: If a customer says that services aren’t enough, they want on-site engineers, they want sort of higher-level design consulting – do you do that as expert services, or do you work with delivery partners to do that?

Shannon Williams: We tend to work with delivery partners. We work really closely with both big and small delivery partners who had built expertise. In Rancher, we have a platinum partner program, which is made up of some amazing companies that have implemented Rancher for others multiple times, and really have deeper understanding often not just of our ecosystem.

So, companies like RoundTower, CloudOps, Readapt,
Accenture. We work with quite a lot of the large multinational services
companies. We work with different regions around the world. These companies, BoxBoat
and other really good ones, these guys, they’re really staffed to provide
ongoing services for organizations in a way that we’re not.

Like, we are great at coming in and giving you a
ton of information about Rancher and helping your architect your Rancher
deployment, but a lot of times, technology is only a chunk of the solution. The
solution needs to include some transformation of how you do things, how you do
DevOps, how to train all your developers around microservices, how they start
thinking of some of these new service matches, and how they might get into
solving business problems for your company.

We can point you in the right direction and help
you with those things, but we’re very laser-focused on the Kubernetes platform.
And these companies are much better than we are at providing the transformational
experience around there. So, yeah, we very much partner, especially in those longer-term
things.

What we have found as really critical is the
actual investment of our own on customer success. I would say, one of the
things that’s got a lot better as we’ve grown is, we’ve invested more and more
in — I think it was like the first 90 days when an organization becomes a
Rancher customer.

I think this is really important for open-source
companies because if you are a SaaS provider and somebody’s using your product,
you have a pretty good idea what they’re doing with it. But as an open-source
software companies, especially ones that support that open-source software,
organizations can have very different processes, they may have more or less
mature implementations, they may or may not have built-in an HA deployment. And
they’re coming to you to provide support. You really need to make sure they
understand best practices, that you reviewed their deployments, you helped them
understand how we recommend doing things.

We invest a lot more now in customer success than we did in the early days. When a customer comes on board, we really spend a lot of time going through their architecture, helping them make improvements that they will achieve their goals, whether it’s stability, multi-cloud implementations, or they might try to do something, there’s a lot of scale. And then, there might be something we’ve learned already that can help them. I would say customer success has been a big learning for us.

Net Retention

Michael Schwartz: Has that investment in customer success also translated into increased revenues per customer year-over-year, so they’re buying more, or other products, or other divisions?

Shannon Williams: Well, it’s still new enough that I wouldn’t say if I know how correlated those two things are, but we certainly believe they are. We are investing in it because our bet is helping a customer be successful, with even a departmental implementation or a single app deployment is going to pay dividends for both retention of that customer and that workload.

So, a year later, when they decide they want to renew that support they bought last year, they have a really good feeling that, “Yeah, that was a great investment. Partnering with these guys has been useful.”

But certainly that also works internally. As
they use it, they seem to spread the word. I mean, we have seen over and over
and over again the power of the success of a Rancher deployment spreading
within a company.

Users love Rancher. It’s a user-oriented
product. What’s so cool about a product that has 30,000 open-source users is,
it says something about how usable it is. It’s like terraform, you use it, it’s
pretty straightforward, you like it and you go, “Cool. This is easy. I can get
this.” You tell your friend, “You should use terraform. It would help you do
something.” It’s kind of same with Rancher.

If all those users are using it, they are clearly
getting some value from it. When somebody in your company says, “Hey, use this.”,
and you’ll probably benefit from it. And there’s no barrier. I don’t have to
start by going and getting a license to try it. I can just use it. It tends to
spread the same way. It’s just the word of mouth and the power of it kind of
spreads.

So, we found that making them successful and making sure those early champions are well-armed to explain why they chose Rancher, and they got a really good implementation, they don’t get bitten by a bad config, or maybe not knowing the best practices, it helps us in the long run for sure.

Cloud Strip-Mining

Michael Schwartz: I’m sure you’ve been hearing about open-source strip-mining from large cloud vendors, but what I’m wondering is, do you think it would be good or bad if some mega cloud company offered a Rancher-based service?

Shannon Williams: I think it would be great personally. From our perspective, the value of these mega cloud providers is always tied into a big ecosystem that they’re trying to build around. What we find is that organizations want to live in those ecosystems, and leverage those ecosystems, but they know they’re not going to live in just one of them. So, they want lots of them. And the more that those ecosystems interact or work together, or do things that help them work together, the better off they are.

In so many ways, I think the strip-mining
analogy is that it’s a rough analogy because, well, it’s true that some of
these providers don’t put a lot back, and there’s definitely been some ugly
competition between open source and commercial. For the most part, I think their
relationship has actually been pretty beneficial, mutually beneficial between
the cloud providers and the open-source software developers.

It’s often where it’s really struggling, where
you‘ve seen it’s struggling is when organizations haven’t had a great business
plan our route to market, or they haven’t been able to commercialize their own
products. And then, all of a sudden, it gets embedded into something larger. And
then, the only monetization of it happens in the cloud.

I think that’s where we see most of the
problems. I think that’s going to continue. I think that that was happening
before as well. You know, ideas are developed, but are never really taken to
market fully or are not pushed into the market aggressively. Organizations build
upon those something new, or something tangential, or something that accelerates
them. And that is what ends up being the big success.

To me, that’s business. That’s something that’s
going to happen in any space, whether it is open source or not. And, yes, in
our world, people can take and build on it very easily, but that’s what you
know you’re getting into when you’re starting an open-source software business.
And if you don’t, you really should research a little bit more.

This is a knife that cuts in many ways, from a
business perspective. And I certainly would look at the world, and I certainly
wouldn’t call foul if that happened to an open-source project. I’ll give you a
feel, in China, Rancher is incredibly popular.

From early days, my co-founder Chan grew up in
China, and so, you have someone who can speak Chinese and talks about it in
China – Rancher became really famous. We’ve had multiple times where startups have
kind of emerged competing with us in the market, selling Rancher and providing
support around it.

Our experience has been that that, as long as we
continue to push forward the innovation and organizations really value what we
do, they’re going to want to work with us. They are going to benefit from
working with us.

As long as we keep pushing it forward and building the product better, that will continue to be the case. But you have to know what you’re getting into. I don’t feel like there should be a huge shock if you build an open-source product, and someone forks it, and does something cool with it, that’s kind of the idea.

When To Use Open Source

Michael Schwartz: Moving to slightly higher level, do you have any thoughts about when entrepreneurs should use the open-source development methodology to develop a commercial product?

Shannon Williams: For me, I think it’s about the product you’re trying to build, and what you think your route to market needs to be. If you’re entering a market that you think is pretty competitive, and has a lot of different products, and you know you’re going up against much more well-funded organizations than you, then, I think open source is a really, really important one to consider and to look at. Because it allows you to get adoption in what would otherwise be a really hard market.

If your only feedback is going to come from a
handful of companies you can convince to POC you or pay for it early on, you
are going to have a hard time building momentum. And you’re going to have a
hard time having good conversations with users who either like or don’t like
what you’re building.

To me, I don’t know, I’ve been building nothing
but open source for 11 years, so it kind of feels to me like everyone should
just build open source. I don’t find that it’s ever slowed down our
monetization. It’s always been a benefit. But I certainly would say that if you’re
building something that you think is transformational, that actually has a broad
audience that will adopt it, open source should very much be what you’re
considering.

If you’re building something that’s probably a service,
and it’s going to be hosted, I think open source can be enabling capability,
but I wouldn’t worry too much about the open-source side, I would just focus on
building the SaaS platform product tool that you are building a cloud service.

Because I think in those cases, open source is less
important than it is an on-premise software or fundamental software. You’ve
seen with Docker, open-sourcing, and having an open source success is not by
any means enough to guarantee a commercial business success, but it puts you in
a position where you have a great chance to engage with users, listen to what
they think is necessary. Next steps, what they’re excited about your platform
for, your product for, and what they’re willing to pay for, and build on that.

Advice For Entrepreneurs

Michael Schwartz: Last question, any advice for new entrepreneurs starting a business around an open-source platform?

Shannon Williams: Of the four of us who started Rancher and started Cloud.com and everything, I’m the non-engineer. My role in the early time of building a company, I was considering my role then to be how to connect with users, like how to connect to people even before you have a product.

When we were in our first 6 months, our first
year, I spent all day, every day, thinking about who are potential users could
be, based on the direction we think we were heading, and reaching out to people,
introducing myself and introducing the idea we’re building, and getting
feedback.

You always have to be thinking about the next milestone
of users, “My gosh, how do we possibly get to 10 companies using our product?”

And the only way I can ever found that works to get to 10 is to find them by hand. To think, “You know, I think this makes sense for somebody in that space.” I really believe that if you as a founder can’t explain your value proposition enough to get someone to sit down on the phone and talk to you about it, and maybe watch a demo.

Especially when you can tell them, “Hi, I’m Shannon. I’m one of the founders of this new startup called Rancher. We’re trying to solve this problem, and I thought it might apply to you guys. I really love your feedback. We are not trying to sell you anything, we just want your feedback on what we’re doing.”

If someone doesn’t want to talk to you with that pitch, you might be barking up the wrong tree with your idea. That initial response, if you can’t just explain what you’re trying to build to someone right away, and if you can’t get a meeting, it’s probably worth reflecting on what you’re doing, and maybe tweaking, and then trying some different approaches, trying some different messages.

Because if you can’t get a meeting, it’s going to be really hard to get a sell. It’s going to be really hard to get a user, it’s going to be really hard to convert them into a paying customer.

But if you explain to someone, most people love
to talk to entrepreneurs starting companies, especially if they can really
clearly communicate what it is they’re trying to solve. And that validation
early on goes enormously towards then calling that person back in three months,
and saying, “Hey, we got a first beta ready, would you like to take a look at
it?” And getting those first 10 is hand-to-hand combat.

Really the first hundred is hand-to-hand connecting to people, showing them the product, showing them the value, and getting to use it. Every once in a while, you have these runaway crazy successes, where everyone’s like, “Oh, my gosh, I can’t believe – how did we live before this existed?” But most of the time, it doesn’t work like that. Most of the time, you have to connect, talk, demo, listen to the feedback, and go back and consider how far on or off your strategy you are.

Closing

Michael Schwartz: I said it was my last question, but now you just raised another question, and I can’t resist. Previously you mentioned that a lot of the leads for customers were from inbound, from customers who use the software, liked it, and then called you to purchase a support subscription. But 50 deals a quarter – that’s a lot of business. That’s really pretty stellar. And I’m wondering, what’s the right mix of inbound and outbound marketing sales to push for, or how do you balance that?

Shannon Williams: First step for all of this is find a real market. When you find a real market, things get a lot easier. Because you have to have something going on that’s causing people to look for a solution, they have to have a problem.

So, to your question, if I had my druthers, I’d have a 100% coming inbound, so everything coming inbound means that the market is actively looking for solutions. My brand is well enough known, we are the company they should at least talk to about this to get a demo. Ideally, it’s open-source, just download it, and install it, and try it, and see what you think.

I, from day one, believed in inbound as our goal. So, that meant, instead of spending a lot of our early dollars on advertising, for example, I spent almost everything we did, online communication to users. And that meant, oh, my goodness, we wrote dozens and dozens of pieces of content explaining how to use Containers, and Kubernetes, and Docker, to help people find us.

They may not be looking for Rancher, but they were looking to solve a problem. And so, we really tried to build a list of the lots of the problems they were trying to solve.

We hosted an online meet-up every month that grew to have thousands and thousands of people register every month. It was crazy. We just run them today – I just did one last week.

And what we said was, “Hey, come, it’ll be our smartest technical people. We will stay as long as you need. We’ll demo whatever it is we say we’re going to do. I won’t just show you a bunch of slides, we’re actually getting this code, we will teach you how to do it. And we will stay until every Kubernetes questions are answered.”

So, these things would run two hours, three
hours, but they allowed people to cross hurdles, to learn how to build the CI/CD
Stack on Kubernetes, or how to do monitoring on it, or how to deal with logging,
or how to use containers and the cloud – whatever it was we were trying to
solve that month, we really focused on it. It was really that. It was education,
community, content that, coupled with early references that we built by hand,
in that hand-to-hand phase, got the word out.

By continuing to invest in that, we were able to kind of sow so many seeds of open-source users that as they matured, and liked what they usd, they contacted us. The right mix for me is a 100% inbound from the open-source community. But what we did find was, as we grew, we started to run into bigger organizations. They have entrenched vendors.

All of a sudden, we might have won a line of business users, and then they just said, “Hey, we love this Rancher. We are going to use it for application A, B, and C.” But 80% of the company was using something else that they’ve maybe built themselves, or maybe they bought something, some other product a couple years ago to do PaaS, or something.

And so, because those organizations started to
look and say, “Why aren’t you using this? Why are you using Rancher?”, we had
to support them and show other people in the organization, “Well, actually,
this isn’t the same. It’s different, and here’s why it’s different.” What we
did find was there was longer Enterprise sales cycles, so we needed good
high-quality sales people to work with bigger companies.

But the positive was, we found that those
companies actually really appreciated that it was open source. And the fact
that you already had one over, a group of people who really loved it internally,
meant that you kind of solved, in a lot of cases, the biggest problems these IT
teams were facing, which was, they were building stuff and no one was using it
anyway because they were just going to the cloud, they were building something
themselves.

So, when we could tie together, the IT
organization, which is like doing everything they can to support
forward-looking development while still being secure and still being
cost-conscious. And teams that have usage and feel like they’ve got found
something cool, it was just like made it for a much easier sales motion than
your traditional either selling top-down or kind of getting some executive
buy-in, and then hoping people use your product once it was brought in.

I don’t know, does that answer to your question, Mike? I kind of feel like I ramp up there.

Michael Schwartz: Yeah, that’s lots of great info. Shannon, thank you so much for joining us today, and being so honest with your answers.

Shannon Williams: Mike, it was my pleasure. Thanks for doing this. I love your idea of open source entrepreneurs just sharing and talking about what we do. I think it’s a phenomenal business model. It is a real transformation of the relationship between the developer of a really powerful software and the consumer of that software. So, it’s something I have enormous passion for. Michael Schwartz: Best of luck with Rancher, and congratulations on all the success.

Shannon Williams: Thank you so much, Mike. You too. Have a great one.

Michael Schwartz: Thanks to the Rancher team for making this happen. Transcription and episode audio can be found on opensourceunderdogs.com. Music from Broke For Free and Chris Zabriskie. Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.

The Twitter handle is @fosspodcast. Rate us on iTunes if you like this episode.

Next week, we have James Waters, SVP of Product at Pivotal. Until then, thanks for listening.

Isaac Schlueter emerged as one of the most important leaders from the Javascript community. As Chief Open Technology Officer of npm Inc, the company behind the essential software registry, he has a bird’s eye view of what makes Javascript such a unique ecosystem. And his mission was also unique: to transform a free public utility into a viable enterprise software business. This episode was recorded in person at the Open Core Summit.

Transcript

Intro

Michael Schwartz: Welcome back to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 38, the last in-person interview recorded at the Open Core Summit. Our guest is Isaac Schlueter, CEO of npm Inc.

Many programming
languages have a central software registry, but the JavaScript npm Registry is
unique. It’s the biggest and the busiest by far. For example, it has around
four times the number of modules as a number
two registry, which is Maven for Java.

If you want to learn
more about npm, Isaac was a guest on Founders Talk Episode 61. And for an interesting perspective on the npm ecosystem, you might want to listen to Changelog Episode 355 – it’s an interview with C.J. Silverio, as a former CTO of npm Inc. She provides an
interesting perspective on the economics and the technical challenges of
running the world’s largest package registry.

I hope you enjoy this
episode. And if you like it or you’d like to start a discussion, tweet at us. Our
Twitter handle is @fosspodcast.

So, without further
delay, onward with the interview. Isaac, thank you so much for joining us today.

Isaac Schlueter: Hey, happy to be here.

What Is Npm?

Michael Schwartz: Some business people listening to this podcast might not know what npm is or what it does – can you give a really quick explanation?

Isaac Schlueter: Sure, this is my very fast 50-cent tour. Basically, npm is a way for JavaScript developers to share modules of JavaScript code. So, if you have some reusable function, something that you’re using in a bunch of different places, they can publish that up to the npm Registry. Other developers in other projects can use npm to install that dependency and also keep up-to-date when there are updates to it.

If you’re depending on a platform, or a module, or a library, or something, you can automatically pull in all of those updates and keep your app up-to-date.

Why Inc. Not Foundation?

Michael Schwartz: Most other package ecosystems are supported by a foundation, for example Ruby, or maybe Python – why didn’t that work for JavaScript and npm?

Isaac Schlueter: There is a couple of reasons for this. The first one is, if we go back to the kind of the history of npm, when I decided to start a company around it, it was my side project for about four years.

And it grew in popularity. It was running on donated
infrastructure from this company, Iris Couch. We just grew to a point where the
scale was too massive for them to be able to afford to keep doing that.

I looked at my options, and starting the foundation was definitely on the list of things that I could do. Another option was, find a home for it in some big company, try to get hired by Google or Microsoft, or somebody.

The reason why I decided to start an independent company was
simply owing to the scale and the rate of growth that we were seeing. So, the
typical way that a foundation operates, you raise a bunch of money from a bunch
of companies who have some vested interest in whatever the thing is, whether
that’s an open-source project or some other thing. And then, you spend that
money on keeping the thing going, so that might be, having developers work on
the project, your managing governance, or marketing, whatever.

Within npm, we had this exponential growth curve that we are still
at the very beginning of, in terms of the number of users on the npm platform.
We’d grown to about a million users. Our rate of downloads and package growth
was just astronomical.

The JavaScript language is used in pretty much every application
out there. There are Ruby developers, there are .Net developers, there are Python
developers, but the front-ends are all running in JavaScript, and everybody was
increasingly putting more and more stuff into npm and using it very widely.

So, we kind of did some back-of-the-envelope math and realized
like, “Okay, well, we could go, raise a couple million bucks to start a
foundation and be able to put some resources behind this thing. But what are we
going to do next year? We’re going to need 10X as much. And then, the year
after that, and the year after that.

The task of just kind of continually being in fundraising mode was
pretty daunting. Especially because it’d be hard to justify that the benefits
to each of those member companies would also keep increasing enough to justify
them, increasing their investment.

On the other hand, if you have an exponential growth curve of
almost anything, even rising costs, you can take that to an investor and say,
“Here’s the thing: it’s a thing that’s growing, it is a thing that’s exciting.”
You can tell a story about how you’re going to go about monetizing that in the
future, and that’s something that is sort of a good fit for a venture-back
startup.

Npm Products

Michael Schwartz: Most people use npm for free – what do you actually sell?

Isaac Schlueter: We sell two main things right now. The first is npm Orgs product, which is a multi-tenant SaaS thing that you can use to store your private code within your organization. That’s used primarily by smaller companies or front-end development teams within larger companies.

The price point there is $7 per user per month. It grows depending
on the size of the Org, you can have multiple packages all underneath that same
Org.

The other thing that we sell is our product called npm Enterprise, which is a single-tenant instance of the npm Registry and website. It has some additional features, like single sign-on, or security policy enforcement, that kind of thing, which is more of a need at bigger companies.

Market Segments

Michael Schwartz: What kinds of companies use the Enterprise products – do you segment the market at all?

Isaac Schlueter: The sweet spot for us is about development team of 50 or more. We do some market segmentation to go after different sectors. There are some sectors that we focus on, but obviously, we will sell it to anybody who wants it. There’s a fair amount of inbound that comes in as well.

We’re seeing the most traction in sectors that have really high
compliance, policy and security compliance needs, so financial industry is a
really big one. And there’s also a ton of customers with money to spend on
their development practices, and they get a lot of benefits by having their
developers able to build things in a more frictionless way.

The other sort of category of markets that we go after, where we’ve
seen some good results, are companies where there is sort of an internal agency
model, where you have a web development team that has multiple different
website properties.

There might be hopping between different websites that are all
kind of under one big corporate brand. And in that case, there’s a lot of
benefits to being able to reuse those modules.

Also, frequently, in both types of companies, once a company gets to a certain size, there’s often like a tools team or kind of a platform team that’s in charge of all of the reusable JavaScript code that’s used across all of the different properties. And in those cases, they also benefit a lot by having something like npm in-house.

Marketing / Sales

Michael Schwartz: In terms of marketing, you were sort of starting from a nice position because everyone knows npm – how do you organize sort of the marketing effort so that people know what the commercial offering is? And how do you organize the sales – do you just wait for inbound or you do any outbound marketing?

Isaac Schlueter: We do a fair bit of outbound marketing, and it’s a little bit of a double-edged sword. Everybody knows npm, but not everybody knows npm Inc. or npm Enterprise.

One of the challenges that we ran into, which I think is common
among a lot of companies that are operating in open-source communities, is that
people have heard of the thing but they haven’t really heard of the product.

One of the things we heard is, “Oh, npm? That’s a company??” I
just thought packages came out of the ether.
I didn’t realize it was downloading from somewhere.”

So, when it comes to our marketing efforts, a fair amount of the
work there is in continually beating the drum of like, “Yeah, we have things for
you.” “If you need policy compliance, if you need security, if you need
proprietary code, and you want to manage it, using the things that your
developers already know and love, then we have a solution for you.”

When we go through the sales process, typically we have an
internal champion, which is usually engineering architect, or engineering manager,
or something like that, who sort of intuitively understands the benefits of
npm.

Then, the sale process tends to be one of making the case to folks
who are not already deep in this ecosystem. That tends to be people in kind of like
internal development tools, purchasing team, the CIO’s office – it can take a
couple of different shapes, but, you know, the folks within a large Enterprise
who managed to spend on development tooling.

Free V. Commercial

Michael Schwartz: Diverting a little bit from marketing, one of my guests said to me that it’s almost better to start a company around a product that you don’t write, an open-source product that you don’t write, because all those engineers who are working on the open-source thing, they’re not billable, or they’re not contributing to their commercial product – do you feel that friction at all, where maybe part of the team is really committed to the community mission but maybe other parts of the organization are more interested in the product than actually generate revenue? How do you reconcile that?

Isaac Schlueter: It can be a tough needle to thread. I mean, not to dispute the past guest who said that, there’s some sense in what they’re saying, but obviously, I do disagree because of what I’ve done.

I think that the challenge, or at least the puzzle, is to figure out how do we continue to make good on our community mission in such a way that it serves our product interest, and how do we design our product interest in such a way that they’re served by the success of the open-source community.

We have certainly made some missteps in the past. One of the biggest things that makes good intuitive sense. You have an engineering team, you have a web team, you have a backing team. Of course, you’re going to have an open- source team, but the minute that you start doing that, you create this unhealthy dichotomy.

Even if it’s just in your own thinking as a founder, and as a manager,
as an entrepreneur, where it can be very easy to get into these dysfunctional
patterns of being resentful about, “Well, these five engineers are spending all
their time on the open-source stuff, and we’re just giving that away, and how
is that helping the company?” “And here I am, busting my hump every day, trying
to make our website better, and trying to sell products and trying to get new
log-ins and new sign-ups.”

And every time you want to build some new thing, it’s like, when
we run into this case of like, “Should we give this thing away or should we charge
for it?” And the thing that I’ve come to after five and a half years of doing
this is – if I was smarter, maybe I would have come to it sooner –
is just that that’s the wrong question.

The minute you find yourself asking, “Should this be free or should
it be paid?”, you’ve already kind of committed the fundamental thinking error
of putting those two things at odds.

The better way to think about it is, “What is the free thing that
will get someone to pay for this?”

So, what can we give away in such a way that it will open the door
for an upgrade path, and that will open the door for a paid product that is a very
clear enhancement to the thing that they’re getting for free.

Some of the best companies in the space that I’ve seen tend to
have an approach of, like, their explicit goal is that individual developer
should never have to pay for our product. But, a company should almost always
have to pay for it.

And that really clarifies the thinking, and it clarifies a puzzle
in a really interesting way. Because anything that involves a team of ten
people, writing a proprietary application, like, they got to pay for that. That’s
a company, that’s a for-profit company.

Now, okay, it could also be like a school or it could be a
nonprofit org – you can always give those folks a coupon, that’s not actually a
problem. But with our Enterprise product and with our Orgs product, I think we’ve
done okay. Orgs are free if they’re open source.

If you have five people collaborating on an open-source project, and
they want to keep a bunch of modules under a namespace, they don’t have to pay
for that if it’s all open source. And we really see that as part of the nice,
easy transition from like an individual working on open-source, a group working
on it, and then up to a group working on some kind of paid product.

One of the things that we did not anticipate when we made Orgs
free was actually it increased our paid Orgs signups.

We’d always intended to do some kind of, like, first month free, type
of trial type of thing, and just kind of didn’t get to it because it takes time
and attention, and there’s only so many people and only so much code you can
write in a day.

And we decided that we want to make Orgs free for open-source
projects. Because there was a handful of different open-source projects, and we
gave them an Orgs, one of our database markets just went free. And we were kind of like, “We should just make this a thing.”

When we did that, what was surprising was, people at companies
would sign up for a free Org, add their whole team, try it out for like an
hour, go, “Okay, this is going to work, and then, they’d flip the switch to be a
paid org.

That’s for me when kind of the light bulb went off. Like, “We should not be thinking about what is paid and what is free, we should be thinking about what is free, so that it makes it easier to buy the paid thing, if you need it.

Pricing

Michael Schwartz: So, it was all on the honor system? You could sign up as an Org?

Isaac Schlueter: You couldn’t publish anything private. You couldn’t have a package in your organization that had access control attached to it. Anything you published in a free Org would be open to the entire world.

Michael Schwartz: You really almost had to invent a business around this because I can’t say there was like any direct model you could choose. And one of the hardest parts of that is figuring out what to charge for that, especially because you didn’t have a lot of data. I’m wondering since you started the last five years, have you had to pivot on the pricing model a couple of times? Or has it been relatively stable, and did you get it right?

Isaac Schlueter: Yeah, we just stuck the landing – it’s been perfect. No problems at all. I wouldn’t say that we’ve pivoted on the pricing model. We have made some changes that I think are somewhat subtle. And most of those I’ve been owing to user experience.

Around in 2016, or beginning 2017 I think – I forget the exact
dates now, it’s all lost in the mists of time – when we originally released our
Orgs product, our paid Orgs product, basically an organization, again, you
build things in the simplest way possible with the stuff you have because you’ve
got to ship something, and if at one point it was perfect,
you waited too long. And just the easiest way to do
it was to say, “An organization is a subscription that belongs to a particular
npm user.”

That gets us into some real interesting subtlety I think that not
a lot of Org users, then or now, really fully appreciate it. But the idea was,
your Org would have an owner – that was an npm account.

The real big problem that came up, and it came up fast, was, well,
what happens when that user goes away, what happens if they leave the company
and now what. It’s still billing to their account and their account has this
credit card attached, it is a corporate credit card, and like, the only way to
resolve it was actually to go through our support team, which, I love our
support team, I think that they’re great, they do great work, and I’m really
happy that they’re there, and supporting our community, and our customers, but
every time somebody has to contact support – that’s a mistake we made, that’s
something that we needed to fix.

So, we kind of went back to the drawing board and said, “How do
people think this works? How do users think this Orgs thing works?” They think
that they create an Org, and they think that they just pay for the Org, and the
Org has some user who is administering it, but they can change that user.

So, what that said to me and what we kind of landed on was, the
organization itself should be the primary first-class kind of billing entity. And
then, the user account of the subscription, and everything else, is attached to
that organization, not to some individual user.

Then, that shift, due to some other sort of subtleties, and how it
was implemented, we realized that if we made this transition, a bunch of Orgs,
who are currently not paying for users who have access to their packages, would
suddenly have to start paying for those user accounts.

And the way that we addressed it was, we just collected all of
those cases where that would happen, and we applied a coupon to all of those
accounts to give them a discount and said, “All right. Like, your bill isn’t going
to go up.”

Yeah, we probably could have just said, “Well, bad news. I know
you’re paying $7 a month now, but it’s now going to be 21 because you got these
other two users that technically are part of this other Org, even though
they’re in your Org also.” And it got really hairy, but we figured that the
user experience hit just wasn’t worth it like, “Thank you for being an early
subscriber, an early adopter.”, but moving forward, it really vastly simplified
it.”

The organization is a top-level thing, it’s like a first-class entity
in our system. Every user account costs 7 bucks a month – that’s it. There’s no
like discounts if you’re in multiple Orgs or anything like that.

Nobody complained, some folks got an email that said, “Hey, you
know, we’re changing our pricing model. This would make your bill go up, but
here’s a discount, so it won’t.” There was basically no reaction, which is what
we’re hoping for.

Now, our Enterprise product, regarding pricing, yeah, we’ve been
all over the map there. You talked about there not being data, well, with a
self-serve product, you have quite a bit of data. It’s really easy to just
throw a survey out there, and like, yeah, it’s going to be noisy, and you’re
going to get a dozen people were like, “Oh, I wouldn’t pay more than a penny.” But
you can wipe out the outliers, and get some kind of at least directional data.

One of the things we found was, there’s already some services out
there, like GitHub costed 7 bucks a month for Orgs at that time. I think
they’ve since changed their pricing model for their Orgs products, so it’s like
$25 for the first 5 users and then $9 after. We thought about doing something
like that in our sales, mainly in the future. Just to kind of help people get
over that initial hump.

But once you had your first 5 users, it’s very, very sticky. The
easier we can make that seem, it’s like 25 bucks and you get 5 users – that
seems cheap. But if it’s $7 a user, and you only had two users, there’s a
pretty good chance you might not like stick with the product. If you get those
5 users in, now you’ve got five people all collaborating on code, and they’re
not going to abandon that for anything because now it’s kind of in their
process.

So, with the Enterprise product on the other hand, there really is
almost no data, and it’s very difficult to get that data. A lot of Enterprise
products, even if you go to like companies, providers, websites, and you look
at their Enterprise products, it says, “Call us.” You are kind of in this like
arm wrestling match with the procurement department, where your price is, like,
you give us ‘whatever we can get out of you’ basically is the price.

I think with our Enterprise product now we start at $50 a seat, and
the product has quite a bit more features in it than our previous generation of
our Enterprise product which was quite a bit cheaper. And we also have a
minimum number of seats in order to qualify for an Enterprise product. We don’t
offer it for less than 20 seats.

The nice thing about that is that it immediately selects out
everybody who’s not actually going to need the benefits of this product, who is
not going to need the policy enforcement and security features of it.

They are not going to be as well served by that product like they
should really be buying Orgs. So, it’s tempting to look at pricing as like the
way that you make money, but really, another way to think of it is like, how
does a pricing act as a filter for who should be using this thing, and how does
it work as a signal.

If you have a product, and you have your product break down your
pricing page, or whatever, there are companies that are going to just look, and
they’re going to say, “I don’t want the cheapest one, I don’t want the most
expensive one – give me the one in the middle. I don’t want to look at all
these words.” And they’re just going to buy it.

You need to think of, like, who is that user, who’s that persona
and kind of focus your research there, and then, work backwards, like, “What is
their budget? What can they pay?” And then from there, you’ve got pretty good
answer about your price.

Every Enterprise is going to try and make some argument for why they should be paying less. So, start high and let them push you down. And also, like, if you don’t start high enough, then they’re not going to think that it’s legit.

More On Pricing

Michael Schwartz: Was that one of the hardest parts of migrating from I guess open-source repository or open repository to business? Just getting that right?

Isaac Schlueter: On the list of hard things, that doesn’t even make it top 10, there is quite a bit that’s much more challenging. I mean, the other thing about product is, I think it’s really much more art than science, and certainly, there’s product managers out there who are like pounding the table as they listen to this, and sure that I’m super, super wrong about it.

But, so much of it is, you need to figure out a price that you
won’t go bankrupt. And then, you need to figure out how to sell that at that
price. And the specific number, is it 8, or is it 9, or is it 20, or is it 25.

I think at the end of the day, that probably matters a lot less
than have you built a product that people want to use, and have you priced it
in such a way that it sends a signal that those people actually are the ones
who should be using it.

If
you look at the pricing of wine, great example of
this — I don’t know, I’m going to offend some wine snobs in your audience, I
apologize – a lot of the pricing of wine is like completely arbitrary.

It’s like, are you somebody who likes the expensive wine or who
doesn’t care, or you’re like somebody who kind of wants, “I want it to be good,
but like I don’t want to spend a lot.” I mean, all wine, it’s all fermented
grape juice. It’s not that different, it’s essentially just overstock of wine,
that’s why they’re able to sell it so cheap.

But that price signals a particular kind of buyer who is likely to
benefit from that product. And on the other end of the spectrum, it’s the same
kind of thing. You’re buying this $500 bottle of wine because you want to show
off how rich you are, and in order to show off how rich you are, it has to cost
$500. And so, that’s why people buy that.

In the world of software product management, we like to pretend that we’re a little bit more rational because we’re all like tech people and we are very cerebral and logical. We do math, and it still largely just kind of comes down to like, what are the products that your product is like, how much do they cost. If you just copy them, it’s probably you could do a lot worse.

Lessons Learned

Michael Schwartz: So, now I have to ask a question – what were some of the hardest challenges? Please, take top, one or two.

Isaac Schlueter: I set myself up to that one, didn’t I? I mentioned a kind of the split brain that can happen within an organization when you separate out your free, or open-source, or community offerings from your paid offerings, and think of them as different things. That’s a very, very easy error to make, but it’s a very pernicious one that really gets in everywhere.

And I think it, in order to avoid that error, you have to think
about that design, not just in your product design but actually in your
organization design, in your strategy, in your go-to-market, in where you get
your investment from, and who you have on your board. Like it has to really,
really inform everything about your company in order to steer yourself away
from that kind of problem.

Another big and easy mistake to make is having an on-prem and a
SaaS product at the same time early in companies like them. Eventually, you’re
going to need to have an on-prem product. And if you’re positioned well to do a
bottoms-up sale, that has to be a SaaS.

Because no development team — if it’s five people on a Dev team
and you’re trying to convince them to use this tool, they’re not going to spin
up a server and install it and operate it themselves – they’re just not set up
for that. If there’s a SaaS offering, they’re going to take that one.

And as an early stage company, when you’re talking about like 10,
20 people, if you are building products, like you’re going to take every single
shortcut you possibly can. And the biggest shortcut you can take, if you have an
on-prem product and a SaaS product, is to start putting big ‘if blocks’ in your
code base. And you can tell yourself like, “Oh, they’re the same code base, were
totally keeping them in sync.” It’s all one big Dev team.

What’s going to happen is, even the same developer working on both
things is just going to put a big ‘If Block’ and say, if
process dot, end of dot enterprise equals true, and
then basically fork in place, which is even worse than actually forking two
code bases. Because now you have this kind of like convoluted ball of mud.

We originally did have an on-prem Enterprise product, we still
have some customers who are using it, even though we’re still trying to kind of
like nudge them to our Enterprise SaaS product. We reached a point as a company,
where we sort of realized we can’t keep running this Enterprise product, we’re actually
losing money on every sale, because the cost to support and operate and get a
customer up and running is just too high.

So, we pivoted somewhat, we kind of instead said, “How do we take
what we do with the registry and with the website, with the Orgs and everything
else?” “How do we make a SaaS offering there?” And what do the Enterprise
customers actually need for that?”

We’re still figuring out kind of how to play in that space, and how
to best have that integrated and connected with our self-serve products, but
it’s still a huge step in the right direction. I think hindsight being 20-20, going
out the door really in our first year with an on-prem Enterprise product and a
SaaS team’s product at the same time, seemed fine. It seemed like a good idea
at the time.

A bunch of people told me, “Well, you need to really make sure
that the code bases don’t diverge if you do that.” I heard that from a bunch of
folks at GitHub, who made the same kind of error, and I was like, “Okay, noted.
Don’t let the code bases diverge.”
Got it. What they didn’t tell me was, “You’re going to let the code bases
diverge. That is absolutely going to happen – it’s inescapable.” You can either
be a SaaS company or an on-prem product company, and those two companies are
very different shapes.

If you’re going to be an on-prem product company, that means
there’s a lot more of a top-down sale most likely. Or it just has to be so easy
to install and start running like on a laptop. It’s almost certain that you’re
going to need some really good professional services skills within your company,
because making a customer successful with that product is going to require that
you have somebody who knows how to stand it up, and how to operate, and kind of
which buttons to push, and which knobs not to push, how to tell if there’s a
problem – all of that stuff.

That means training, that means customer success, that means like
really building in good metrics into the product itself, but in such a way that
they’re not going to offend people who don’t necessarily want data collected
about them, or if it’s behind the firewall, like, how that all works.

On the other hand, the way that you go to market with a SaaS
product is completely different. It’s more about adding hooks and adding limits
and adding these pay walls within your free product. So, when you go to your settings
page, or you go to like view some metadata, or you go to view a report, or you
go to add a new package, they can say, “Hey, you need to pay to use this
feature. And those are two completely different mindsets.

At a certain point of maturity, you could reach a point where you
have enough, maybe you fall of the bottoms up path, the bottom up path
eventually gets to the top, and the top down path eventually gets to the
bottom. But if you try to approach it from both sides at the same time, I just
feel like that almost never can work out well. Now, there are companies that
end up doing both, but if you really look carefully at the companies that are
successful doing both, most of them started on one end, and then made it to the
other.

Either they started as a top-down company, and they did well
enough with like evangelizing, and marketing, and getting adoption, and gaining
traction within these large companies that it became sort of a de facto
standard. And then open-source parts started to kind of become the way that developers
expected to do things.

Or they started as a bottoms up strategy, where every developer
just eventually started to expect that this is how things work. And when they
came to a big company they said like, “We need to sign up for these.” And then,
eventually, they built out features that built up to that enterprise-level. And
obviously npm loses position to do the bottoms up thing, and so, approaching
both the same time was — I would not do that again.

Team

Michael Schwartz: What’s your approach to building the team?

Isaac Schlueter: Before there was a company, there was me and there was one guy who was in Thailand. Another couple of folks, one was in Eastern Europe – again, this was a whole donated infrastructure stuff, so whatever that other company was doing. I didn’t really recruit them, it was kind of just like who I ended up with. And luckily, some of them were really good. A lot of npm’s success really owes to that.

When we founded the
company, you know, it’s easy to forget now, because it doesn’t feel like it was
that long ago, but video conferencing was not as good as it is now. Chat apps were
not as good as they are now. Slack didn’t exist, Zoom didn’t exist. I think
Zoom might have existed, but it wasn’t what it is now. It wasn’t back then
easy-to-use.

So, initially, we would focus our hiring on the Bay area, which seemed reasonable. It’s what you do, it was a Bay area startup. We opened an office in Oakland, mostly because that’s where I live. We went from there, so that the initial team was almost all coming from Oakland. There’s one person we got doing op stuff, who is in South Africa. And part of the challenge was like adding remote people was really hard, because the whole team is there in Oakland.

Like, we’re talking about strategy, and tactic, and products, and technical direction, and stuff over lunch, out everyday, like, it’s really, really hard to keep people in the loop if they were not colocated with us.

We eventually moved from IRC to Slack, and we started doing more and more stuff on Slack. We found that we actually needed to have a little bit more time zone coverage. So, we added some other developers, we hired somebody who was in Europe, and that really pushed us to operate in a more distributor friendly way. So, doing more of our discussions on Slack, having our meetings with Zoom.

We kind of just kept adding remote people. It was like, “Well, there’s those two developers we want to add, we want to hire.” And like, can they do remote, and one of them is remote, and you do that again, again, again, and after a while, it got to a point where like, our CEO is in Halifax, our CTO is in Toronto, I’m here in Oakland. We have this big beautiful office, and I’m one of like four people in it.

When we rented that office, we had this plan to like eventually grow to 50 people. And we were looking at the office we were in. We were 13 people, and we did not fit. We had a single conference room, a single room with a door that closed, and we grew to about 13 people, and we were just like, “This is ridiculous, we got to get out of here.”

We found a bigger space, we knew that we would end up growing to between 30 and 50 people over the next couple years, so we’ve rented the space that could house that many. I think it was just a few weeks or a month ago actually, or maybe a couple months ago, where we had this interesting situation where our landlord wanted to move us to a different spot within the building.

You know, we’ve been thinking for like a year how stupid it was that we had this big Oakland office, and like, we’d really like to get rid of it, but we’ve got another year on the lease. And they’re like, “Hey, we want to move you from the 11th to the 5th floor.” And we’re like, “How about we just leave?” They are like, “Yeah, cool. We get to rent the space out at 2019 prices instead of keeping your lease? Yeah, go.”

So, it actually worked
out great. It was a little bit sudden, the way that sort of fell on our lap. But
yeah, now we’re just 100% remote, everybody works from home, and that freed up
a lot of capital for us to actually offer like a monthly work from home
allowance, to cover things like internet, and the desk light, or whatever work
expenses you might have, whereas previously, it was like we really can’t afford
to do that because we’re spending our whole office budget on an office.

If you want to work in
the office, like, we got this great office, but most of our staff was not in
the Bay Area. So, in terms of like, where do we recruit people or how do we
find talent, we do get a lot of resumes, we do get a lot of interest especially
in technical roles.

When it comes to other
roles, when it comes to non-technical roles, things like sales or marketing – I
hate that term ‘non-technical’, like, the profoundly technical jobs, but if I
want to hire a product manager who doesn’t write JavaScript, if I want to hire a
VP of finance, it’s kind of the same thing every other company does.

We use a combination of
just our networks, which has some pros and cons. The obvious pro, hiring
somebody you know is you know them, so there’s a good chance that there’s a
little bit more of like a connection, they may be a little bit more motivated
to make it work, etc.

The downside is, you
probably know people who are like you, and so you can very quickly and easily
get into a bad cycle, where your kind of diversity just goes off a cliff. Or
even worse, we’re like people who are kind of in the crowd, or like included in
decisions, or have a little bit more power or authority within the company,
then they probably sort of can get very like toxic and weird that way. I think
that we’ve avoided that for the most part.

The other thing we’ve done in, especially tough to find rolls, we’ve had some success with executive search firms, we’ve done that a couple of times. And then, also posting stuff on LinkedIn, on Lever, on our other social media channels. We have our own npmjs.com/jobs that shows what roles we have open, and people apply for them.

Advice For Entrepreneurs

Michael Schwartz: The last question. Any advice for new entrepreneurs who are starting a business where open-source is a part of their business model?

Isaac Schlueter: I talked about this a little bit, but I’m going to go ahead and just repeat myself, because I feel like this is really important and really easy to miss and really easy to not understand the importance of it.

You have to craft your plan such that doing the free thing actually
serves your strategy. And there’s a lot of subtlety to that. I don’t have like one
weird trick that will fix everything. But you definitely need to think of, like,
“If we give this thing away for free, what happens?”

Part of the thinking there is, imagine that you have like ants roaming around on a dirt floor or on the ground, if you pour some honey in one spot, that’s going to change the whole ecosystem. And that’s kind of what happens when you start giving away something for free, whether it’s an open-source product, whether it’s a service that you say, like, “This is free for open-source packages or for open-source projects, or for open-source users whatever.”

You’re creating a pile of honey in the middle of all these ants that are currently just kind of roaming around in their own different ways, like, they’re all going to find it, and they’re all going to come to it. It’s like, “Okay, now what?” What I mean by that is, when you get something away for free, you are fundamentally kind of like disrupting an ecosystem.

It’s important none of the ants are complaining about the honey,
but you’ve now changed the shape of the scenario. And that can be really, really
good, or that can be really, really hazardous.

It’s tempting to be like, “Oh, I’m charging for this thing and I’m giving this thing away.” And how do I convince the free people to buy the paid thing? Like, you’d really need to back several steps up and think, “What do these people need? What’s the thing that I can sell them that will address that need? And what’s the free thing that’s going to drag them over?” Instead of saying, “What do I give away for free?”, and then separately from that, “What do I pay for it? How do I balance these two?” They have to be one thing in your mind.

Closing

Michael Schwartz: Isaac, that was super interesting. Thank you so much for joining us today.

Isaac Schlueter: Thanks for having me.

Michael Schwartz: Huge thanks to the Open Core Summit for connecting us to Isaac and for volunteering their only sales office to provide a quiet place to record. Don’t miss the next Open Core Summit. It was one of the best conferences I attended in 2019. Where else can you get a critical mass of open-source founders in one place?

It’s essential that we foster an event like this so we can share
experiences about what’s working in open-source business.

Please, subscribe to the podcast on your favorite podcast platform. Every subscription helps. Next week we have Shannon Williams, one of the founders of Rancher. He was fantastic, so don’t miss this one.