rethinkdb-failure-reasons-according-to-hn.md

- 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.

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

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 :-)