metheus

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

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.

I also work for MongoDB.

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.

The SSPLv2, currently under review by the OSI, does not have this property.

Try the free tier on Atlas.

The API is implemented on the server side; the licensing of the MongoDB drivers is irrelevant.