I like the analysis, definitely some points I didn't consider.
The Java points are certainly fair enough, although I'm unsure how much of the target market actually uses Java. Java as the author states, is number 1 in enterprise, a space where moving to a new database can take a great deal of research and A/B testing.
I feel if the Java community was interested in RethinkDB, a few community tools would have popped up to do the tasks the author discusses.
I certainly disagree with the author regarding point 5. Change feeds were one of the substantial competitive advantages it had over other databases. Rethinkdb was trying to innovate, and produce a unique and beneficial product rather than build another NoSQL product.
Interesting that the reference that the author used was their own company - I find it difficult to believe Pojo and Java 8 library stopped it taking the Java world by storm. I see a few java clients back in 2013 - that appear to have very little interest from the Java community.
I know the founders of RethinkDB and have had drinks/meals with them in the past. They're smart people that mean well and I absolutely believe they did everything they thought possible to make it a viable business, so the last paragraph comes across as a bit snippy to me.
I do think the author means well though, and is trying to construct a rationale. As a product guy who worked for several database startups, the delay on delivering a Java driver does seem a bit puzzling but some/most of the other points can easily be explained by those two startups devils, prioritization and product design. Does a MongoDB user look for automatic failover before converting to Rethink? Probably! Would an advanced user, perhaps leery of the pitfalls of automatic failovers prefer a more manual approach? Likely! Should Rethink have focused on the former or the latter group of users? Who's to say? I feel similarly conflicted about points #2–5.
The article does make a good point overarching though. In times of failure it's easy for engineers to blame external factors like market or marketing rather than look inward, and it could be that the product or engineering was wrong. Failures at that stage are essentially Product-Market fit failures, and they usually involve a bit of both Product and Market(ing). I'm just not sure the points listed bear that out but would love to hear more, possibly from the author or Slava & Mike @ Rethink?
2 comments
[ 3.1 ms ] story [ 14.5 ms ] threadThe Java points are certainly fair enough, although I'm unsure how much of the target market actually uses Java. Java as the author states, is number 1 in enterprise, a space where moving to a new database can take a great deal of research and A/B testing.
I feel if the Java community was interested in RethinkDB, a few community tools would have popped up to do the tasks the author discusses.
I certainly disagree with the author regarding point 5. Change feeds were one of the substantial competitive advantages it had over other databases. Rethinkdb was trying to innovate, and produce a unique and beneficial product rather than build another NoSQL product.
Interesting that the reference that the author used was their own company - I find it difficult to believe Pojo and Java 8 library stopped it taking the Java world by storm. I see a few java clients back in 2013 - that appear to have very little interest from the Java community.
I do think the author means well though, and is trying to construct a rationale. As a product guy who worked for several database startups, the delay on delivering a Java driver does seem a bit puzzling but some/most of the other points can easily be explained by those two startups devils, prioritization and product design. Does a MongoDB user look for automatic failover before converting to Rethink? Probably! Would an advanced user, perhaps leery of the pitfalls of automatic failovers prefer a more manual approach? Likely! Should Rethink have focused on the former or the latter group of users? Who's to say? I feel similarly conflicted about points #2–5.
The article does make a good point overarching though. In times of failure it's easy for engineers to blame external factors like market or marketing rather than look inward, and it could be that the product or engineering was wrong. Failures at that stage are essentially Product-Market fit failures, and they usually involve a bit of both Product and Market(ing). I'm just not sure the points listed bear that out but would love to hear more, possibly from the author or Slava & Mike @ Rethink?