It’s already been mentioned that “Queryable Encryption was designed by MongoDB’s Advanced Cryptography Research Group, headed by Seny Kamara and Tarik Moataz" - are you calling bullshit on their work? What are your qualifications?
So long as whatever system they designed has not been published and reviewed by independent experts, then yes. I don't have to be an expert in this space to recognize what the norms are for making new production ready cryptosystems are, and that this doesn't remotely meet them.
Designing secure cryptosystems is hard. Experts fail at it all the time. The lack of technical details is a major red flag.
Not to mention the distinct possibility that even if this group made a secure system, the mongodb marketing dept may very well be misrepresenting its security/limitations.
> Closed, source-available, software vendors are the anti-thesis of that. They want others to participate and contribute,
Whatever makes you claim they want others to contribute? They have a large engineering team, it probably wastes more of their time to review external “contributions” than add value.
> if I could modify the source code … But I can’t … legal.
You absolutely can. Where did you get the idea that you cannot?
> Whatever makes you claim they want others to contribute?
1. They started out, and achieved their success partly, by making an Open Source database. When you publish something under that moniker, into the Open Source community, it is generally assumed you want to collaborate. That's the default. Projects that want to publish Open Source software but don't want collaboration (e.g., SQLite, AOSP, etc.) make it clear and explicit that they do not take contributions. Because collaboration is the default.
2. They set up contribution guidelines[1]. Their words: "MongoDB welcomes community contributions!".
3. They set up their own trackers and tools to classify issues/tickets for external contributions. Their words, again from [1]: "tickets of an appropriate complexity for new engineers are marked with a “neweng” label."
4. They evangelise Open Source contributions. Even when they demand copyright assignment to accept any contribution.
To distribute a modified version of MongoDB to a client, without breaking the conditions of the SSPL, I shall have to license my changes under the SSPL itself, and distribute a copy of the SSPL with it. I cannot legally convey a copy of the license text, even if MongoDB Inc. permits me to "copy and distribute verbatim copies" of the license document, when I know that they may not even have the copyrights to do so, and that the legal copyright holder of said document does not allow changes to it.
You are right that most big FOSS projects don't want your contributions, another ugly fact behind the open source myth. And why would they? How could you control code quality if you let randos write your stuff? You can't. No reasonable organization that is trying to make money from software would rely on people outside that organization to write or fix it.
> How could you control code quality if you let randos write your stuff? You can't.
Huh? You use the pull request mechanism on Github. That's what it's there for. If people want to contribute, the PR needs to be up to standards. Just to pick one example, Elastic uses this method for ElasticSearch. [1] ES gets PRs from hundreds of unique contributors each year.
Pull requests don't mean the code gets integrated. It's just someone sharing a suggestion. Unless that suggestion happens to be on the project's to-do list or it fixes an open bug, I'd say it's unlikely to get merged.
Elasticsearch's top contributors (the three I checked) seem to work for Elastic, which goes to what I'm saying. No profit-making business can have its workflow dictated by the public. Even if a pull request is accepted, the team has to go through all the same code review and testing processes as if the code had originated in-house, and that's not always feasible or on the timeline when the request comes in.
> Unless that suggestion happens to be on the project's to-do list or it fixes an open bug, I'd say it's unlikely to get merged.
There are lots of open source projects that contradict your assertion. Here are 3 projects that have been quite liberal about accepting PRs from outside.
* MySQL - MySQL AB was very open about accepting external patches. Oracle still does today.
* ClickHouse - Yandex team has the most commits, but accepts PRs from hundreds of outside contributors.
* Superset - Apache project that is supported by Preset. Again, pretty open to new PRs as far as I can tell.
Overall it's a question of how the community is governed. A lot of us view open source communities as sources of innovation. That being the case, why would you refuse a good PR? Somebody just solved a problem for you, maybe one you didn't even know existed.
Nope, just the same API, completely unrelated codebase.