RethinkDB, SageMath, Andreessen-Horowitz, Basecamp and Open Source Software
sagemath.blogspot.com
sagemath.blogspot.com
RethinkDB is amazing software and a real breakthrough. And the audience of deep thinking people who can really leverage the event model is ... limited. Today.
MongoDB is no breakthrough, but there are legions of people who just want to plug something together with PHP or Node. Given what they're doing, it works fine.
I sincerely hope Rethink can turn into a vibrant open source project and I'm willing to donate money to that. Given sufficient time, the world will learn to use it. And until then, it will grant superpowers to people willing to invest a little effort to understand and leverage it.
Mongo was "there" first and generated a lot of hype through sales and marketing. For a while and probably still now, a lot of Hackathons at college campuses are sponsored by Mongo and you can usually get a prize for using Mongo in your project.
Rethink never marketed themselves too much—it was one of those things you found out about in HN or from another dev.
I'm clueless about business stuff so I don't mean to say Rethink should've marketed heavily like Mongo did, but that's definitely a factor. I also think Rethink should've done Horizon earlier and offered paid hosting/deployment for it and Rethink users.
(I work at Firebase)
Btw, as a person who works on Firebase, perhaps you can answer this question that has been bothering me about it. There's no way to model a foreign key relationship that's traversable in both ways without trusting the client application to update both directions, right? Isn't that a bit of a dealbreaker for anything other than a toy app? I would assume if you wanted to make something that's actually reliable, you'd have to run all your mutations through your own personal server instead of letting clients mutate Firebase directly, right?
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?
Instead, your server should listen to the Firebase, rather than have writes go a separate path (which loses lots of useful features). I think the term now is a client-database-server architecture.
it's not actually a problem for 90% of apps. It's usually in the users best interest not to break their relationships in the db. Think chat. Think info services like Pokemon. Cross table transactions are relative minority in the space of useful apps that's can make money. For those more complex domains, you need technical know how, and Firebase is a useful system component in a larger architecture.
I would be surprised to find that 90% of apps don't have this kind of requirement. Pokemon is easy because that data is static.
For analytics I would want stronger guarantees than LISTEN and NOTIFY alone can provide. I explore options for that here: http://btubbs.com/streaming-updates-from-postgres.html
Exactly, they gave it a good go as a company but their burn rate was likely too high/too soon and differentiation insufficient (whether lack of actual novel features and/or communicating advantages in marketing). For example, a polar opposite of something like Couchbase which is used by giant enterprise shops to move away from Memcache and/or CouchDB.
It was also competing in a way Peter Thiel and Paul Graham warn about. Reinventing something without a vital quantum of improvement is like trying to juggle while climbing Half Dome.
I hope Rethink lives on as open source and adds MongoDB support. If they can hustle to encourage more people to try it by selling its obvious advantages, they have a slim but nonzero chance of rebooting.
Next time, gotta find more paying, alpha customers first and then start building. Then, try VC only after being capital-constrained when hiring/expansion/development is a blocker to realizing imminent profit. New category brands and segment-optimized products are riskier but more likely to be able to set up moats with defensible, competitive value.
Don't raise money for an idea, raise money for a business that is capital constrained. VC is only one kind of funding you can try to grow with.
The best source of funding is revenue.
But, from what you're saying it almost sounds like that RethinkDB would be a great companion to MongoDB. And if so, that the company behind MongoDB might be a great custodian for RethinkDB.
Better to just use something like PostgreSQL. Contrary to popular belief PostgreSQL is actually a better document store than MongoDB via it's jsonb type, operators and GIST/GIN indexing.
The company behind MongoDB is a database company so they probably have some sort of affinity and appreciation for a product like RethinkDB, and, they are commercially successful (or at least, it appears to be that way).
Just because, hypothetically, MongoDB could be a custodian for RethinkDB don't mean that all of a sudden RethinkDB becomes MongoDB.
As Paul pointed out, both solutions seem to be two different products covering two different use cases and audiences and from what I can imagine, they might actually complement each other.
But "NoSQL" atleast as it'd defined has been around forever, it predates SQL because everything before then was trying to work out how to store bits on disk as efficiently as possible before relational theory really found it's way into storage systems and revolutionized things by focussing on modelling.
Even putting aside that fact it was a terrible database then, it's a slightly less terrible database now and everything it can do is done better by other databases.
When I started at RethinkDB, it was before changefeeds were a thing. I always thought the "killer feature" was, well, ReQL. It had the qualities of an ORM/DB Builder in your native language of choice. There was a poster on the wall that said "Databases should be indistinguishable from magic"; I always thought that was a perfect pitch to the RethinkDB audience. I understand why they canted toward pitching the realtime aspects first and foremost after changefeeds came about, but I thought it had great power even if you weren't focused on realtime/event-driven aspects, and perhaps that should have been emphasized more.
However, learning to live without transactions takes some rethinking of the approaches taken. It's totally doable but it may not come easy if you're used to transactions in an RDBMS.
Of course in today's distributed multi service multi database world, learning to live without transactions is becoming more and more important anyway.
1. Business model / strategy is as important as the technology. Way too many people believe that all they need to do is build a great product (by all accounts it seems RethinkDB did) and the rest will take care of itself. Enterprise software is a very difficult business and at the moment going through tremendous change and while there is good opportunity it takes much more than good tech.
2. I would put RethinkDB in the "hard tech" category - the category that YC recently said they'd like to fund more of. Given the success of the technology but failure of the company it raises the question of what value YC brings to the table for a hard tech company? Many hard tech companies are very different than the companies that appear to enjoy the most success from YC (e.g. very different than AirBNB, Dropbox,...).
Amen to this!
When I was CTO of my previous company, I always thought of the "product" as the technology we were building.
As CEO of my current one, the "product" is really the business model we are nurturing/shaping. Even when we are creating amazing technology, the business model is the thing that requires the most care and the main driver of whether we succeed or fail - the real product.
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.
RethinkDB's support prices depended on the size and needs of the customer, so were very reasonable for my company.
If I was doing support for startups that weren't paying me very much, I would have to question the return on investment there.
I was trying to say, that startups as customers are a bad idea and that support contracts if you DO have them as a business model should be in that range.
In the case of RethinkDB I wish they had started Horizon much sooner. Having plugins like for Stripe will make Horizon usable in the real world. I certainly like the goal set for Horizon that it be easy to extend a Horizon app by embedding it in a Node app. I just found the lack of step by step tutorial and several examples frustrating.
I've just started learning about business stuff. I've gone to three Seattle Lean Startup events. I've learned a lot. Two key things I've learned that are helping me are make a working engine before raising money so that money is just gas and focus on making something that people pay for.
Being involved in SMC I'm very glad that VC hasn't been taken. I'm not convinced that VC would make things much better.
I'm excited about the success here, but it's extremely atypical. Most open source projects gets tens of dollars a month, barring large sponsors (despite over 100 sponsors, 80% of Evan's funding comes from the top 11 sponsors)
At first glance it looks kinda like Knockout.
Here's an obviously biased (obvious biased since it's from the creator of vue himself), yet pretty good comparison: https://vuejs.org/guide/comparison.html
Vue.set(vm.someObject, 'b', 2)
That said, I feel Vue does offer some things that, say, Angular/Knockout/Ractive don't to offset this, so I could see myself using it in some cases where I would otherwise go for React.
I rather like the documentation, for one, as well as the tooling that offers single-file components (js/css/markup) and plays well with the editors I use (Sublime, Atom).
I've also found that it's often easier for others to learn the angular-like markup compared to learning React.
For example, I know that at least $100k/month is being poured into Ember right now. There is no visible patreon page to point to, because it's all employee salaries. But multiple very-big companies -- in tech, finance, and media -- are using and depending on Ember and are paying their employees and contractors directly to keep making it better.
That estimate is certainly lower than the true number, because I'm only counting the group of people whose time is 100% allocated to Ember. There are a couple orders of magnitude more people who get to allocate some of their paid working time, and that group adds up to quite a lot more money.
That may have taken away from the core development, but may have been a better case than some of the bits they did with Horizon, which does look interesting to say the least.
If the goal is to create a 0-backend firebase like interface why can't this become a module of the database? Not to harp on the project, it seems cool, but I'm genuinely curious what no DBMS bother to try.
However databases are hard and they are a bit like operating systems. They are so important that people expect them to have a long track record of stability, and that they should also be be completely open, or have someone like Oracle behind it.
If it is open and completely free it doesn't make money.
And large support contracts are lucrative with enterprise customers, but they will not buy into a relatively new database product and entrust its crown jewels to it.
Another, probably the most important, element is timing. MongoDB was there first and it made a huge difference. They shipped with really terrible defaults, lost and corrupted people's data. And they are still around. Had RocksDB come at that time, it would have been a different database market today no doubt...
It is really painful to see this because technology is there, people working on it are really smart, it is just this market is fickle.
OSes are a bit like that. Either a multi-billion dollar company like Apple or Microsoft behind it or it is completely open.
Only small companies like IBM and Google who have put hundreds of millions of dollars into it.
If Google tomorrow drops out and doesn't want to contribute to Linux kernel, no big deal. IBM and Redhat will. If those don't want, others will.
While it's still entirely unclear whether and how RethinkDB and Horizon will develop from now on, I have become more hesitant to use a 'relatively new database product' even for my side projects, let alone something 'important'.
This was my first experience using some piece of technology (library, framework, etc.) that suddenly potentially won't survive, and it's probably a good thing that I learned this lesson with a relatively unimportant side project.
Still, it becomes a bit of a fulfilling prophecy: I'm now even less likely to invest in a new database product.
I really hope RethinkDB and Horizon will find a home, because I've really enjoyed working with both.
(Ironically we just ported the new version of our SaaS code base to RethinkDB! We plan to stick with it. It's too nice, and I'm optimistic it'll find an OSS home.)
I'm anxiously awaiting the postmortem, but my sense (albeit from a distance not knowing anyone involved) is that their failure resulted from an underlying assumption that they'd always be able to raise more money as easily and quickly as they had in the past.
As a result they deferred marketing and monetization strategy too long and ran a burn rate that was too high. When the money didn't come they couldn't sustain what IMHO could have otherwise been a fantastic business. If they'd had a little more time to build out Horizon and some of their other efforts, I think they would have made it.
It makes me feel a little bit vindicated for taking the contrarian (to some) position of hugging "default alive" instead of hiring for what feels like the sake of hiring. A good fraction of the Silicon Valley people I talk to (founders, VCs, etc.) have consistently encouraged us to spend more and increase head count, etc., sometimes on the argument that this would make us look better to investors.
Personally I'm concerned more with looking better to customers and surviving. The whole thing just seems bizarre and irrational to me even when I try to put myself in a VC's shoes. If I saw two companies with roughly equivalent stacks and growth and one was burning cash at half the rate of the other, would it make sense for me to choose to invest in the more expensive of the two?
Of course not being in Silicon Valley also helps us keep our burn really low... and I've had people say there's no way we can possibly succeed without being there. So hey, we're either smart or doomed. We'll see.
Hugging default alive means that when our growth goes up in a sustained reliable way, we can hire.
To seen a model try: http://growth.tlb.org
>I do not think it is impossible to build an open source business (I think Wordpress is an example), and I do not need to raise VC.
Is the right market here not everything like A16Z told you? The market for wordpress is crazy large with several blog platforms seeing 100+ million dollar exits and it seems no one who gets in this space fails--clearly the market is large.
I also look at other open source projects that have "made it" and they just seem to be tackling bigger markets than you are. Is there a chance the market of what you're doing just seems big to you because of personal interest in the product? (Not trying to be inflammatory with that comment)
The market may not be large enough and opportunity may not be as fast growing that VCs expect, still it may be possible to build a decent size business with SageMath.
> Have you taken any external funding for SageMath and SMC beyond grants?
For SageMath, all funding is via grants, and I have almost no such grants these days (I used to get grants in the early days). There's a grant in Europe called OpenDreamKit that provides substantial funding right now. There's also one new NSF grant that will provide some funding for free open source textbooks built with lots of example using Sage.
For SageMathCloud, I did a round of Angel investment about a year ago in order to "bootstrap" things, and hopefully give us the time we need to build the business to be profitable. The Angel investors are a small group of people I know from the mathematics world. Right now the company is not profitable, even with a small number of low-paid developers, so it's critical to have this money to make up for the slack until we have more customers.
We can and should do a lot more marketing when the time is right. I hope that time is very soon.
Agree 100% I just wanted to make sure your expectations were realistic based on the what you wrote. I hope the best for you!
So you inadvertently signaled "I'm looking for funding" in VC-speak ;)
In the case of Wordpress, I think a big part of its success is that it is built on the most well-supported technologies on the web: PHP and MySQL.
I'm by no means a great programmer but it was relatively straightforward to migrate a Drupal site with a completely different DB structure to a Wordpress redesign. Both use PHP and MySQL.
In contrast, my built-from-scratch journalling tool that runs on RethinkDB will take a bit more work - all over the place - to work with some other database (probably Postgres, SQLite or MySQL). It's still relatively simple, but less so than the Drupal->Wordpress conversion.
My Horizon app, on the other hand, will basically have to be rewritten if support and development were to stop.
I think it's the exact opposite. Basecamp is mostly open source. Ruby on Rails is basically extracted from the Basecamp application. They've open sourced even their Trix Editor (https://github.com/basecamp/trix).
Edit: capitalization
(1) The founders are extremely nice and thoughtful people, as well as everyone I've ever met from there (seriously, top notch). Seeing someone like Uber with their poor ethical reputation succeed and a company like Rethink close down is disheartening.
(2) It's more ammo for the "open source can never make money" crowd which I think is frustrating for HNers like myself who enjoy the idea of running or working for such a business.
(3) Rethink did things the right way engineering and UX wise and had a great reputation for this compared to, say, MongoDB. So as another commenter noted, "worse is better" is still holding true in 2016.
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.
One example I keep referring back to is postgres. Postgres is soon going to be getting distributed capabilities, and I think it corresponds to the need in having highly available systems.
Now, this was what was missing from postgres all along as postgres already has LISTEN/NOTIFY, so if you slap on a system that can properly replicate and shard it, then what you have is a product that is open source, free and has years of strong engineering to back it up.
Its hard to compete with that.
Some of it is just nicer abstractions (like limit/offset changefeeds, where you get notified if say a high score list changes). But there are a bunch of subtleties in that space that RethinkDB had to solve. Like enabling you to fetch the existing results and receive the new ones without gaps or duplicates. RethinkDB 2.0 didn't have that, but 2.1 added it. They had to iterate many times to improve the changefeed semantics, and to get LISTEN/NOTIFY to the same place you'd have to solve a lot of those same problems.
In the spirit of analyzing your business model, how much of your success has come about because you had access to a subsidized team fixing bugs for you?
> Why do you fund ... companies ... which have no clear (to me) business model?
It's a great question and I used to wonder it myself.
Consider it in the engineering domain: companies get investment to do development. Some may have only an idea, some may have a prototype, some may have a product and need money for growth (these get the highest valuation as they have the lowest risk, but also tend to have the lowest returns). I don't think any of that should surprise anyone.
Well; companies appear in the same distribution of states in the business domain. Some, like Google, have no business model in mind and almost fail because of it. Some have a business model which does't look well baked but the entrepreneurs seem to understand it, so can probably develop it into something worthwhile.
And of course there are there ones where the investors want to know more about the sector. Open Source <insert XXX here> was like that back in the late 90s.
This is also why I am worried about things like CoreOS. Not sure who uses it. I hope their enterprise sales keep them ticking, otherwise they are screwed since they have taken so much funding.
Will support contracts end? Will people run into new problems and be stuck without help when this happens? Just curious to see what happens.
> I wonder what will happen to products like SageMathCloud using RethinkDB now that the company is gone away.
Unlike my first year of using RethinkDB, during the last six months, my RethinkDB cluster has been rock solid stable and I have NOT hit a single noticeable issue. It seems like the last "the devil is in the details" bugs got ironed out a few months ago. So fortunately there is no pressing need to make a decision. My plan is to do what I can to support the open source project, and if it takes up, stick with RethinkDB longterm. If the open source project does not take off within a year, I will probably spend about 2-3 months fulltime (my estimate) to rewrite SMC to use Postgresql and RabbitMQ. Anyway, that's my plan. After this experience, I personally can't imagine rebuilding everything on top of a database that is substantially less proven than Postgresql.
I love engineering as much as anyone else but learning how to actually go to market and create customers is the most important thing if you want to build a company.
Mobile is the most common use case for a real-time DB. They didn't provide good iOS and Android integration. Technically Rethink is superior to Firebase, but Firebase is more successful.
Are you are trying to strike some sort of balance between capitalism and altruism?
His comment about licensing was also interesting:
"At a bare minimum, I think they must switch to a very liberal license (Apache instead of AGPL)"
If it goes closed source, what's the point?
Regarding "If SageMath goes closed source, what's the point?" there's absolutely no possible way SageMath itself could go closed source, since the copyright is spread across over 500 contributors, and SageMath depends on many other GPL licensed libraries. In my opinion, SageMath also has much greater depth and breadth of functionality than Mathematica for many areas related to pure mathematics research, especially coding theory, number theory, algebraic combinatorics, graph theory and group theory. To a mathematics researcher such as me, the functionality of Mathematica for elliptic curves and modular forms (my area) is very basic compared to what is in SageMath.
As for RethinkDB; we loved it, and even wrote an article about it a few weeks ago, outlining how it could be awesomely used with Rails 5 [1]. Having tried to bootstrap a company solely around an open source product ourselves as well[2], we can't help but share their pain here a bit. For instance, and I'm just going on what OP has shared about RethinkDBs business model, we tried to build our business solely on support contracts initially too. That didn't work out great for us.
And it kind of makes sense if you think about it: the support contract is available in case your software is failing during critical operations, yet your main efforts in product improvements are to minimize those chances. So you may have two conflicting interests, and I think you will find yourself having a hard time satisfying both. Through product improvements, you're basically minimizing the probability that such a support contract is needed. That might make it more enticing to only get the contract whenever you actually really need it, and that moment might never come. Especially if you consider how many hoops customers have to jump through to procure something within the enterprise. I can imagine something similar happening for RethinkDB.
This was an important realization for us though: rather than charge for the probability of problems, consider charging for the product's merits instead. As much as it pained us to introduce a closed source premium version of Passenger a few years ago to do this, I can confidently say that it was the best choice we could have made for our open source users as well; it allowed us to have a sustainable income and allowed us to rapidly improve Passenger's open source core alongside the closed source version as well. So even though I commend OPs determination into keeping things strictly open source, I'd encourage him to look into a hybrid option as well. We wouldn't be around here today as a company if we didn't.
Lastly, seeing as OP is a fellow bootstrapper and a fan of Basecamp as well, I think Jason Fried put it best when it comes to VC monies: "if you start out by raising money, you get good at spending money, but if you start without money, you get really good at making money", or something like that :-)
[1] https://blog.phusion.nl/2016/08/04/using-rails-5-actioncable...
[2] https://blog.phusion.nl/2015/10/30/bootstrapping-a-business-...
* 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.)