
How We’re Building a Business to Last - orangechairs
https://www.cockroachlabs.com/blog/how-were-building-a-business-to-last/
======
coffeemug
RethinkDB [ex-]founder here.

The problem wasn't that we (and presumably others) didn't plan for open-
core/cloud. We did, but there are structural problems in the market that
prevent this from working.

Open-core didn't work because the space is so crowded with high-quality
options that you have to give away enormous amount of functionality for free
to get adoption. Given how complex distributed database products are, by the
time you get to building a commercial edition you're many years in and very
short on cash.

Cloud didn't work because AWS/GCloud have enormous moats of pricing and brand
recognition. They drive margins down to epsilon, and if your product sees
meaningful adoption in the industry they launch their own service and take all
your customers.

~~~
jdoliner
Do you think there's something different that Cockroach could do? Or do you
think that the database market as it exists today leaves them without a path
to building a lasting business?

Personally I believe that latter. I don't see how they're going to get people
to pay for Cockroach with all the options that are already out there. I think
they might have an even more difficulty than RethinkDB did because their
interface is SQL which means that migrating to things like Postgres or RDS is
a lot easier.

~~~
mbesto
A majority of software companies can operate on RDS (and DynamoDB for that
matter) and utilize their built-in scaling functions. CockroachDB adds no
value to those customers, which will presumably make up the bulk of them
hypothetically becoming a profitable company.

Contrast CockroachDB with some of the other nascent open-source-to-successful-
businesses:

Influx - Solves timeseries applications challenges. (biz problem)

Citus - Solves a scale out technology problem with an already established DB
platform. (tech problem)

Confluent - Solves scaling issues with an already established data streaming
database. (tech problem)

Cloudera - Solves scaling issues with an already established big data
platform. (tech problem)

Elastic - Solves search application challenges. (biz problem)

Cockroach - Solves scaling issues with SQL databases by offering an
alternative DB. (??)

Unless Cockroach can position itself as either solving a technology challenge
with an already adopted DB solution, or solves a business problem, it's going
to be very difficult to achieve profitability.

~~~
mbesto
I should add. One of the reason I thought that RethinkDB might actually
survive was that (as far as I could tell) their database not only solve
scaling issues, but also helped solve real-time push to mobile apps. I'm
surprised they didn't position more to mobile app devs for adoption.

~~~
pbarnes_1
When I tested RethinkDB, it was an order of magnitude slower than Postgres.
That didn't match the website marketing, so I just gave up.

Dunno what that anecdote adds, but... that was my experience.

------
sytse
Great direction, I think they it on the head. If I would have to give
suggestions they would be:

1\. CockroachDB Community License (CCL) might sound like a Community Edition,
and that normally refers to the open source version instead of the proprietary
one.

2\. It is hard to quantify the difference between a startup and an established
company. We put the difference for GitLab at 100 people that can potentially
use our software.

3\. I see the CTO commenting here
[https://news.ycombinator.com/item?id=13438863](https://news.ycombinator.com/item?id=13438863)
that they will never move features from open source to the CCL Maybe they can
consider publishing a set of promises to the community. We did that at
about.gitlab.com/about/#stewardship

------
mikekchar
From the chapter by Michael Tiemann in Open Sources:

"At first I tried to make my argument the way that Stallman made his: on the
merits. I would explain how freedom to share would lead to greater innovation
at lower cost, greater economies of scale through more open standards, etc.,
and people would universally respond "It's a great idea, but it will never
work, because nobody is going to pay money for free software." After two years
of polishing my rhetoric, refining my arguments, and delivering my messages to
people who paid for me to fly all over the world, I never got farther than
"It's a great idea, but . . .," when I had my second insight: if everybody
thinks it's a great idea, it probably is, and if nobody thinks it will work,
I'll have no competition!"

I still find it interesting how many people dismiss Cygnus's business model
out of hand when entering the open source market. (Cygnus was acquired by Red
Hat for $600 million and Michael Tiemann is _still_ VP of Open Source
development IIRC) What is interesting to me is that I've never heard of anyone
else even trying it. No successes. No failures. As Michael Tiemann said, no
competition. And Red Hat enjoys that competitive advantage even today.

I highly recommend reading that chapter for an alternative view on how to
approach open source development.

~~~
webmaven
_> I still find it interesting how many people dismiss Cygnus's business model
out of hand when entering the open source market. […] What is interesting to
me is that I've never heard of anyone else even trying it._

Well, as I understand it, part of the reason is that contrary to their origin
story, Cygnus didn't really follow the "Cygnus Business Model" either, and
anyone trying similar tactics since then has had to deal with much greater
visibility.

------
hendzen
It looks like you are trying to replicate the MongoDB Inc. business model
(regardless of major differences in the actual product being offered).

MongoDB offers a commercial version of their product with enterprise features
(encryption at rest, LDAP auth, etc) and support - MongoDB Enterprise.

Additionally they also offer managed, cloud hosted MongoDB deployments -
MongoDB Atlas.

Over the last few years the valuation of MongoDB, Inc. has been slashed by
institutional investors such as Fidelity and BlackRock. While they haven't had
mass layoffs or some other negative corporate event, they have clearly had
some difficulty making their (and apparently your) business model work.

Do you agree that this is a fair comparison? And what do you makes
CockroachLabs more likely to succeed with this business model than MongoDB?

~~~
hnkimb3558
(Post author here) I'm not incredibly familiar with the ins and outs of
MongoDB Inc's business model, but I agree with your assessment. They certainly
seem to have embraced both of the OSS business models I described in the post
as viable alternatives. We are going to start with just one, and there's still
a huge amount on our plate.

MongoDB Inc did have its valuation reduced by some institutional investors.
Hard to say whether that was premature or what the impetus was behind their
decision. MongoDB is an incredibly well-adopted product that has gotten
considerably more capable over the years. I would argue they've had good
success with this business model, as building a $1.6B business is a huge
accomplishment whether you've got an OSS business model or not.

It would be fair to ask whether they've done the balancing act as well as they
might have. They've certainly knocked OSS adoption out of the park. On the
other hand, I've heard anecdotally that they waited a long time before
introducing enterprise features.

Regardless, I view MongoDB Inc. as a big - and still growing - success, and
consider much of what they've accomplished to be worthy of emulation.

~~~
hobofan
> (Post author here) I'm not incredibly familiar with the ins and outs of
> MongoDB Inc's business model, but I agree with your assessment.

"I don't know much about one of our signifcant competitors' business model."
doesn't sound like something you would want to hear from someone just
announcing their business model.

~~~
grenoire
I don't think that's a fair interpretation of 'not incredibly familiar.'

~~~
nickpsecurity
Point still stands. I'm not even in the market but have looked at the
community vs enterprise editions of successful companies to learn what splits
are already market-proven. Just curiosity for me in case I got into the
business. If I was in the market, I'd know everything about market leaders,
main competitors, and failures that seem like they should've worked. It's
necessary to compete with them to best effect.

------
sply
This can be seen as a kind of response to concerns about the survival of other
open source databases raised after closing RethinkDB and its recent postmortem
[https://news.ycombinator.com/item?id=13421608](https://news.ycombinator.com/item?id=13421608)

------
sciurus
> In 2017, any product whose core capabilities cannot scale without requiring
> a commercial license is probably setting the bar too low.

Is this a dig at InfluxDB for removing clustering from their open source
version?

~~~
user5994461
InfluxDB never had clustering in any version.

They announced that when they'd have clustering, if they ever do, it will only
be in a paid edition.

That's open for another debate entirely: Advertising and promoting features
that don't exist and won't in any near future.

------
lclarkmichalek
Do you envision features moving from CCL to APL? For instance, should the
database ecosystem change such that everyone and their mother are offering row
level geo partitioning in OSS databases, would it be likely that that feature
would become APL licensed?

~~~
bdarnell
(Cockroach Labs CTO here) We don't really anticipate making a lot of changes
like this, but yes, it's possible that as the product and market evolve we may
change our minds and relicense some CCL features as APL. Of course, we
wouldn't move in the other direction - once something has been released under
the Apache license it will stay that way.

------
mendant
If they really want to actually make money with a database, they would
implement binary compatibility with Oracle's SQL dialect, Oracle stored
procedure language, and its OCI binary protocol for programming from C.

There are plenty of big customers locked into Oracle. If you gave them a
backwards compatible but scalable database for half the price, they would
happily cut their costs in half, and make cockroachlabs very rich.

And then Oracle would offer to buy your company.

------
inconclusive
> So what doesn’t a startup need to succeed, but an established company would
> consider an important requirement.

> The first is a fully-distributed, incremental capability for quickly and
> consistently backing up and restoring large databases using configurable
> storage sinks (e.g. S3 or GCS). The same functionality, but non-distributed,
> will be available for free to all users.

I appreciate that you're trying to write a good database and build a business,
but what do you mean by "startup"?

If a database can't guarantee it can make backups, why would a startup attempt
to use it in the first place?

~~~
bdarnell
(Cockroach Labs CTO here) This could have been worded more clearly in the
post. There will be two versions of backup functionality: a basic
implementation for free (Apache license) and a faster distributed and
incremental implementation as a paid feature (CCL). It's like the difference
between mysqldump and an InnoDB-aware backup tool.

~~~
haimez
Sounds like crippleware for a distributed database.

If you can't incrementally back it up, you can't really afford to run it in
production in a cluster that has a large dataset. If you don't have a large
dataset, you don't need cockroach db (first law of distributed objects, etc).

Maybe you'd be better off designing features for clients with specific
requirements and very deep pockets.

~~~
elcritch
Not necessarily, even small datasets can benefit from a distributed database.
Configuring a HA database setup for any of the open source DB's requires a lot
of work. For a startup, a small cluster can provide HA, redundancy, and ease
of scalability should the need arise.

~~~
haimez
No one cares about the difference between 99.9 and 99.999 reliability at the
DB layer and then adopts a new open source DB to solve that problem.
Especially when that exciting, new, experimental database cripples your
ability to back it up. Hilarious.

------
RichardHeart
What's wrong with actually charging money for what you make? I think the over
open sourcing of things leads to a tragedy of the commons whereby no one can
profit enough to afford a marketing budget. Or if they can afford one, its
100x smaller than anyone else in the space that "charges" and is closed not
open.

------
filereaper
I'm really looking forward to the 1.0 release of CockroachDB. S3 and GCS were
mentioned as configurable storage sinks, are there plans to release with Azure
Blob as well?

~~~
mjibson
Yes, Azure blobs will be supported. (I'm a dev here and just finished that
feature.)

------
agibsonccc
Disclaimer: I am outside the database market (we view it all as just
"storage")

We are a similar play (open core, etc) I commented in the rethink thread as
well.

A few lessons on the business model we ran in to:

1\. Cloud is commodity/experimental. It _could_ be the future though and
there's no reason not to have an offering at least. We are launching a
partnership with microsoft on azure to experiment with cloud for their hadoop
offering. We found it was bring your own license and very similar to on prem.
It seems like a no brainer to at least try this.

2\. We are on prem first. Enterprise customers need "pay to blame" kind of
like insurance. We have closed source features we license. Support is
secondary and comes only with a license.

3\. Bundling and minimum purchasing is key. You _need_ to validate a customer
has a budget.

1 thing that I notice database companies don't cover which kind of surprises
me (that cloudera,red hat, etc do) is training and the "services swamp" 1 way
to qualify customers and increase run way is a "small" amount of support you
charge a high rate which in turn drives licensing revenue on top. A lot of the
companies that have actually stood the test of time started like this.

Where we deviate:

1\. Building a horizontal platform but focus on 1 product at a time. In our
case, we have a generic platform we can license for teams that just need
"something better". We focus on a use case such as fraud/network
intrusion/money laundering and sell that. This is very similar to the oracle
model. "Bundle a database with the app"

2\. Any services we end up doing we put aside to turn in to a product down the
road. In our case, we observe and learn the patterns and reapply those as
"templates". In our case we accumulate expertise, make a bit of money, and
monetize later. Many SAAS companies in our space keep the customer data
because they need to build better models. I'm not quite sure what the analog
in the database market here is. We just keep the "lessons learned". The key
here will be scaling that. In our case, we do that by focusing on 1 vertical
use case and owning that. We also minimize engineering time on the platform.

In short: We have a dual licensing model where we have an "app" that's easy to
sell in the market, get paid to explore the market (while focusing
on/prioritizing 1 use case for more scalable revenue, and for teams that just
need a better platform, we can just offer that and make some fairly passive
licensing revenue.

1 other neat anecdote: for all the people raving on HN about what google's
doing with AI, the problems people had 50 years ago are still the same ones
people pay for today. The database market maybe similar, it might not be bad
to learn from your predecessors but maybe just update the business model a bit
(eg: cloud offerings,..) At the end of the day people pay for use cases over
everything else. Think about the _reason_ they are about HA not "HA is cool,
they obviously want to pay for that"

------
pbarnes_1
These are famous last words. You can't predict any of this.

------
kmicklas
What about AGPL?

