Hacker News new | comments | show | ask | jobs | submit login
RethinkDB, SageMath, Andreessen-Horowitz, Basecamp and Open Source Software (sagemath.blogspot.com)
331 points by williamstein 138 days ago | hide | past | web | 120 comments | favorite



To understand what happened to RethinkDB, you want to contrast it with MongoDB.

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.


FWIW I found Rethink easier than Mongo, especially the query language. ReQL is actual JavaScript—Mongo's query language always seemed weird to me.

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 admit I don't have a lot of experience with MongoDB, but RethinkDB was really easy to plug into Node. While we didn't support PHP officially, the PHP RethinkDB driver was maintained by RethinkDB's engineering manager, Daniel Mewes, and it looked pretty solid.

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.


In my opinion rethinkdb is super easy to get going and use. The low touch maintenance is what drew me originally.

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.


if "Databases should be indistinguishable from magic" then somehow you should be able to get transactions


You can get transactions, but at a cost. Distributed transactions exist, they're just slow (and network-chatty). RethinkDB decided not to go that direction, I guess.


Disclaimer: I have a bro crush on Ben Horowitz.

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.


You nailed it with this "try VC only after being capital-constrained when hiring/expansion/development is a blocker to realizing imminent profit".

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.


For those not "in the know," what capability is that? Everything I hear implies a focus on ease of use: Easy replication/distribution, JS API, single number type (float64), usefulness when teaching novices, etc.


RethinkDB's niche is allowing a service to listen for changes to a dataset. As in, your Node application could listen for published events by Rethink, rather than your Node application long-polling the dataset for changes. "Real Time" data analytics can then be performed.


I've never done it, but I think it's possible to do this in Postgres as well using LISTEN and NOTIFY. You may want to do all of your database mutations through functions that ultimately call NOTIFY for this to work though. But uh, that's how you'd do it in postgraphql or postgrest anyway.

https://github.com/calebmer/postgraphql

http://postgrest.com/


You can definitely use LISTEN and NOTIFY to watch for changes in Postgres. Here's a presentation I did on that last year, though oriented more towards web apps than analytics. https://www.youtube.com/watch?v=PsorlkAF83s

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


Its other niche is easy to deploy replication and sharding that actually works, actually scales, and does not lose data.


I've never seen that in any db I've worked with. If that's true, that's pretty huge.


It is true. It was NOT true a year ago, but it is now. I pushed it hard, Aphyr pushed it hard, and the RethinkDB team worked very hard addressing every issue we found. That's why RethinkDB failing is so tragic.


Damn, I'm simultaneously excited and sad now. I hope it survives as open source so I can use it for my next project.


Yeah it feels like they died right after getting everything right.


Firebase works like that. The polling of databases is a really obvious limitation of existing databases once you see the alternative.

(I work at Firebase)


Well it's easy to shard when you don't support joins or foreign key constraints.

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?


You can use it as the mobile device connector as clientside auth, push, latency compensation, presense and offline persistence are big features on their own. For sensitive joins, have a server side joiner with administrative privileges. Still, it's work that should be easier I agree. Firebase's strength is not what other DBs can do, but what they cannot.


I'm curious what Firebase users do in real life. Do people realize this is a problem?

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?


The latency compensation through the sdk is optimistic writes. If you shortcut to server, you have to reimplement that so that's not a good solution for many cases. It would confuse the offline persistence too.

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.


As soon as you want to view something through a different direction you run into this problem. Sure, you can embed chat messages into a conversation, but what if you want to look up every message by a particular user?

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.


Viewing all posts by a user is solved with classic denormalization. You maintain a separate index of post by user and do two writes per chat msg. It's a case where a user has no incentive not do the second write so it be fine to implement clientside. If however it was business critical, you would have a server side process listen to all chat messages and write the user to message index with the admin account. That index would essentially be eventually consistent.


[edit: this is an irrelevant remark] RethinkDB supports joins: https://www.rethinkdb.com/docs/table-joins/ "Like many traditional database systems, RethinkDB supports JOIN commands to combine data from multiple tables. In RethinkDB joins are automatically distributed—a join command is automatically sent to the appropriate nodes across the cluster, the relevant data is combined, and the final result is presented to the user."


Rethink joins aren't consistent (in fact, no Rethink multikey transaction guarantees any degree of consistency), so even though the original conversation was about Firebase IMO it is just as applicable to Rethink.


I'm talking about Firebase :P.


I searched and searched, but I couldn't find a download link on Firebase.com. Help?


I think Firebase is a closed source program that can only be used via "the cloud", i.e., via a web application. It's not something you can run yourself. In contrast, RethinkDB+Horizon would have soon provided similar functionality to Firebase, but with the option of self hosting.


Has Firebase been through Aphyr's Jepsen tests?


Seeing as how Aphyr can't deploy his own instances of Firebase to simulate network partitions, I don't think it has.


Pretty much anybody can appreciate that, right? Not just the "deep thinking people"?


Concur. We've been running a small cluster for about a year and we've had the same experience thus far.


isnt that what Realm is trying to do on the mobile side ?


"Worse is Better" triumphs again...


Just going out on a limb here, and I know neither MongoDB or RethinkDB (nor the companies behind them) very well.

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.


That thought fills me with dread. Rethink is well engineered and has a great developer experience. Mongo isn't and doesn't.


All these comments are starting to make me feel stupid. I picked mongo for a side project, and it's been really nice so far. I have a hard time imagining how one would use it for a complicated and/or large schema though. I assume that is just my newness to it.


Don't feel bad for not understanding how to make it work for a big project, it just doesn't. You can try make it work for a big project, but at that point you are just implementing database level code in your application.

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.


Nope, you have it right. Mongo is a lot of fun to play with out of the box. Once you have nontrivial data models, redundancy and load, not so much.


I'm not entirely to sure if I understand your comment, however, what I mean is;

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.


MongoDB was much more breakthrough than this little thing called rethinkdb. Hell, people even create the term NoSQL because of it. Maybe the failure of this project came from this dellusional thinking I keep reading in all posts about their failure.


MongoDB coined the term maybe, along with webscale and a whole bunch of meme.

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.


Several interesting ideas to ponder due to the RethinkDB shutdown.

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


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

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're an open CORE (caps for emphasis) deep tech company YC has funded in the deep learning space.

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.


> " but usually such things are in the 6 figure category or later and require something larger than what a startup can pay."

RethinkDB's support prices depended on the size and needs of the customer, so were very reasonable for my company.


Right but that's likely the crux of the problem "reasonable" might not be enough to build a sustainable business.

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.


The open source project that has really stood out to me in terms of funding is vuejs.org who's funding is almost entirely public at https://www.patreon.com/evanyou

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.


There are much more mature and stable examples to point at for community-supported open source. Successful open source generally doesn't happen because of direct dollar contributions, but because companies that depend on the projects decide to employ the project maintainers, or assign their existing employees to fix & improve critical projects.

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.


> The open source project that has really stood out to me in terms of funding is vuejs.org who's funding is almost entirely public at https://www.patreon.com/evanyou

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)


What differentiates Vue from all the other client rendering libraries out there? (Angular, Polymer, React, Ember, Knockout, etc).

At first glance it looks kinda like Knockout.


It seems like a full framework, easy to start with, yet doesn't feel bloated or confusing (personal opinon).

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


Oh no. This: https://vuejs.org/guide/reactivity.html#Change-Detection-Cav...

    Vue.set(vm.someObject, 'b', 2)
This is exactly the kind of gotchas that drove me away from the likes of Angular, Knockout, and Polymer to the simplicity of "Just re-render everything" that is React.


Yeah, I often use React or a more react-like library because of this reason.

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.


My understanding is that one of its selling points is that it doesn't have to be a full framework. You can use it for views, create components, or use it as a full blown-framework.


Thanks for the link. Interesting. Seems it supports an angular/knockout-like template syntax by default, but allows you to drop down to the virtual dom layer or even use JSX if you want to. Also it has knockout-style computed properties which may be why it outperforms React. This may go nicely with something like RxJS, so maybe I should try it out with Horizon after all.


As I understand it (mostly from hearing Evan on various podcasts), it's essentially the simplicity of Angular 1 from a development perspective, with a React-like architecture.


Plus the computed properties system from knockout. Yeah, it looks like a nice mashup of everything out there.


Vue, like Ember, is not controlled or authored by a large tech corporation. That doesn't make them better or worse, but it's an idea I like.


For me it's that I can easily get work done in it compared to React.


There seem to be a lot of "thin-server" type frameworks that are meant to bridge between the database and client, typically injecting basic authentication and user management.

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.


I think they also could of, as a flat fee structure, with listed consulting fee rates, could have done what compose.io does just for RethinkDB, as well as a SaaS model for cloud-ready instances on a handful of popular cloud platforms.

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.


Could have.


It seems new users and people who saw the ease of querying, distribution, good docs, solid architecture jumped on board. Lots of HN articles were written. The technology is really solid. Come to think of it, don't recall seeing a single negative RocksDB article on HN, ever.

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.


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

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.


Interesting that you make the comparison to operating systems, since Linux is open and completely free and doesn't have a big company behind it. (Granted, I think the big difference is that Linux doesn't have as many competitors as exist for DBs today.)


> Linux is open and completely free and doesn't have a big company behind it

Only small companies like IBM and Google who have put hundreds of millions of dollars into it.


The important part is it doesn't have "a" big company behind it. Contrast with Android. It is free and open and Amazon and others have forked it and used it. But the situation is not the same.

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.


It is an "or" thing. It can be completely free and open like PostgreSQL or it should have Oracle behind it.

OSes are a bit like that. Either a multi-billion dollar company like Apple or Microsoft behind it or it is completely open.


I'm confused, where does RocksDB come into this? Typo?


Oh sorry, yap, was thinking about RethinkDB.


I'm watching this very closely since I am a founder of another OSS-based company doing something very hard and trying to monetize via things like services, support, etc.

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


I'm a long ways from being a VC, but I see one reason they might prefer the larger, higher-burn-rate company. I think one of the hard jobs for a VC-funded startup is growing really fast (to become big enough to be worth-while when the VCs cash out). The company with more head count may have a head-start on that growth (assuming they actually hired the right people). So if you're a VC looking to place a bet on a company becoming huge enough to offset all your other failed bets, a company that's being very cautious about growth might not be what you're looking for.


Cautious about hiring and spending, not growth. That is pretty decent, though we are working on ways to increase.

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 think Basecamp itself is mostly closed source, so they may have an advantage in building a business.

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


That's very cool that Basecamp is mostly open source. I really appreciate their leadership and the example they set.


The difference is that the stuff they've opened source is not stuff they're directly in the business of selling; this is quite different than trying to sell support or enterprise versions of an open source product.


>They were also worried about how small the total market cap

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


I don't see the market I am targeting as huge, and I agree with you that it is probably easier for Wordpress to succeed than SageMathCloud. I'm perhaps too realistic about the potential market for SageMathCloud, which was a reason why A16Z wasn't interested. If I took VC funding I might not have the option to focus on a smaller market.


Btw nobody clueful goes to meet VC, at lest on the first goaround saying they are looking for funding. Instead they say "were not looking for funding but would be interested to hear your thoughts and open to any introductions you might think appropriate from your network."

So you inadvertently signaled "I'm looking for funding" in VC-speak ;)


>If I took VC funding I might not have the option to focus on a smaller market.

Agree 100% I just wanted to make sure your expectations were realistic based on the what you wrote. I hope the best for you!


Just curious, what kind of resources you have and efforts you make in the area of marketing, business development, and sales of SageMath and SMC? Have you taken any external funding for SageMath and SMC beyond grants?

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.


Regarding SMC, right now we are growing our sales slowly but very consistently. Some universities tried SMC last year, liked it, and are significantly expanding their subscriptions this year. However, our top focus right now is on fixing every bug, implementing key features that users demand, and dealing with issues that become clear from support requests, while working hard behind the scenes to build better technical foundations for growth. We have enough users (e.g., often 500 simultaneous active users, and we hit about 1150 simultaneous running projects this week) to give us a good sense that what we are building provides value and is working (or not). Our business model is freemium, and the conversion rate for students using SMC in courses is high.

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


I don't disagree with your assessment, but I do think 'open source project' is way too vague a concept to really draw conclusions from.

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.


Can someone do an ELI5 explaining the significance of RethinkDB shutting down? I've seen numerous posts about it in the past week, but don't know anything about it more than RethinkDB pushes data in realtime and is scalable.


I think several aspects of it have disturbed the HN community and elsewhere--

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


Excellent post, that sums it up my concerns quite nicely.

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.


I think Rethinkdb although having quite a lot of ambition and delivering on a lot of that ambition just wasn't compelling enough compared to the strides made by competitors.

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.


RethinkDBs changefeeds were a lot more powerful than LISTEN/NOTIFY.

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.


It is true that there were a huge number of subtle issues with exactly what you're describing above (involving changefeed semantics). Many of the RethinkDB bugs I reported (all of which the team fixed!) were related to these edge cases, which I hit when pushing things hard in production. RethinkDB is amazing in a way that is not interesting to an academic researcher, but matters very much for production use. I really, really hope a couple of key people realize this so that RethinkDB can have a second life as an open source project without a company home.


Under a successful support driven model, engineering costs associated with fixing bugs and quirks in the product are amortized across all clients. Fixing a bug for one user fixes it for another, as well as future users. However, if the paid user base is not sufficient to cover support costs, VC money is effectively subsidizing support.

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?


I'm going to defend the issue raised by the (deleted) slide:

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


Open Source is really just a check mark in a list of things required for developer tools these days. It doesn't sell a product by itself. What people pay for these days in primarily service and not the software. If you want to sell software, the only place left is the enterprise. Enterprise sales is really about networking and connecting and not whether a product is technically good.

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.


I think service is crucial. Although there are plenty of strong open source projects out there, that have large communities, they really aren't businesses. I mean, you don't see the PSF trying to sell you some proprietary stuff.


I also very much wonder what CoreOS's business model is.


Same goes for docker. Many monetization options for docker (like the registry) have been duplicated by Google and AWS in their cloud centers. The good news is docker is in bed with Microsoft now which has very deep pockets.


Docker has been baking in more and more of the infrastructure (see all the musings about a potential fork)


I wonder what will happen to products like SageMathCloud using RethinkDB now that the company is gone away.

Will support contracts end? Will people run into new problems and be stuck without help when this happens? Just curious to see what happens.


The answer to "Will support contracts end?" is "Yes". The email they sent me says "Unfortunately the shutdown of the company is abrupt. We won't be able to service your contract but we'll try to provide a list of contractors who might be able to help support you. We're also working hard to find a continuity plan, and to rally the community around the open-source project. We don't know for sure how active RethinkDB development will be going forward, so you should make appropriate preparations."

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


RethinkDB was a case of putting product before sales and marketing, which is how you build a nice project but not a business.

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.


Other successful companies have used this business model.

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.


I believe the thinking was that rethinkdb would always sit behind an API, and if you think about it, its not a bad assumption.


The plumbing around a real time DB is non trivial especially if you are primary a mobile developer.


I'm pretty sure Horizon was meant to fill that niche, though my first look at Firebase had me cringing a little as some of the security model wasn't clear at all, and I am still apprehensive about not having a translation layer between your db and deployed apps that you control.


Horizon was an after thought, too little too late.


Only used Firebase before, why Technically Rethink is superior to Firebase?


I found it too much work to deal with a complex schema in Firebase.


Why didn't rethinkdb offer a paid scaleable hosted solution similar to Amazon RDS? Seems like a straightforward business model.


That's what I'm wondering as well. Having done amazing work to make replication and sharing work the right way, it would've been a straightforward way to make it run reliably (managed) on AWS and such to productize it and make some money.


Agreed... I think compose.io's pricing model left plenty of room to compete directly in that space. I would have loved to have had that option a couple years ago.


William, you never mentioned why you decided against starting to close some of the source.

Are you are trying to strike some sort of balance between capitalism and altruism?


The business model that the SageMath guy failed to consider was the "Money at the End of the Rainbow" model used by Spring, JBoss and MySQL.

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


Could you elaborate on what "Money at the End of the Rainbow" business model is? Thanks!


Acquisition


SageMath is an open-source alternative to Mathematica.

If it goes closed source, what's the point?


The main commercial (but 100% open source) product I'm talking about in the post is SageMathCloud. To clarify, unlike SageMath, SageMathCloud is a web-based realtime collaborative environment for editing LaTeX files, writing code, using Terminals, and distributing and grading homework, which tightly integrates SageMath and Jupyter notebooks.

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.


Sad to see RethinkDB going this way, I think I'm one of its biggest users (see previous comments). Don't really want to switch away from it either


Phusion co-founder here (creators of the Passenger app server); just wanted to chime in and say that this article resonated a lot with our experiences with VCs and our ventures in open source. Even down to the "lifestyle business" remark. Like OP, I'd encourage first-time founders to talk to VCs when starting out just to get an idea of how they perceive your business. Yes, even if you don't plan on raising. You may walk away learning a thing or two :-)

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


There seems to be some common blinders here about open source models, venture capital as a tool, and startup risks:

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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: