Open source project Rethinkdb closed, founder summarizes failure lesson (market positioning error)

When we announced that RETHINKDB was closed, I promised to write a survey analysis. It took me some time to sort out the lessons and experience that can be clearly written.

In the HN discussion post, people raised many reasons for why RETHINKDB failed, from the inexplicable humanity and the clever MongoDB marketer, to the absence of an experienced listing team, to the lack of a number type that supports more than 64-bit float ... I'm going to focus on these ideas here.

Some of these reasons are true, but they are symptoms and not the cause. For example, if we fail to make money, it does not tell us why we failed.

In hindsight, there were two important reasons for our failure-we chose a horrible market and optimized the product according to the wrong indicators. Each error can reduce the valuation of RETHINKDB by one to two order of magnitude. So if we think that one of them is right, then RETHINKDB will be the size of MongoDB, and if we think that all two of them are correct, we may end up with the size of Red hat (don't think these numbers are close, it will let you know the cost of these errors).

Terrible market.

Our idea is this: the new company is not built on top of Oracle, so there is the opportunity to build a new infrastructure company. The database market is huge, and if we create a product that captures a portion of the market, our company will be very successful.

Unfortunately, you are not in the market you think you are, but in the market that your users think. Our users think we are an open source development tool company, although this is our original idea. This is very unfortunate because the open source development tools market is probably one of the worst markets. Thousands of people use RETHINKDB in business, but most people are not even willing to pay the price of a cup of Starbucks coffee (that is, they are unwilling to pay anything).

This is not because the product is too good to be supported by others, or the developer does not control the budget, or the failure of capitalism. The answer is basic microeconomics. Developers like to create developer tools and are usually free, so there is a lot of demand, but the supply is plentiful. The number of substitutes has risen and prices have fallen to zero.

See how other companies are: MongoDB (about $160 million, about 700 employees) and Docker (market capitalization is about 1 B, about 300 employees). Two companies are fully dominant in their respective markets. The two very rough rules of thumb for a growing private tech company are: valuations are 10 times times the annual income, and each employee earns about $20,000 a year. This means that MongoDB's annual revenue is about 140-1, $600 million, and Docker's annual revenue is about 60-1, $0.

This looks good until you see the main business-to-market technology companies that are not focused on developer tools. Companies like Salesforce,palantir or box (facing fierce competition). Suddenly MongoDB and Docker look weak.

All of this has been a great success. What does it mean for a budding startup to have a relationship with an existing company, distribution infrastructure and access to a large number of accounts?

For us, this means a hard-to-handle customer acquisition channel. Entrepreneurship in a fertile business-to-trade market has to deal with 100 potential customers to get 10 opportunities, ultimately a sale, and 10 times times more opportunities for a start-up company with a development tool. You can access a large number of high-quality leads-many people are downloading your products and interacting with you, but you have to spend a lot of clues to get an order.

This is a disastrous domino effect. It makes the morale of the team so that attracting investment and hiring top talent becomes very challenging. This, in turn, limits your resources so that you cannot invest adequately in products and distribution. The survival or death of a startup is driven by power, and early allocation challenges can almost lead to eventual death.

Error metrics

Well, although the market is not good, other development tools companies still sell a lot of products. Why not RETHINKDB?

Although we cannot intervene in the dynamics of the market (apart from building something else), the product decision is entirely within our control. We want to create an elegant, robust and aesthetically pleasing product, so we have optimized the following metrics:

• Correctness. We have made very strict guarantees and have strictly fulfilled them.

• The simplicity of the interface. We take on most of the complexities of the implementation process, so it's easier for application developers.

• Consistency. We did it. From the query language, the client driver, the cluster configuration, the document, and the marketing copy on the home page are as consistent as possible.

If you find these tradeoffs seem familiar, they are "worse is better" (i.e. quickly take out prototypes, listen to user comments, and then continue to add functionality to fix bugs). Original, correctness, interface simplicity and consistency are the error metrics for most users. Instead, most users want these three criteria:

• Timely. They want the product to exist when it is needed, not three years later.

• The speed of the contact is known. People want RETHINKDB to be able to quickly achieve the workloads they want, rather than the "real-world" workloads we recommend. For example, they would write a quick script to measure how long it takes to insert 10,000 documents without reading them. We lost the market learning this battle, MongoDB skillfully mastered these workloads.

• A useful thing. We started building a good database system, but the user wanted a good way to do something (for example, a good way to store JSON documents from Hapi, a good way to store and analyze logs, a good way to create reports, etc.)

Not that we didn't try to get rethinkdb to ship fast and build up its surrounding ecosystems, making useful work easier. We did that. But the right, simple, and consistent software takes a long time to build. This has left us behind the market for three years.

When we feel that RETHINKDB meets our original design goals, and we are confident that we can put it into production, almost everyone asks "What's the difference between RETHINKDB and MongoDB?" "We try to explain why correctness, simplicity and consistency are more important, but these are not the most important criteria for most users.

To be honest, it's been a big blow. It's hard to understand why people choose a system that doesn't do what it's supposed to do (store data), and there's a big kernel lock, random discard errors, a single node function, a virtually non-working shard system, though it's one of the core features of the product, which basically doesn't guarantee correctness, and exposes interfaces that have no discernible consistency or visual consistency.

Every time MongoDB publishes a new version, people will congratulate them on making improvements, which makes me feel sad. They will announce that they have repaired the BKL, but in fact they will drop the granularity from a database to a collection. Instead of a combination interface that fits the rest of the system, they simply use a one-time command. They will make sharding improvements, but it is clear that they are unwilling or unable to make basic data consistency guarantees.

But as time went on, I learned to appreciate the wisdom of the crowd. When people need it, MongoDB can turn ordinary developers into heroes, not years later. It makes data storage fast and allows people to quickly receive goods. As time went on, MongoDB grew up. They solved the architecture problem one by one, and now it's an excellent product. It may not be as perfect as we want it to be, but it does its job very well.

In the 2014 we were clearly aware that we were at a disadvantage in the competition, and we tried to differentiate it from MongoDB. We found a very elegant way to add real-time push, hopefully allowing developers to build a generation of applications that they could not build before. But that's not enough. Suddenly, we find ourselves competing with Meteor and firebase who are almost ignoring the many years of commitment to solving real-time problems. We were three years behind the market again, and then we found ourselves completely defeated.

Cloud Services

Several people suggested that we should build a cloud service. We actually have one of those works, so it's an interesting topic I want to talk about.

The obvious problem with small database companies building cloud services is that its pattern matches a common startup failure pattern-split focus. Building, transporting, and operating a reliable multitenant cloud service is difficult and requires extraordinary expertise and resources, so if you go down this road, you find yourself running two startups at the same time. But we are faced with an existential threat and have made a quick choice, so we can only give it a short shot.

Our reasoning is that the database cloud provides services that can be one of the following three: managed, database as a service (DBaaS) or value-added platform as a service (PaaS). Use the above-mentioned per-employee income of about $20,000 per year for empirical rules to quickly retrace market analysis:

So these markets are small, even smaller than the database market itself. But can one of them be better than others?

Managed hosts essentially run databases for people on AWS, so they don't have to. An alternative to using these services is to set up your database on AWS yourself. It's painful, but it's not that hard. But there is a very difficult limit on how much hosting database hosting services can charge. Considering that the number of MongoDB users Compose.io and Mlab provides is one to two orders of magnitude more than RETHINKDB, we believe that providing managed hosting does not have an impact.

The database as a service is a more complex managed managed version-Dbaas provides complete management from the user Abstraction node. You just run your queries and the system processes them. You don't know how many nodes are running under the hood. This business is very challenging-partly because Dbaas companies have to compete with Giants (such as Dynamodb and Documentdb), partly because when there are many alternatives and alternatives, It is very difficult for the customer to give the data management to the start-up company completely. Do you know who is using a startup Dbaas product? So a Dbaas product came out.

The last option is to build a value-added platform as a service. We think this is promising, because we have a huge technical advantage in this area. Firebase and Meteor must build application-level real-time logic on top of MongoDB, fundamentally limiting real-time query functionality and performance. On the other hand, we control the stack all the way, so we have a significant advantage that firebase and meteor don't.

So we created Horizon and started working on Horizon Cloud-a way for users to deploy and extend Rethinkdb/horizon applications. The challenge of a very small team to build three large projects (Rethinkdb,horizon and Horizon Cloud) eventually caught up with us, and we never intended to give up the cloud service before we run out of money. Give the applause to the engineering team, who are very, very close to success.

Meta issues

We can also do a level of root cause analysis. Why do we choose a bad market and optimize the product according to the wrong indicator?

When I was a child, I wanted to build my own radio. I made a box of plywood with some metal garbage in it and connected the box to the power cord. I have ebooks at home, but I don't think I need them-I have a firm belief that I can do it myself. Eventually, I built a work receiver, but it took me years to finally realize that I needed to learn basic electronics.

Early RETHINKDB was a bit like this. We have no intuition about the product or the market, so we passed a motion to build a company without really knowing what we were doing. What's more, we have a lot of optimism bias (human beings tend to estimate the future better than it actually is.) ）。 Just as doctors know that gifts from pharmaceutical companies have a bias against other doctors, but believe they are immune from this effect, we believe we are immune to the mathematical laws of the economy and business. Mathematics, of course, finally gave us a taste of the bitter fruit.

What can we do to avoid these mistakes? It is not the childhood of the albeit, a radio that can work. Unconsciously, we are not competent, and this sense of powerlessness will be realized after a few years.

Several people have pointed out that if we build an experienced listing team, we will do better. The 100% is true, but the timing of our personal development is not in line with the company's needs. Initially, we did not know that we needed to enter the market expertise, so we did not want to include it in the founding team (by the way, no good business intuition, know good business people like, not a strong intuition of the project to know a good engineer as difficult). When we are psychologically prepared, we find ourselves in a market full of competent competitors, but with a shortage of funds, only one product after three years. By then, the best listed team in the world could not save us.

The missing of parting

Many people have a very strong sense of the development tool market. Engineers like to build development tools, so they want to make development tools companies thrive.

I totally ignore the market-because I don't want to use a single experience to promote it, because I don't like to say "it can't do it" because there are many exceptions. Github,mongodb and Docker have built a strong company. Gitlab and unity seem to be doing very well.

If you are going to build a developer tools company, be careful. The market is filled with many good substitutes. Users expect high, low prices, and seriously think about the value you provide to customers. Remember--You want the world to go in a certain direction don't have to make it this way.

In 2009, we showcased the early ideas of RETHINKDB (we don't have software) on YCombinator Demo Day to the investor audience. We wrote three points to remember on the end of the slide. "If you only remember the three things rethinkdb," We say, "remember these." "People don't remember anything else on the slide, but at the end they did remember three points.

If you remember anything about this article, I want you to remember these three points:

• Select a large market, but make a product for a specific user.

• Learn to know your lost talents.

• To read economics systematically. It will make you faster and better.

Compiled from: http://www.defstartup.org/2017/01/18/why-rethinkdb-failed.html

Compiling: Open source China

Http://www.oschina.net/news/81180/rethinkdb-why-we-failed

Open source project Rethinkdb closed, founder summarizes failure lesson (market positioning error)