Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save coffeemug/af8dcb6f653a7f9c31daedbbdaa3402c to your computer and use it in GitHub Desktop.
Save coffeemug/af8dcb6f653a7f9c31daedbbdaa3402c to your computer and use it in GitHub Desktop.
- Inexplicable perversity of human nature.
- The clever machinations of MongoDB's marketing people.
- The AGPL license killed it.
- We spent too long development before monetizing.
- Bad performance.
- Numeric types limited to a 64-bit `float`.
- Great product, but didn't/couldn't translate to revenue.
- Bad business model.
- Failure in timezones/timestamp nuances.
- Document databases are a bad idea.
- Investment dried up due to noisy market.
- Did not solve problem companies using databases and having money
  need solved.
- NoSQL hype died out.
- No Java driver / automatic failover for too long.
- No cloud service.
- Trying to ship a cloud service.
- Failure of capitalism.
- MongoDB has done a way better job at SEO.
- Realtime technology was too early.
- Didn't build good sales/marketing teams.
- Bad name.
- The product was too good.
- Didn't have a Heroku addon.
@acouch
Copy link

acouch commented Jan 20, 2017

These are reasons why RethinkDB is not as popular as Mongo. None of this addresses the actual funding reasons why it failed.

@martinvahi
Copy link

martinvahi commented Apr 12, 2017

I'm no marketing guru and I have a lot to learn about economy myself,
but I just finished reading the

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

and wanted to offer an idea that the very same
product group
(cars, umbrellas, developer tools, shoes, bubble gum)
can have very different target audiences, which form totally different
markets with totally different prices and competition.
For example,
a bubble gum that is pink and smells like strawberry, targets probably
a very different audience than a bubble gum that contains nicotine and
tastes like mint. And yes, the market for the pink strawberry bubblegum
is probably much greater than the market for nicotine bubble gum, but
since those 2 "bubble gum markets" are different markets, then it is
perfectly OK for the nicotine bubble gum to cost at least 3 times as much
as the pink strawberry bubble gum costs.

The same with "developer tools" market: corporate software development
is a totally different market from the market, where small IT-companies and
freelancers attend. At first glance "it-is-all-one-huge-software-development"
and CODE IS CODE, but actually the people, who do the development, are
very different, the money flows are very different, the acquisitions are decided
very differently. There's also a huge difference, whether the megacorporation
creates something for its own, internal, in-house, use, or whether the megacorporation
is some government contractor, doing the software development as part of
a contract to its client, some government.

May be I'm mistaken, but my 2017_04 understanding is that the main beneficiaries
of developer tools are developers, who can use them to get their projects done
with less time and smaller amount of mistakes. Therefore it's also the developers, who
should pay for the developer tools. Since no smart developer wants to lock itself
in to the whims of some component manufacturer, "libraries" can not be licensed to
smart developers by offering some closed source license or any license that limits
wild copying and reuse in whatever manner. A database engine is essentially
a library that offers persistence, hopefully in some smart and optimized manner that
copes with the various real life issues like scaling, backups, connection failures, etc.
As of 2017_04 it seems to me that models for "financing" the development
of developer tools are:

  • Pay to some Linux_Foundation/Apache_Foundation for the
    development work and benefit from the pooling of the money or build it from scratch
    Yourself and fail to deliver a bug-free and optimized product, just like
    Microsoft fails all the time.

  • Get the money by doing something for the end users, by working on client projects,
    and optimize one's own development work by creating reusable components that
    can be reused at different client projects. To get the legalities out of the way and
    to get free testing and suggestions, make the reusable components that
    do not form the core of the differentiation available
    to everybody, including one's own competitors
    , because it is exactly the
    competitors, who have somewhat similar tasks and who then have the
    motivation and resource to properly test the component and to come up
    with clever improvements. (It's basically the case, where all parties, who
    compete at some market, are motivated to minimize the cost of the
    non-differentiating work, a bit like a mall, where different merchants
    compete, but at the same time they jointly pay to the security guards
    and cleaners to minimize their costs.)
    Examples of such projects are the
    Free Pascal/Lazarus/MSEide + MSEgui and other projects that are entirely maintained by
    a set of freelancers or lonely wolves, who develop the tools to get their other,
    paid, work done.

  • The various research grant based approaches, like the OpenAI
    and university related academic projects are. However, those projects have the
    same problems that start-ups have: when the grant money runs out,
    the project might be in such an incomplete state that the only deliverable is
    an academic paper, which describes the lessons learned, or the project is
    not completed to a production quality or a properly developed project is
    left to bitrot. I even have a 2014_01 blog post titled:
    About Software Development in Companies, Communities and the Academia
    (It's a very acute topic for me, so obviously I have been giving it some thought for YEARS!)

  • If I understand correctly, the
    Eclipse Project was financed from the fear of the IBM's
    senior executives that the IBM will be left out of the market. The Google Android project
    was started from the fear that Google as a search engine will be left out of modern
    mobile phones, which was at the era were the
    big players were the Palm, the Nokia and the Microsoft Windows Phone.
    The giant, Nokia, was a disgustingly closed and snobbish company and the Google's
    fear was, at that time, very well justified.

Sometimes there are also some hybrids, like the Linux Torvalds's Linux and Tucker Taft's ParaSail and the Yukihiro Matsumoto's Ruby are, which start as a lonely wolf's hobby-project and then it gets picked up buy some group of people, who need it for either a hobby or for educational purposes or for work and then at some point some company basically gives the core developers and founders a salary based development grant. The LLVM is a kind of a hybrid project in a sense that in stead of being founded by a lonely wolf the compiler project was picked up by BigMoney (Apple) after the project lived as a grant based academic project.

As of 2017_04 I am really not aware of any technically successful, open source, long-term projects, where the more sophisticated version of Banksters, generally called as "venture capitalists", had given a project a life. In that sense, it's a very nice thing that the founding company behind the RethinkDB failed, because now the financing model of the RethinkDB development can be honestly fixed. I suspect that the most likely scenario is some scheme, where someone, who already has real costs (read: the party spends money) sees the RethinkDB as a way to reduce costs, just like Linux saved Google from buying Microsoft Windows Licenses for all of its thousands of servers at its datacenters.

I like the idea that
HISTORY IS FOR LEARNING, FOR LIVING A SMARTER LIFE IN THE PRESENCE AND IN THE FUTURE,
but interestingly hardly anybody has written
The Mythical Man-Month
about the early 21. century and the 90'ties. Nor have I noticed that there would be
a comprehensive overview, a HISTORY BOOK, about software projects.
There are many books about the history of war, which king killed what other
king, but even the war history books are kind of primitive and dull, because
they mostly lack analytical, war simulation based, game theoretical, resource planning based,
descriptions of the scenarios. It would be awesome, if history were taught by telling:
here are the findings of archaeologists, here is the collection of ancient, digital, texts,
in their original, extinct, language: CALCULATE, WHAT MIGHT HAVE HAPPENED AND
GIVE A PROBABILITY ESTIMATION TO THE CALCULATED TURN OF EVENTS!

Anyway, thank You for reading.
I hope that I was able to write at least something useful :-)

@Alex2357
Copy link

Alex2357 commented Feb 20, 2018

HI,
You mentioned

The clever machinations of MongoDB's marketing people.

I wonder, what machinations do you mean?

@vap0rtranz
Copy link

vap0rtranz commented Jul 11, 2018

Just read Slava's explanation [0] and the 2nd to last reason on this list makes the most sense.

"The product was too good."

Bingo. Engineering pitfall.

I was part of VC startup, not as a founder but 2 years in, engineering built 1 product, legal & biz folks did it on the opensource core model (80% OSS/20% closed), and -- big point -- we had a powerhouse of sales, marketing, and partnerships. That big point worked for our little startup if you count getting acquired a success (because a 35% return to our VCs should be considered as a success). Whether acquired/sold or going big, it seems Slava's essay echoes back to the lack of a sales, marketing, and partnership group early on at RethinkDB. He admits to focusing on the engineering for 3 years! That's a lot of cash to burn with little/no revenue even for Dark Startups.

Engineers have this idea that if you build it they will come. Ok, but how do they know to come?! Especially if you're 30 guys coding away all hours of the night, with the occasional Meetup pizza, and the only folks seeing your hard work are fellow engineers following your git commits? Followers of Github repos tend to not pay for software. :) So the point is nobody with a checkbook will know.

[0] http://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment