Hi, I work at MongoDB, and I'm here to elaborate in answer to your comment.
> I was at the presentation last Thursday, they (OnGres) have fully open sourced both their methodology and their results and had a pretty strict divide between teams designing the benchmarks and teams running the benchmarks.
> MongoDB could create a Pull Request/Merge Request against that repository so we can all judge those results ourselves
The existing, unaltered content of the OnGres repo is all the testimony one needs to know that the OnGres team is incapable of or unwilling to produce a valid test of MongoDB. Open source garbage is still garbage.
I understand the allure of asking for a pull request from our testing team to demonstrate how we obtained the measurements we cited in our retort. It is tempting to see this as a case of well-intentioned scientists, doing their best, honestly asking for peer review. But that view relies on two things that we can not take for granted: 1) that the OnGres team is acting in good faith and will work to correct their errors, fairly declaring MongoDB more performant if they concur with our results; and 2) that such an open back-and-forth will be illuminating to bystanders.
1) We cannot assume that OnGres is acting in good faith when their report so clearly demonstrates that they biased the test against MongoDB. This conversation should start and end with the fact that OnGres used an experimental MongoDB driver to compare against PostgreSQL with a production driver and a dedicated connection pooler in front of it. (What kind of pull request could MongoDB submit to address the use of sysbench, which requires a Lua driver?) They are simply not credible.
2) What would a MongoDB-submitted patch prove? It would certainly print out different numbers, but that alone proves nothing. For those numbers to mean anything, you have to read and understand the code. Anyone capable of understanding why our patch is valid is equally capable of seeing the deep flaws in the code as published, no patch required.
Consider this: if a research group funded by the fossil fuel industry published a report, littered with false statements and methodological errors, claiming that climate change isn't happening, NASA and NOAA aren't obligated to issue full a correction of that report along with their response calling shenanigans.
No, we're not going to get mired in a patch war with demonstrably biased authors over a fundamentally flawed comparison methodology. We have published our own benchmarks demonstrating how to test MongoDB performance, and in a few months, one of our engineers will present her work adapting the industry-standard TPC-C at the VLDB conference.
> their current response is only words and a single table showing unlikely results.
There is nothing unlikely about our obtaining speedups to queries by using indexes that OnGres ignored.
> However I do think the criticism of not tuning MongoDB is valid, however their response is dishonest:
>> with their own heavily tuned PostgreSQL.
> This was explicitly not the case according to OnGres other than the established norms of taking 25% memory for `shared_buffers` etc. No other tuning that is normally done for big clusters was done.
I'm very comfortable using the phrase "heavily tuned" when OnGres used "established norms" for PostgreSQL and ignored the existence of those (clearly documented) norms for MongoDB, while falsely claiming in their report that MongoDB does not require tuning.
I agree, it does sound like a step in the right direction.
Here’s how I look at the issue you have with trust in companies and regulatory bodies: I cannot imagine a world (inhabited by humans) without bureaucratic inefficiency and corruption inherent to the systems that organize large societies. It's like a law of social thermodynamics. We should continually strive to fight against the chaos and bad behavior, but at some level we have to understand that as long as humans are humans, /those/ efforts (e.g. anti-corruption legislation) will be marred by bureaucracy and corruption (e.g. lobbyists influencing anti-corruption legislation), like a recursive glitch in the matrix. If you can recognize the challenges that introduces, but be at peace with it, you can stay focused on what "steps in the right direction" we can make.
I respect your opinion about whether the SSPL is free or open, but it is not one that is uniformly shared by the OSI, as evidenced by the discussion currently underway in the license-approval mailing list. Many have argued in its favor. On that basis, some of your assertions in paragraph one are subjective.
Not that there’s anything wrong with subjectivity! I think it is valid to ask the question of whether the move was motivated by greed... it’s even understandable why people would default to that conclusion. (I wish that weren’t the case, but I’m not naive.)
Since you’re asking, I will give you my answer: the SSPL was created to make it viable for open source projects that are largely or completely funded by a single entity to remain funded in an era of large cloud vendors. While it is about revenue, it is not about greed.
The proof of the pudding is in the tasting, and I won’t ask you to just buy my claim. Just keep your eyes open for a conspicuous absence of MongoDB strong-arming community MongoDB users into buying commercial licenses.
As far as including MongoDB in Debian et al, goes, we absolutely respect process and principles. We’re waiting to see what the feedback from the OSI is.
Businesses have to survive in a competitive market, I get it, you don't have to apologize for it and it's not greed, it's just how the market works.
That said, you did not work with OSI or the FSF before changing the license. And your company is not the only contributor to MongoDB, you have third party contributors as well, who did not have a say in it, because of the copyright attribution that you require.
In other words, you did not collaborate with OSI or the FSF and you screwed your contributors.
It's good that you're now waiting on feedback from OSI, but the damage to the FOSS ecosystem was already done.
I appreciate your comment about how the market works, thanks for that.
You certainly have a point about our not working with the OSI prior to issuing the SSPL. All other things being equal, we would like to have, but as a publicly traded company it's just not responsible to announce "we will be changing our license... to... something... we'll get back to you on what that'll be... sometime."
We weren't happy about it, but we're doing the best we can given the constraints. We're all grownups, and accept that one of the consequences is that some in the OSS community feel betrayed by that change, but we ask that you let our actions going forward, not the worst suspicions of those most predisposed to judge us harshly, determine what you think of our dedication to OSS and our community.
As for non-employee contributors to the MongoDB codebase (who account for about 3% of the codebase), I think we should credit them with the same adult responsibility for their actions as we hold MongoDB to. Their contributions were made in full knowledge of the attribution requirement, and we have no reason to believe -- and no evidence -- that they resent anything MongoDB as a company has done.
I'm thinking about the use case to have a native app be able to work nicely with no internet connection, but then once the internet connection resumes, it downloads new data from the server and sends its offline-modified data up to the server.
From a quick search online [0] [1], I see people doing offline MongoDB sync using SQLite, but nothing like using Mongo directly. With CouchDB, we can use either the old Couchbase native app SDK, or the Cloudant native app SDK, to sync up nicely with a CouchDB instance in the cloud. We've had this running for awhile, and it works quite well, and we do not have to shuffle information to and from a SQLite database... at least, we're not doing it, since the Cloudant or Couchbase SDKs for iOS and Android keep track of all the data and store it on the mobile device however they'd like.
If there is anything similar for Mongo, I'd be interested to know!
Dunno if this thread is too cold for you to notice my reply, but there absolutely is... MongoDB Mobile was released last year, and along with Stitch, MognoDB’s serverless application platform, you can get exactly what you want — mobile sync.
CouchDB "replication" was designed to be "master-master" (or "no master" sort of) where replication is not a coordinated process but a distributed push/pull of concurrent revisions with basic conflict resolution rules.
Whereas, Mongo only built support for classic RDMS-style replication where one database serves as the master or primary, and any number of secondaries can try to keep up with it.
It's a bit like SVN versus git. Mongo when replicated still has the SVN centralized mentality, whereas CouchDB is a lot more like git.
I think we're all on the same page about the shoddiness of being in the open source insurance business, but that is not what the SSPL is for, nor could it be used for that. We simply can't make the claim that any SaaS other than specifically MongoDB as a service derives primarily from MongoDB -- or rather, it it's possible to make the claim, but it's easier to defeat it.
The whole point of this discussion is that MongoDB, Inc could make that claim (as you agree)...and we as users of MongoDB will have to spend money fighting off that claim. You'd have to pretty naive to use software that has these terms.
Sorry, let me clarify. It's always possible to claim anything. I meant that the claim is too weak for the SSPL to create that threat.
It's obvious that several people disagree, but within this thread, conversing about this article, we should expect a bias to see things that way. I hope you'll stay open to being convinced otherwise. The SSPL has been submitted for review to the OSI, and this issue is one of the points of discussion that we're listening very closely to.
It’s great that you’re listening closely, but it seems to me that regardless of what OSI says, the consensus is that nobody in this thread will continue to use MongoDB under this new license.
If your license places any requirements on software that is not a derivative work of software you own the copyright to, the license is nonfree by the standards of the OFSI and the DFSG and probably others.
> I was at the presentation last Thursday, they (OnGres) have fully open sourced both their methodology and their results and had a pretty strict divide between teams designing the benchmarks and teams running the benchmarks.
> MongoDB could create a Pull Request/Merge Request against that repository so we can all judge those results ourselves
The existing, unaltered content of the OnGres repo is all the testimony one needs to know that the OnGres team is incapable of or unwilling to produce a valid test of MongoDB. Open source garbage is still garbage.
I understand the allure of asking for a pull request from our testing team to demonstrate how we obtained the measurements we cited in our retort. It is tempting to see this as a case of well-intentioned scientists, doing their best, honestly asking for peer review. But that view relies on two things that we can not take for granted: 1) that the OnGres team is acting in good faith and will work to correct their errors, fairly declaring MongoDB more performant if they concur with our results; and 2) that such an open back-and-forth will be illuminating to bystanders.
1) We cannot assume that OnGres is acting in good faith when their report so clearly demonstrates that they biased the test against MongoDB. This conversation should start and end with the fact that OnGres used an experimental MongoDB driver to compare against PostgreSQL with a production driver and a dedicated connection pooler in front of it. (What kind of pull request could MongoDB submit to address the use of sysbench, which requires a Lua driver?) They are simply not credible.
2) What would a MongoDB-submitted patch prove? It would certainly print out different numbers, but that alone proves nothing. For those numbers to mean anything, you have to read and understand the code. Anyone capable of understanding why our patch is valid is equally capable of seeing the deep flaws in the code as published, no patch required.
Consider this: if a research group funded by the fossil fuel industry published a report, littered with false statements and methodological errors, claiming that climate change isn't happening, NASA and NOAA aren't obligated to issue full a correction of that report along with their response calling shenanigans.
No, we're not going to get mired in a patch war with demonstrably biased authors over a fundamentally flawed comparison methodology. We have published our own benchmarks demonstrating how to test MongoDB performance, and in a few months, one of our engineers will present her work adapting the industry-standard TPC-C at the VLDB conference.
> their current response is only words and a single table showing unlikely results.
There is nothing unlikely about our obtaining speedups to queries by using indexes that OnGres ignored.
> However I do think the criticism of not tuning MongoDB is valid, however their response is dishonest:
>> with their own heavily tuned PostgreSQL.
> This was explicitly not the case according to OnGres other than the established norms of taking 25% memory for `shared_buffers` etc. No other tuning that is normally done for big clusters was done.
I'm very comfortable using the phrase "heavily tuned" when OnGres used "established norms" for PostgreSQL and ignored the existence of those (clearly documented) norms for MongoDB, while falsely claiming in their report that MongoDB does not require tuning.