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.

Ben Golub has lead several open source software ventures, including Gluster and Docker. Storj monetizes open source by creating a distributed file storage network. Using the network, people can securely store files. And owners of Internet connected computers can put their unused disk capacity to work. To lower transactions costs, Storj launched a true utility token, which has intrinsic value. It simplifies transactions of an alternate 150+ fiat currencies. This episode was recorded in person at the Open Core Summit.

Transcript

Intro

Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 37, with Ben Golub, CEO of Storj.

I was really excited to schedule this episode because for a few years I’ve been wondering if there’s some cryptocoin business model that might work in the open-source world.

This is the second of three episodes that we recorded at the Open Core Summit in San Francisco in 2019. It was a fantastic event for open-source teams and founders, and I highly recommend attending the next one.

Ben was previously the CEO of Docker, he was also the founder of Gluster, which was sold to RedHat. He has a pretty deep understanding of the trials and tribulations of building a business around open-source.

After finishing the interview, I wasn’t 100% sure this was really an open-source business model after all, but Storj is definitely one of the most unique companies I’ve ever learned about. So, with that said, let’s roll the proverbial tape.

Origin

Michael Schwartz: Ben, thank you so much for joining us today.

Ben Golub: My pleasure.

Michael Schwartz: Ben, before Storj, you helped found a company that launched a little product called Docker – can you tell us a little bit about your journey? How did Storj come about, and why did you move on from Docker?

Ben Golub: Yeah. I’ve now been at 8 startups, four CEOs, so I’m a glutton for punishment. I actually started my career doing international development, so my first failed startup was a business school in Uzbekistan that had a business model, which was I think, “Teach people how to read a balance sheet and then democracy will flourish.” And that didn’t quite work.

But from then on, I’ve been involved in sort of the first version of the web, ran a number of businesses at VeriSign, was the CEO of Plaxo, was the CEO of Gluster, which we sold to Red Hat, and then ended up at what was dot.Cloud, and it eventually became Docker.

Right at the time, Docker had this crazy notion of taking a container that we used to run a PaaS and said, “Hey, can we make this available to the world?” And Solomon Hykes, the founder, and I introduced this notion of a container. And I think in sort of excellent open-source fashion embraced the community, embraced something that was disruptive.

We saw it grow, and it became tremendous. I think it helped change the industry and became a driving business. I’m an early-stage startup guy, I’m not a late-stage startup guy, and I think that once you want to get to a certain size, where it’s 500, 600 people, and you’re closing in on a hundred million revenue, there are people that are better at scaling PaaS than I am.

So, I moved on. I still obviously love the company. And then, I got approached by Shawn Wilkinson, who had this crazy notion as a student at Morehouse College that you could build Airbnb for disk drives, and that’s what I’m doing now.

Is Storj Distributed S3?

Michael Schwartz: I think of Storj as decentralized S3.

Ben Golub: That’s absolutely accurate. Deliver something that’s S3, its cloud storage, but it’s delivered across a huge network of disk drives that we don’t own, that are run by individuals and data centers.

How Does Storj Make Money?

Michael Schwartz: So, for every dollar raised, 60% goes to the person with the hard drive? The other $0.40 I guess goes to storage, the company – how do you use that $0.40 to help build the ecosystem?

Ben Golub: It’s a really good question. One of the most important things that we do is, we sort of build equivalent of really large self-storage data centers, without spending any capital, and we just compensate the people who run the nodes.

We are onto the same thing on demand side as well, so rather than hiring hundreds of salespeople and giving away open-source software for free, we’ve come up with the notion that open-source drives 2/3 of the cloud, so we give a portion of our $0.40 to any open-source software company.

Usually, our way is, we also have partners in the Storj space, we are partners like Mongo, FreeNAS, FileZilla and Influx, and it’s really a great win-win.

Who Are The Users Of Storj?

Michael Schwartz: Who are the users of Storj? What type of applications is it good for?

Ben Golub: Its really general object storage, which means that anybody who’s generating a large file that is going to be read a lot, it’s an excellent use case for us. That’s good for backup, it’s good for serving videos. It’s good for distributing software.

The world of course creates lots and lots of data every year, and about 90% of it that’s being created is sort of large files, which is a perfect use case for us.

Why Use Storj Over S3?

Michael Schwartz: Some would say that you have to be ten times better than a previous existing solution to motivate people to move – why would someone use Storj over Amazon S3?

Ben Golub: That’s a good question. And they almost have generalized it to the centralized cloud storage offerings. One interesting note is that while the price of disk drives has come down roughly 50% over the past five years, the price of cloud storage has come down maybe 10%, during a period in which the amount of data of course has exploded.

We are significantly cheaper, we are also profitable. We are also significantly, we think, a much better security model. And we can’t read your data. It is almost impossible for a hacker to get your data, or get a treasure trove data – it’s like sort of encrypted sand on an encrypted beach.

We also happen to be faster. We happen to be 100% durable, and at a significantly lower price. What we’ve found is, there’s almost insatiable demand for people to try us out. Now, it’s early, so people are dipping their toes in the water, using test data first, or you know, low value use cases, but we think when they see what we’re doing, they’ll be here.

How Does The CryptoCurrency Work?

Michael Schwartz: Google tells me that Storj as a cryptocurrency issued on the Ethereum platform. The price they told me is $0.1514 cents, and a 24-hour trading volume of three million, prices up 3% in the last 24 hours.

Ben Golub: Oh, it must have been my speech.

Michael Schwartz: It is a circulating supply of $144M coins, of max coin supply of 425M coins. So, my question is, how does a cryptocurrency relate to the monetization strategy of the company?

Ben Golub: Our basic economic model is that we quote prices for Storj, and we quote them in dollars. And as a consumer of our service, you can either pay for storage with us in dollars or in our cryptocurrency.

If you are a provider to us, if you are renting out your disk drive, we pay you a dollar rate, we pay you using our cryptocurrency.

And you can either hold onto that, you can use it to buy storage on your own, or you can trade it on one of the 11 + exchanges that are using us.

Unlike a lot of other crypto companies, we’re primarily a decentralized storage company. And the crypto is a great accelerant, it lets us have hundreds of thousands of people get paid in 180 countries and build things like smart contracts. But we’re not a mining company, we are a company that is first and foremost about delivering a much better approach to storage.

Why Use A CryptoCurrency?

Michael Schwartz: Why was the cryptocurrency a better way than just settling in cash?

Ben Golub: Well, it turned out to be very difficult to settle in cash in small amounts. It’s very difficult to do things like smart contracts using cash money. We are in 180 countries, so what we found is that having the cryptocurrency made it much better for us to build a large network.

Now, we could certainly be entirely fiat-based, but then, there would be additional fees, but this seems to align well with our interests.

What Is The Disconnect With Value And Economic Empowerment?

Michael Schwartz: You’ve said in the past that there’s a disconnect between the value created by open-source software and the amount of economic empowerment – what did you mean by that?

Ben Golub: If you look at for example the cloud market, which is now a 180-billion-dollar market, over 2/3 of all of the workloads are open-source based. In fact, if you were to include Linux in that, it’s about 90% of the workloads.

It is very clear statement to make that open source built the cloud. If you look at the total revenue generated by pure-play public open-source companies, like the Red Hat’s, and the Hortonwork’s, and Cloudera’s of the world, their total revenue is about 5 billion. So, 5 billion out of 180 billion.

If you talk to any open-source company that’s doing things in infrastructure, what you’ll find is that the primary way in which they are being monetized now is by Cloud companies, who, for rational reasons, basically give away the software for free, in order to drive consumption of additional compute cycles, or additional storage cycles.

And unfortunately, cloud computing is the biggest trend and monetization by giving away for free is the biggest way that open source is getting monetized. And there are really only four companies on the planet that are capable of running large public clouds. That to me is a huge disconnect.

Is Cloud Strip-Mining A Victimless Crime?

Michael Schwartz: On this podcast, we’ve had several guests who are worried about what we called Cloud strip-mining of open-source software, and they see it as really an existential threat to the open-source ecosystem.

And yet, Elastic, Redis and MongoDB are doing pretty well. Is this a victimless crime? And is it desirable for the companies that develop the open-source companies to capture all, or even a majority of the revenues, in the ecosystem?

Ben Golub: I agree that there are a handful of successful commercial open-source companies, I happen to have been at a couple of them, but these are just a handful of them. And almost all of the ones that you mentioned have essentially gotten to their state by spending hundreds of millions of dollars to go directly to the on-premise businesses.

And while I think it is wonderful, and it’s great that there are success stories that there are, I don’t think we would be happy if we said, “Hey, there are only five successful farmers in the world out of millions of farmers.” We wouldn’t be happy if we said, “Hey, there are only five or ten, successful companies in general.”

There is so much potential, and so much of these trillion-dollar IT industry, and 180 billion-dollar Cloud industry is being driven by open source, but if it isn’t flowing back in, then, we’re really not going to see the potential that open-source could really bring to us. In much the same way that I don’t think telecommunications was delivering on its full potential until we went to the internet.

Does Decentralized Cloud Offer An Alternative Business Model?

Michael Schwartz: So, selling to these large enterprise customers, as you mentioned it, an on-premise software product is really expensive to scale support in sales. And it could be tens of millions or even hundreds of millions of dollars actually build that kind of infrastructure – but does decentralized cloud approach change that for these companies?

Ben Golub: Yes. For an open-source company that partners with us, if they have an open source project, whether through paid users or free users, generates lots and lots of storage. My guess is that they are generating lots and lots of money for one of the big four cloud providers, but are not seeing any of that.

Instead of trying to come up with a new kind of license, we come up with a new kind of cloud, a centralized cloud, like Storj, it’s entirely in our rational benefit to say, “Hey, if you have an open-source company that drive storage to us, we will give you a healthy chunk of the revenue that we get. And so that’s what we do.

All of a sudden, they’re able to build up a sustainable revenue source that doesn’t require hiring lots of salespeople, it doesn’t require trying to solve the multi-cloud problem for the 500 large companies in the world that they can do that.

Now, we may not be-all and end-all, we may give them the first two years of additional runway, so that they can build a sustainable base, and then go after the enterprise – and that’s fine. But getting from big community to successful enterprise sales is a really hard gap to close without the cloud.

Does The Market Value Open Source?

Michael Schwartz: Recently I was reading an S, and I did a search for open source, and the only place I found it, was in the risk section that, you know, somehow using open-source might come back and bite us, and we might have a liability. Do you think that the public is really aligned with this view that open source is a good thing?

Ben Golub: I think there’s no question to me that open source itself is the dominant way that software is getting written and consumed. Go to any enterprise, and it’s far more likely to find that they are open-source first rather than proprietary.

If you look, all these same things are happening, whether it’s Containers, or Docker, Kubernetes, or Mongo, or databases, or in operating systems, or in machine learning – it’s all happening in open source.

But the monetization of that is broken. It’s not that anybody questions that open source is a right way to build great software, it’s that the monetization model that used to be fairly clear has now gotten disrupted by the public cloud.

Michael Schwartz: Because one of the best monetization strategies of offering and as-a-service is now not available?

Ben Golub: It’s not available. If you are a small company, it is almost always a much better idea to say, “Hey, let me service lots of small and medium-sized customers first with something that looks like a service, rather than trying to do on-premise.”

You might eventually get to on-promise, but unfortunately, that model, which used to work pretty well for open source, is really difficult now. And it’s not only that you sort of have this gap between large community and getting to on-premise, but increasingly, even the on-premise market is now becoming dominated by public cloud.

Does Open Source Materially Contribute To The Business?

Michael Schwartz: Do you think that using the open-source development methodology materially contributes to the business?

Ben Golub: It really depends. I’d say open source is not a strategy, it’s a tool. And you have to find the right approach to open source that matches with your business strategy. But, if your strategy — Docker certainly could not have happened had we been proprietary.

We could not build a huge ecosystem and get so much usage and integration if we were proprietary. And then, the challenge becomes okay.

Now, we’ve got millions of users and billions of downloads, and lots of enterprises are interested in how we turned that into monetization. But, honestly, that’s a much better problem for me to try and solve than, “Gosh, I’ve got some proprietary. I can’t take anybody even take a look at it, and it doesn’t work with anybody else’s stuff.”

When To Open Source

Michael Schwartz: What do you think are some of the indicators as to when the project should be — where open-sourcing it might be helpful?

Ben Golub: I think that there are a few different things to look at. I think, first of all, you want to, in any project, do that 10x thing that you said. If you’re just coming up with an open-source version of salesforce, and the only difference is, it could be slightly cheaper, that is not going to happen.

The disruption was being SaaS, the disruption isn’t on the code side. But I think that, to the extent, what you are building requires a strategy that wants to build a large top of the funnel. You know, if it’s something that’s developer-centric, if you have a strategy that depends on having lots of integration, if you have a strategy that depends on being disruptive, then those cases, I think, you want to look at open source. If you’re just an end-user application – probably not.

Storj Virtuous Cycle

Michael Schwartz: You mentioned that with Storj, there’s a virtual cycle of investment, growth monetization, and innovation – can you unpack that a little bit because that’s very concise?

Ben Golub: Sure, again, we are a different kind of cloud, and since 2/3 of cloud workload is given by open-source, we’ve sort of elected to try and make the open-source community part of our go-to-market, but in a mutually beneficial way.

In the model that we have, if you’re an open-source company, and your product generates lots of data whether by your free users, by your page users, it doesn’t matter, backups, if you build a connector that gives your user the option to send that data to us, versus another form of object storage, will give you a chunk.

What does that set up? It sets up a nice virtuous cycle, in which open-source innovates, open source generates revenue for us, like in similar decentralized networks. We, in turn, send revenue back to open source, which allows them to innovate further and build their own business models, and it continues.

Other Decentralized Opportunities?

Michael Schwartz: You mentioned that decentralized cloud is potentially a new business model for open source. And I understand how you’re saying, if you write an open-source piece of software that uses Storj for file persistence, that you could generate revenues from that. Can somebody build a company like Storj that uses a decentralized approach to something else?

Ben Golub: Yeah. There are companies – we are sort of decentralized S3, as you said. There are other companies out there, like Xiamen and others, who are trying to do decentralized DC2.

Of course, there are a lot of interesting decentralized payment companies, there are interesting decentralized CDN companies. Each of these has basically been taking a fairly horizontal use case that the cloud companies deliver, but deliver it in a decentralized way. And I think, in all cases, we would all be well-served by embracing this notion of mutually beneficial relationship with open source.

Other FOSS Cryptocurrency?

Michael Schwartz: The only company that we’ve interviewed, who has issued a cryptocurrency, do you think that there’s opportunities to use cryptocurrencies for other purposes? Maybe to help either fund or reduce transactions cost for developing or monetizing?

Ben Golub: Absolutely. I’ve seen lots and lots of interesting crypto companies, and there are lots of not so interesting ones that are just ‘fly by night’ operations. But, among the interesting ones, with blockchain and cryptocurrency, what we needed to do is sort of create these large decentralized networks, where trust is sort of built into the network, rather than residing in a particular individual.

And you can make payment algorithmic. There are a lot of interesting experiments, for example, to say, ”Hey, let’s reward people for contributions to open source based off of using crypto currency, and doing it in an algorithmic manner.” And it gets really an interesting idea.

But ultimately, for anything like that to work, somebody has to be able to drive economic value for the open-source to begin with.

And my guess is that’s not the people who today are generating the value, which is the public cloud companies.

Challenges Of Launching A CryptoCurrency

Ben Golub: Yeah, we were sort of fortunate that we did it right. And we also, in 2017, we had a network built and launched before we did a token sale. The token sale had utility from day one, and we’ve tried really hard not only to be enterprise-grade in terms of our product, but to be in a serious enterprise-grade in terms of our governance and management of the token and our treasury policies, inside our trading and governance, all those good things.

Treasury / Governance Of Currency

Michael Schwartz: Storj actually holds cash or an amount of cryptocurrency that’s let’s say unissued – is that how it works?

Ben Golub: Yes. We generated in our token sale 425 million tokens, and then in essence, we broke the mold. So, there will be no more ever created. We sold 75 million in our initial token sale. Since that time, of course, review tokens to compensate people who are running nodes, some people have paid us back in tokens.

Right now, there’s about a 125 million storage tokens in circulation, and then, the remainder we have, the biggest chunk of that, is in time lock, so that it won’t be entering the market in an undisciplined way.

View On Red Hat Acquisition

Michael Schwartz: I could probably keep asking you questions about cryptocurrencies for the next half an hour.

Ben Golub: Oh, that’s okay. Happy to answer that, but now, I’ll be honest, I find cryptocurrency far more interesting than decentralization. Because, ultimately, I think that if that’s a tool, and cryptocurrency is a small part of blockchain, and blockchain is a small part of decentralization. Decentralization is in some way even bigger than Internet, because Internet in itself is decentralized.

Michael Schwartz: Slightly off topic question, but is the acquisition of Red Hat by IBM a good thing for the open-source software segment?

Ben Golub: I think it really depends on how IBM manages it. Some companies do a great job at acquisitions and some don’t do a good job. I have to say that I actually sold a company to Red Hat Gluster, which, of course, Red Hat has now become part of IBM.

I think to the extent that IBM enables, or allows, Red Hat sort of to open-source roots, but helps it sort of continue to flourish as a shining example of commercially successful open source, I think it’s great.

Personally, last year, I was able to say, “Hey, it’s fantastic, we now have more than Red Hat.”, as an example of a public open-source company, and Red Hat, and Hortonworks, and Cloudera and RealSoft and, and now Mulesoft has been acquired. Cloudera and Hortonworks have combined, and Red Hat is now part of IBM. Elasticsearch entered, but there’s fewer public open-source companies.

Michael Schwartz: Now, we have less.

Ben Golub: Yeah. And, of course, the largest one is now no longer independent.

Move To Open Source License

Michael Schwartz: Recently, several prominent companies in our industry, like Cloudera and Chef, moved to an all open-source strategy, then moved away from open core. Do you think open core has peaked and will move back towards a more truly open-source model?

Ben Golub: Well, it’s interesting, because on the one hand, you’ve seen some people become more permissive with their licensing, and then you’ve also seen other companies become more restrictive, and come up with a sort of new licenses to deal with the Cloudera.

I don’t have a dog in that fight, except I think that the answer to monetizing the cloud isn’t a new kind of license, I think it’s a new kind of cloud. And that’s where we come from. Because, ultimately, yes, you can add value to open source by making it better for large enterprises, whether it’s through proprietary modules, or services support, or subscriptions, or packaging.

I think there’s all kinds of variations on a theme. What we need to do is find a way that you can make open source monetizable for large numbers of small and mid-sized companies, or even larger companies that are running in the cloud.

Biggest Challenges For Open Source Businesses?

Michael Schwartz: Putting storage solution aside for one second, what do you think are the biggest challenges today facing entrepreneurs who want to build a business around an open-source software project?

Ben Golub: I think that the first challenge most have to do is, like any great open-source project, build something compelling and build an exciting community around it – that’s a hard thing to do.

I think that what they then need to figure out is how do they build a sustainable business model that can carry them from the time they have a really big community to the time that they have a sustainable economics.

Along the way, it gets really difficult. Even if your community is successful, how do you manage your community, how do you monetize, how do you make it possible for people that participate in your community, without undermining it, and how do you avoid going down to the point where all that you get from a large company is just charity.

I’m not saying charity in a bad way, but I’m saying, when I was running large open-source communities, what I wanted from the cloud companies wasn’t some cloud credits. I didn’t want them to say, “Hey, I’ll put two people on your thousand-person projects.”

It’s nice, but what we really needed to do was have a mutually beneficial business relationship, so that we could invest and grow.

Advice For Entrepreneurs

Michael Schwartz: What advice do you have for the entrepreneur who needs to lead this open-source effort? You’ve been through the entrepreneurial journey many times, and I’m just wondering if you have any advice for the person who is actually going through that journey?

Ben Golub: Well, of course, it is a journey. As they say, it’s a marathon, not a sprint. I think, personally, what you have to do is, you have to love what you’re doing. And I think especially for an open-source, you have to believe that the journey will be worth it even if you can’t feel the successful business.

Because, what you are doing, it’s interesting enough for you, and it’s going to be hard to build something interesting enough for the community. But having done that, I think you need to think really clearly about where you want to be each year over the next five years. I think you need to think really clearly, from my point of view, over what your monetization strategy is going to be, and who are your users, and what is your use case.

I think far more startups fail because they don’t pick a direction than because they choose the wrong direction. I think if you articulate internally a really clear direction, and then, you’re consistent in saying that’s your model, whether it’s open core, or service and support, or access, or whatever it is, and then you are relying on everybody in your company – I hope choice of strategies is right.

But even if it’s slightly wrong, at least you’ll all be running in the same direction, and you can change course. The worst thing that I’ve seen in startup after startup after startup is, they don’t pick a direction.

Everybody runs at five different directions, and they know they are failing and they don’t know whether it’s because one of those is wrong or because all of them are wrong.

Closing

Michael Schwartz: Ben, thank you so much for taking the time out of the conference today to record the podcast.

Ben Golub: Great questions, thank you.

Michael Schwartz: Huge thanks to the Open Core Summit for connecting us to Ben, and for making space to record at the 2019 Summit. Don’t miss the Open Core Summit next year. It’s a fantastic event for founders and open-source teams.