RethinkDB, SageMath, Andreessen-Horowitz, Basecamp and Open Source Software

* 100% open source models: Why 100% open source everything? What's the real goal, and what's a slogan? Even Mozilla hides a lot. Open what you can and what is really important to you, and if you really want it to be everything, you can do that on a defensible delay. (We're starting with our non-differentiating framework layers, and now that we're starting on our next layer of differentiating tech, are considering how to open the previously differentiating stuff.) If the choice is slow open growth vs massive partially-open growth, the total amount of open source is actually SMALLER in the 100% open approach. Likewise, if the choice is death over partial open source, not dying means you can do more open work.

* Use of venture capital: The risk of going on the treadmill of always needing the next round is real -- we went slooow on spending ours to avoid that. It's not inherently a bad idea though: companies have successfully bought their way into success. Pay enough great execs for enough time, and cheapen the cost of product enough to avoid competition, and something real will pop out. HOWEVER, a conservative way to think about it is (A) there is a step function to getting to a real worthwhile & sustainable product, which requires capital (sweat, time, VC, whatever.) And (B) after you get there, and revenue growth gets predictable, it's worth increasing spending more this year to have bigger revenue next year. If you bet wrong, you simply slow hiring and wait for natural revenue growth to catch up (it's math!). This is hard, and if you fail at (A), that means layoffs while you try again. It's not necessarily death -- RethinkDB called it quits instead of going to a skeleton team.

* Risk: For the same reason as above, I actually view not reaching the point of a sustainable product as risky in the short-term, and not reaching a maintainable competitive position risky in the long term (esp. in tech, where the world changes every 2-3 years!) It's worth considering why, if you fail getting to point (A) above with VC, how you'd have succeeded without VC. (Taking VC != going all out on a single marketing & sales blitz)

With that view, what Github and Jupyter are doing is (arguably!) leading to better and more sustainable software than Sage's approach, and leading to more open source code than Sage.

(And more a throwaway: A VC is a buyer of a chunk of your company and needs to turn it into a different sized chunk based on the size of their fund. If they're a big VC, they will only buy it if they see it turning into a $1B+ return. Your job as a company builder is to know what revenue you can get & when; it's weird to approach it as some sort of laissez faire random walk. Likewise, as a salesman to a VC, your job is to show you're selling what they need to buy. Not being aware of what the customer wants is a bad start. Doing my best to understand this stuff is part of my obligations to my team.)

To expand on 3, and what others have said, RethinkDB is solid technology, and is a joy to maintain, and even scale, compared with MongoDB. To those of us that have used it and depend on it, losing it would feel like a step backwards. It really does feel like the good guys have lost, in that respect.

The story isn't over yet, and hopefully it lives on as a popular and well-maintained open source project.

We have proprietary software we sell as well as helping people go closer to the applications. We spend a lot of time on relationships with fortune 2000 vendors with existing channels for distribution.

As the CTO of a startup like this I spend my time on coding, leading an engineering team, and managing partnerships with technology companies that help us sell an integrated solution.

We focus on the fortune 2000. One of the things that concerns me is: "My startup bought a support contract from rethinkdb"

No offense to the founders of either, but usually such things are in the 6 figure category or later and require something larger than what a startup can pay.

Selling a cloud version which is easier to scale with more users and less costly on the engagement side (vs say: high touch enterprise) may have been a problem with the business model.

Other plays in the space (maybe gitlab can comment here) tend to minimize support costs to make it easier to work with smaller entities. This may work for data base companies and I hope this is not interpreted as "what I'm saying works for everyone"

What we're doing by default requires some high touch and what might essentially be touching more sensitive problems with a wider variety of applications.

Where deep learning and databases line up is the wide applicability of problems and data types vs say: source control which I won't comment on here (due to lacking knowledge in the space beyond being a user)

My cofounder and I met slava when we were in YC and I have to say we learned a lot from him. He clearly had experience in the space. This space is definitely hard though. I wish them and their community the best no matter what.

Focusing on the customer base from day 1 here is definitely a must.

One of the distinct things we do (other open source startups do this) is figure out which features belong in an enterprise version and a community version.

You can't be everything to everyone and every feature has a price. Boiling the ocean will kill you here. A lot of the engineering team's job is to figure out ROI for certain kinds of features and what kind of problem the feature solves "community" vs "enterprise". It sounds like the enterprise version started later which is a shame. I can say for us, community feedback has been crucial and quick feedback loops help keep us tied to real problems. There's always a certain ratio of engineering time spend on customer problems vs "core features everyone can use". I think a lot of startups have to measure those trade offs.

I can imagine making an app like that where all mutations go through my server and reads go through Firebase. How would this interact with the offline persistence feature though? I suppose you could allow the client to do some simple mutations like editing text fields. For the mutations that must go through the server, though, perhaps you could do optimistic local updates?