RethinkDB is one of the developer tools that we at Stripe most looked up to.[1] The team had so many good ideas and rigorous, creative thoughts around what a database could be and how it should work. I'm really bummed that it didn't work out for them and have enormous respect for the tenacity of their effort.
I'm also excited to have them join us here at Stripe. As we've gotten to know Mike, Slava, and the other Rethinks -- and shared some of our plans with them and gotten their feedback -- we've become pretty convinced that we can build some excellent products together in the future. I'm looking forward to learning from all of them.
As a user and supporter of RethinkDB I hope (and expect!) that the engineering team joining Stripe is a sign that Stripe will be able to take part in further development of the product.
On a sidenote, for people unfamiliar with RethinkDB, this episode of The Changelog with Slava explains some of the history and choices behind RethinkDB ; I found it really interesting. https://changelog.com/114/
The team at Stripe has been absolutely phenomenal throughout this process, they've gone above and beyond in finding high-impact projects for our team. We're brainstorming together how to transition RethinkDB to a self-sustaining open-source project, and Stripe is super-supportive of that too. If there is a way for RethinkDB to live on, we'll find it!
I can't describe how sad I am over this. RethinkDB is not just excellent db, but it is yardstick on how future db's should look like. What you accomplished there is excellent balance on features, great ui. We really need this project to go on, even if slower.
We use RethinkDB at CertSimple. It's always been a great DB with safe defaults, excellent documentation and it's always just worked. Trickier ReQL queries are intuitive. It deserved wider support than what it got.
It's depressing that a half-baked constantly problematic effort like MongoDB wins while this gets neglected. Unfortunately we still live in a world where marketing beats merit.
It's always like this. Just look at Windows; if people cared about quality, no one would be complaining about Windows 10 giving them grief because Microsoft would be out of business or relegated to some business software niche, and we'd all be running some kind of Unix variant or maybe some descendant of BeOS or OS/2.
That is very good to hear. We just ported our backend to use it after evaluating many other options including managed databases.
It's really a top quality piece of software in every respect, combining much of what's good about nosql with relational features and robustness. The ease of clustering across data centers is just phenomenal.
Would still recommend it in spite of this bit of uncertainty.
It's licensed under the Affero GPLv3, but I don't think AGPL license requires you to open source your code, if you're just using ReQL (the API/interface for RethinkDB).
GPL/AGPL requires you to share your code if you statically (or dynamically) link (which is a C language family concept) to GPL code, but I don't know if calling an API is considered "linking".
I don't think most companies really make any contributions or modifications to the databases they use that they absolutely do not want to share back to the community.
(If using ReQL constitutes "linking" under AGPLv3, then that's a very serious matter. Perhaps re-licensing under LGPLv3 would make sense then.)
But overall, I think it's fair that they used AGPL. I especially like that they opted for the Affero version, since companies that do make useful changes can't just hold onto it , and not share it back.
I've worked in a project that used some AGPL component. There were some many doubts on what should be open-sourced/which licenses were possible that we dropped that component and invested or time modification another one.
After some while, that component changed its licensing model. It was too late.
The GPL is of course completely commerce-friendly, as it permits anyone to resell the original or modifications to it. What you're asking for is a license friendly to proprietary software[1].
Why on earth would they want to enable someone to close his modifications to RethinkDB? How does that make the world a better place? How does that encourage the growth of RethinkDB (vice the proliferation of closed, proprietary forks of RethinkDB)?
[1] Which is to say, user-hostile software. Users should be free to use, modify & distribute software.
Proprietary software is not by definition "user-hostile," and hyperbole like this does much more harm than good to people like me who would like to see more open source and less proprietary software in the world simply as a matter of principle.
I can see why you're sometimes labeled as "fanatics" and "zealots". You speak in religious-like absolute terms and use circular logic to "prove" you're correct. The GPL's biggest enemy are its most ardent supporters. Truly.
I disagree. Most of those are things that most users don't give a damn about in most cases (because they're meaningless unless you have certain unusual skills), which means they don't make for a sensible definition of "hostile".
Do pirate bay support your statement or proof that it is wrong? Maybe it just that "most users don't give a damn" about copyright, and as such don't care if what they do is legal or illegal with current copyright laws. In order to care about copyright licenses, first users need to care about what happens when they don't follow it.
So you care more about having the entire pie, than about how much pie you have?
If you have a license that "permits" commercial sales in a way that by design makes most business models completely unfeasible... guess what? You'll only get contributions from those with one of the handful of blessed business models. Which will work or not depending on what sorts of businesses models your project is suited for.
Copyleft works fine for things like the kernel that are complementary to tons of different expensive things and nobody cares about otherwise. Permissive works well for Postgres.
At the same time, you're arguing that you should be able to take the work they've done, add to it, but not give back, despite having received a HUGE base to start with.
I secretly (not 'secret' anymore I guess) and irrationally trust Stripe to do good on RethinkDB.
Also, TIL: Slava is defmarco. Yeah defmarco, that's how I read it for a long time. I especially love this piece from defmarcohttp://www.defmacro.org/ramblings/fp.html
I believe the RethinkDB team will be a great fit for Stripe. RethinkDB was literally a pleasure to work with. As someone who has had to endure the pain of setting up a production mongo environment, I was thrilled to see how easy RethinkDB was to provision and then configure (all in their beautiful dashboard).
I see a lot of similarities between Stripe's offering and RethinkDB, making a once painful process into one that is actually looked forward to when building a new product. I'm glad Stripe will have even more engineering firepower as they continue to succeed.
Sad that RethinkDB(.com) is no more, but happy they found a great company to join!
Patrick, I am curious why Stripe didn't just acquire RethinkDB completely? Seems like you could have gotten a bargain. Their investors get some money back, you'd get their excellent intellectual property, and finally the entire functioning RethinkDB team joins Stripe. Win-win right?
Just a hypothetical - if you actually own the IP, you may be able to release future versions under non-free licenses. However I don't see Stripe in the premium-DB business.
yeah. RethinkDB is AGPL, which means that some people cannot use it (e.g. http://www.theregister.co.uk/2011/03/31/google_on_open_sourc...). While a very well grounded interpretation says that merely using the AGPL'd service via a public API doesn't force you to release the clients, some companies would prefer buying a commercial license rather than facing the legal risk.
TL;DR: it's not always "them", there are also those working for "them", who might have no say in the matter.
cannot resist to reply to nitpicks :-)
counterexample: let's imagine I'm an employee of a company which has a policy that forbids me from using any AGPL software for work and it also forbids to install said software on my corporate laptop at all (even if it was for personal evaluation or toy projects) or else, if caught, I might incur in disciplinary action, who knows, possibly termination.
I guess that in this case you'll agree with me that the statement "some people cannot use it" is not quite false and especially not completely false, in that , yes, I could use it (as in no physical law forbids me), and even if you might say that it's me who freely chooses to not use it in order to avoid the repercussions I don't really think I have a choice here, do I?
This is an extremely pedantic definition of "some people". As employees of the company doing work on their corporate laptop they can't do it, but that is because the company won't do it, and they are employees of the company.
Also: you shouldn't be using your company laptop for persona projects anyway... get your own laptop :/. So, likewise: "people who by premise are already doing something sketchy because they can't afford their own laptop and are pretending to borrow one under employment terms" is just an awkward place to start to define a reasonable, as opposed to pedantic, definition of "people".
A lot has been told about those cool companies that hire creative people that love to play with technology. A lot has been said about how some weekend projects have turned up in useful things to be used within the company, sometimes even major projects.
Such a passionate developer however might find himself in a situation where she's not allowed to use some tool X because of a restriction put up by his employer.
That restriction might be a minor annoyance, e.g. raise the barrier to entry because "doh, I need to go and grab my personal laptop for that? nah, let me use something else". Or it might be a deal breaker: I need to get some job done, I'd like to play with tool Y, use it to get the job done and learn new thins while doing it.
This kind of people, those passionate developers, will complain about that.
They will complain to their employee for putting up such a restriction (and you'll usually not hear about those complains here).
But they will also complain about why the tool Y has chosen a license that his employer find so problematic.
These people will not just stop complaining just because they shouldn't be wanting to play with things in the first place. That's what they do, and that's often why they are good at doing things.
People do complain when they have too many rules that hinder their ability to do stuff effectively. I do see that happening, quite a lot; and I can understand why and relate to it.
Do they have the right to complain? Well, that's another story.
If the tool is closed source and they don't want to buy a license, then sure they can complain but they will just shrug it off as "that's the way it is" and move on.
I believe that things start to be more blurred when you have an open-source tool, which suddenly you cannot use (I'm not saying extend and sell commercially as closed source!) just because of FUD around licensing.
That's a nonsense definition. In general language it's perfectly reasonable to say things like "vegans can't each chicken". Responding "FALSE! They can, but they choose not too!" doesn't add anything.
No, if I'm working at a company that has a blanket policy against using any (A)GPL software, then I can't use it.
What the lawyers decide in a company that has 10k+ employees has nothing to do with the fears of anyone but the lawyers and the top management. Everyone else is just following the rules.
Ummm...no. Won't implies you have a choice. Can't implies that it's not an option.
Working for one of those large companies, you simply don't have an option.
And the people without choices vastly outnumber the people who do have choices.
Frankly, most developers are probably happy using whatever code, under whatever license, that's available. It's the people who run the business who typically make the decisions about what's OK and what's not.
So it's developers who are punished by GPL, by and large, because many can't use the code. It's not helping those developers, and nothing zealots say or do will convince the legal department at those companies that they should change their position on (A)GPL.
Sounds as good news for any competitor (if your company has any). The competitor can use (A)GPL when its suitable and get products out earlier with lowest costs. If development time is cheaper than doing per-case evaluation of a license, then something must be horrible wrong.
>Sounds as good news for any competitor (if your company has any).
Actually thinking of Amazon.com. They have competitors, sure. But they also have the budget to write their own entire stacks internally when the license doesn't fit. And it's not like their decision to avoid GPL software is hurting them in the market in any relevant way.
When something is MIT licensed, they'll use it, and they can and do contribute changes upstream. GPLv2 code requires serious hoop jumping to use, and GPLv3 software is verboten (the patent clause can't be adhered to by large companies with cross-licensing agreements: Many of these licensed patents can't be sublicensed, and so they can't be in compliance with the license at all).
So all GPL does is prevent companies from using and supporting the software. For every instance of an MIT project that ends up modified in proprietary code there are probably 100 that either use it verbatim or contribute changes back upstream. It just makes sense so that you don't need to keep maintaining an increasingly divergent fork.
When you are large enough and entrenched enough, you can do suboptimal decision and still win the race in both market share and revenue. IE and Microsoft comes in mind, and it took major failures and long time before competitor started to gain ground.
And it would explain why say a gaming company can't have such rigid policies. Preventing that a game get delayed is worth both lawyer time and, in the case that a license directly conflict with the business model, send mail to the author and asking for an exception. For example, I recall that LGPLv3 which has the same patent clause you describe as "clause can't be adhered to by large companies" is used by blizzard in starcraft 2. Blizzard is not Google in size, but they are not exactly a street vendor. One might also ask if they have much need to protect patents about xml parsing, or fonts, or what ever specialized functions those numerous library do that blizzard use to build a game. The only thing they don't use is copyleft, as their core business model is designed around restricting copying in order to limit supply when selling copies.
Per case evaluation make sense when your product is time sensitive and when there is a lot of competition. A game from Blizzard is almost treated the same by the market as a game by a indie studio (keyword: almost), and a such can't rely on market share to protect them. A bad, delayed, and rushed game is still bad and won't sell regardless of who made it (To name an example, the last batman game). They must be agile, which mean religious thinking about software licenses must be thrown out and per-case evaluation be added to the process. If a library can be use within the business model, saves time and money, and is not your core ingredient in making your game stand out, its almost always a good idea to use it.
It's the Google/Amazon/IBM/Apple size where you end up with endemic cross-licensing patent agreements. That's where they can't adhere to it: They have a license to a thousand patents that protects them from being sued, but they don't have the right to sublicense those same patents. (L)GPLv3 requires they sublicense any patents they have to anyone who's sued, IIRC, so since they can't, they lose the ability to distribute their software.
I'd be somewhat surprised if Blizzard were a party to such an agreement. They might be party to a "patent-troll-don't-sue-me" agreement, I guess? No idea. But if they are, depending on the terms of their agreement, someone could potentially sue them over it based on LGPLv3 terms.
I'm not planning to, so I haven't done the research, to be sure. The risk scenario that comes to mind is a stretch, but say I buy a Blizzard game with LGPLv3 code in it, which grants me the right to be protected against patent lawsuits relevant to that code, and then I ship my own game that uses the same LGPLv3 code -- and I'm sued by a patent troll over a patent that Blizzard has licensed through some agreement. Guess what? I can now demand that Blizzard protect my use of the same LGPLv3 code by sublicensing me that patent. Which they (probably) don't have the right to do. So they either pay for my license or they have to stop distributing their LGPLv3 code.
For Amazon, who distribute tons of code for people to use in AWS, and the fact that they're a much larger, more collectable company, the scenario is proportionally worse.
It's all beside the point, though: In no case is it the line-level developer making the call, it's someone in management. Not everyone can (or even wants to) work for Blizzard or equivalent.
In particular, not everyone wants to work at literally half the compensation or less just so they can have full software freedom, whatever that means. The Google/Amazon/Apple compensation can be that much better than start-ups for top developers. I didn't realize this myself until I got a job at one of them.
And I'd love to be able to use RethinkDB where ever I end up next, without having to worry about whether the company legal department has a problem with (A|L)GPLv3. It's a battle I wouldn't even bother taking on in most cases; too much work when I could use something else and get back to doing real work.
The copyrights and patents are already covered under the licenses they used (AGPL v3 and Apache v2). A search for RETHINKDB on the USPTO trademark search engine turns up no results.
Coming from a failed startup myself, there is probably a bit of debt associated with the company at this point. In our final throws of life, we raised additional capital (angel/VC/etc) via convertible note to sustain the business a bit further. This in addition to back rent, unpaid bills, etc, leaves quite a pile of financial liability that any acquiring company would likely assume. Easier to let the company die and hire the staff as a separate operation.
The comments section here can be brutal and God knows I've been responsible for some of it, which makes seeing comments like this all the more heartening.
It's great to hear that the Rethink crew will have a home at Stripe. Seems like the perfect fit. I hope you consider putting resources behind the project. We've absolutely loved using at Lumi.
"we can build some excellent products together in the future."
So in other words you're not going to continue to work on Horizon and Rethink, or at least if you do they are secondary priorities? Ugh.
Slava did the right thing; his first responsibility is to his employees, not his users, but this really sucks for us users.
For us, it would probably have been better to shut down abruptly. The community would have scrambled. Some employees would find work in companies that used RethinkDB, and maintenance would have continued the same way that Apache was developed ~20 years ago. Some would have grabbed support contracts from users. And some would have moved on.
I'm also excited to have them join us here at Stripe. As we've gotten to know Mike, Slava, and the other Rethinks -- and shared some of our plans with them and gotten their feedback -- we've become pretty convinced that we can build some excellent products together in the future. I'm looking forward to learning from all of them.
[1] (And, for me, even before Stripe -- I started learning Haskell with Slava's Lisp-interpreter-in-Haskell tutorial back in 2006... http://www.defmacro.org/ramblings/lisp-in-haskell.html)