RethinkDB Postmortem

In my opinion, you got it backwards. Fewer than 0.1% of software engineers are working on the "social startup of the year", whereas the other 99.9% of developers are working on software where consistency and correctness matter more than availability.

And for most of those developers, atomicity guarantees (the A from ACID) are very important, because without transactions if that one operation fails, before it can be repeated as you say, the system also has to rewind the previous operations that succeeded in order to leave the data in a consistent state and implementing this rewind by yourself is extremely challenging (take a look at the Command pattern sometime for a possible strategy).

Or in other words, most developers need atomic guarantees / transactions as well and if the DB doesn't support transactions with the needed granularity for your app, it's easier to change the DB than implementing it yourself, which is why RDBMSs are still more popular than NoSQL systems, because they are more general purpose and made the right compromises for a majority of use-cases.

Yes, worse is better.

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

The problem with MySQL early on was exactly its feature set. Fifteen years ago it was very far behind Postgres yet much more popular. I do not think it even had InnoDB/transactions at that point (or almost no one used it), definitely did not have user defined functions, procedures and many other features developers took for granted in commercial RDBMS.

Like MongoDB, it was popular mostly for being popular, which is a nice gig if you can get it.

I agree for most part but what is important is productivity.

Java ecosystem is just toxic waste full of abandoned projects, over engineering everything, crashing build because everyone use arbitrary versioning schemes, ring-fences code with licenses/patents and developers with C++ mindset.

Node.js is maybe build on top hack on top of hack. With some ugly code, lack of any abstraction, lack of sensible std library, debugging capabilities, minimal editors support and finally with package manager that cannot be trusted.

But I can build CRUD API working with any database under 1h in node.js. Where In Java I need to start with learning all maven quirks, write pointless JSON mappers and learn stupid annotations that every library introduce.

I think the basic problem here is a lot of technology is heavily hyped and in use but 'not in use'. People are learning about them, trying them, even trying or using them in small internal deployments but are not buying them or supporting them in any way.

Those who take them into production are startups who are themselves trying to succeed or large companies who have tons of engineering talent who can create the product if need be but since its open source and available they use the open source version but they don't value it. Think the recent article where Github, forget supporting Redis has not even reached out to the developer once to thank him.

The demands of the community are high touch, even one or two weeks without commits and people start getting restive and raise 'alarms' on github and here. If there is potential value that you are still figuring out how to capture and a lot of attention you could end up expending time dealing with the politics of a fork. On the other end purchase decisions of most companies brings a whole new sets of requirements from internal processes, approvals, policies to decision makers and most open source companies do not have the resources or experience initially to manage the expensive and high touch sales and marketing process that most companies buying technology require.

If you have funding the pressure is even higher. There is a missing piece of how to translate support and usage of open source software for commerical reasons into some sort of revenue even minimal without friction. I think there should be a spotlight on companies using open source and their support and contribution back, and not just acquiring projects or hiring their developers which is an 'influence play'.