Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FerretDB: open-source MongoDB alternative

blog.ferretdb.io

Post reply on HN
Print view View original

51–60 of 130 posts

Re: FerretDB: open-source MongoDB alternative

#51

Post by vrtx0 »

PeterZaitsev wrote: post #36
vrtx0 wrote: post #29

Earlier quoted context omitted.

No, the term “open source” was in use before long before the OSI, and it was in popular/hacker culture in the 1980s. UNIVAC used it in for a major system in the 1950s. [1] I used it in 1993 (I wrote a small BBS). The OSI looks and sounds like an authority on open source software, but their entire strategy is legal, political and quasi-philosophical. I get how easy it is to be mislead by them though — they’re good at…

There are 3 "competing" Open Source and Free Software definitions - from OSI, Free Software Foundation and Debian. MongoDB does not match any of them and most importantly does not match the spirit of Open Source Software Movement.

I could name more, but let me clarify something. I’m not a fan of the SSPL, but I get why it was necessary.

It was rough seeing huge cloud providers profit off open source projects without giving anything back. When they offered competing hosting services with no value added (well, past “integrated billing”), no contributions or innovation, and drove their new customers to the documentation and libraries of the companies backing these projects, they crossed a huge line.

And it’s not just MongoDB. Or Elastic. Just look at all the “services” AWS offers, and note how many AWS actually invented or even contributed to…

Monopolistic practices forced a lot of companies to either shut down, or find a way to survive. I’m glad MongoDB decided to use the SSPL instead of shut down like so many others. I’m glad they’ve continued to thrive.

Changing to the SSPL isn’t ideal, but it only impacts people who want to sell hosted versions of the software (not users, self-hosted or otherwise). For those infinitesimal few selling hosted versions of the software, it doesn’t even stop them from doing what they want — it just stopped the monopolies from destroying something a lot of people dedicated a lot of effort to... That seems like a pretty amazing feat to me, given the reality...

I wish the OSI wasn’t so successful painting users of the SSPL as somehow betraying the open source community. And I wish the SSPL wasn’t necessary. But until there a better option, I’m ok with the SSPL…

Again, I say this with all due respect, and this is just my opinion. Corrections and new perspectives welcome!

Re: FerretDB: open-source MongoDB alternative

#52

Post by mitjam »

that_guy_iain wrote: post #47
aleksi wrote: post #23

Earlier quoted context omitted.

> They are still able to run cloud hosting just release their custom code? The SSPL license reads: > […] you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. > “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified…

I am confused. If you use a custom storage system then you would have the code for it. No?

Yes and custom network software for routers, switches, firewalls, and custom OSes etc.

Re: FerretDB: open-source MongoDB alternative

#53

Post by tracker1 »

kbd wrote: post #42

Ok, old man yelling at clouds moment finally coming for me. Now that we've been through the document-database heyday and are out the other end, what have we learned about where document databases are a good fit? At the time I looked at them like a fad. "These script kiddies want to write javascript and ignore schemas. Let's see how well that works out for them." As expected, most of what I ever hear is regret. Today,…

Looks that way to me... I really liked a LOT about MongoDB, I don't think they had a good story for administration of scale + redundancy. RethinkDB, Cassandra and others have a ring + redundancy model which I think is easier to deal with. Where Mongo at least was limited to replication or sharding, and was a serious pain to deal with from the admin side imo.

Understanding the advantages and shortfalls is sometimes harder too. Mongo having multiple secondary indexes is pretty nice as well. Haven't dug into FerretDB, my first question is if it will run over the top of CockroachDB, as that's how I would probably want it configured. Then, I'm not sure if I wouldn't just use the JSONB surface in PostgreSQL/CockroachDB directly.

I think it just really depends on how/what you need to accomplish.

Re: FerretDB: open-source MongoDB alternative

#54

Post by that_guy_iain »

mitjam wrote: post #52
that_guy_iain wrote: post #47

Earlier quoted context omitted.

I am confused. If you use a custom storage system then you would have the code for it. No?

Yes and custom network software for routers, switches, firewalls, and custom OSes etc.

Those aren’t listed are they? The idea you need to release code for the os, file system, network routers, etc is absurd.

Re: FerretDB: open-source MongoDB alternative

#55

Post by peterfarkas »

that_guy_iain wrote: post #46
PeterZaitsev wrote: post #36

Earlier quoted context omitted.

There are 3 "competing" Open Source and Free Software definitions - from OSI, Free Software Foundation and Debian. MongoDB does not match any of them and most importantly does not match the spirit of Open Source Software Movement.

Please state in what way they don’t? This is what I’m confused about. Apgl is open source but a sspl isn’t? They seem to be aimed at solving the same thing, which is cloud/server based code modifications.

SSPL goes way beyond AGPL as it contains an additional clause called "Offering the Program as a Service". It is not defined at all what constitutes providing MongoDB as a service. How many layers are needed to abstract MongoDB in a way that it doesn't trigger this clause? There are no answers for that in the SSPL. It comes with an enormous amount of risk compared to AGPL. There is a good article from Dor Laor at ScyllaDB which explains this in detail [1].

Moreover, cloud providers are not limited to AWS, Azure and GCP. Smaller providers whom we talked to are not able to negotiate licensing terms with MongoDB the same way as how AWS could. For this reason, these providers are not able to provide MongoDB as a service. Yes, it's great for MongoDB that they were stopped from providing MongoDB for free, but now they can't provide the service at all. This limits competition and choices, and that is never in the favor of users.

[1]: https://www.scylladb.com/2018/10/22/the-dark-side-of-mongodb...

Re: FerretDB: open-source MongoDB alternative

#56

Post by tracker1 »

tasubotadas wrote: post #43
softfalcon wrote: post #20

Earlier quoted context omitted.

I would recommend against modeling too many relations in a document DB. It can work, but it gets bogged down very quickly for the reasons you've stated. My off-the-cuff suggestion is that document databases are not built to model normalized relational data. If you try to do so, you bring a whole new level of pain upon yourself. It is do-able, but it is hard and annoying. I know this from extensive personal experience…

Joins only make sense in analytical context as a tool to get some additional data into your report and almost never as domain modeling concept. People should pretty much hardly ever use RDBMS for their domain data... but since everyone learns RDBMS as their first DB, we have these horrible ORM frameworks on every corner.

Yeah, I've kind of railed against ORMs for a while now... I'd just assume a simple data mapper (like Dapper for C#) or be really explicit in a scripted language with template queries.

Re: FerretDB: open-source MongoDB alternative

#57

Post by kiney »

mitjam wrote: post #49
kbd wrote: post #42

Ok, old man yelling at clouds moment finally coming for me. Now that we've been through the document-database heyday and are out the other end, what have we learned about where document databases are a good fit? At the time I looked at them like a fad. "These script kiddies want to write javascript and ignore schemas. Let's see how well that works out for them." As expected, most of what I ever hear is regret. Today,…

A use case I have for FerretDB is migrating existing apps off MongoDB without needing to change the code. I find it funny that you could call these now „legacy“ apps.

Insert meme here

Re: FerretDB: open-source MongoDB alternative

#58

Post by zokier »

vrtx0 wrote: post #35
PeterZaitsev wrote: post #30

Earlier quoted context omitted.

"You can do so as soon as you open source infrastructure" is impractical and misleading. It is very likely part of infrastructure will be commercially licensed so even if one would want to open source it, it would not be possible. MongoDB Specifically switches from Open Source License to SSPL to create monopoly in DBaaS Space. IT is business decision so lets not pretend here. If you look at Real Open Source software…

Er, if you develop the infrastructure to host MongoDB, you should absolutely be able to open-source that infrastructure. I mean, before MongoDB, I wrote a cluster management system for virtualized software security and hypervisor research, and all of it was either open source or something I wrote… Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license? Your s…

> Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license?

Lets say you are running your infra on any cloud provider. Do you think its realistic to get them to hand out their source code?

Re: FerretDB: open-source MongoDB alternative

#60

Post by ahachete »

vrtx0 wrote: post #28
peterfarkas wrote: post #11

Earlier quoted context omitted.

By definition, SSPL is not an open-source license [1]. One could argue that the SSPL brings justice to open-source, as cloud providers will not be able to monetize a project without giving anything back. SSPL forces them to pay a license fee. On the other hand, this also creates a vendor lock-in situation for the user, simply because not all service providers will be able to negotiate a deal with the developer of the…

MongoDB’s source code is still freely available. It’s still actively developed in the open on GitHub. Unless you’re offering MongoDB as a service, it’s just as “open source” as ever. If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right? And if you don’t want to make the source available, you can purchase a license and…

> "Unless you’re offering MongoDB as a service, it’s just as “open source” as ever."

It's not. It's source available, and that's still proprietary.

The reason why the SSPL is not Open Source is pretty simple: it doesn't convey the four essential freedoms of free software [1]. That's it, there is essentially no more to it: it imposes usage restrictions, and that's orthogonality against the spirit.

Whether it is "except this or that" or "AGPLv3 but with this additional clause" is irrelevant: even the tiniest change can cause significant differences, and this is the case: it removes the freedom to run the program as you want, as it imposes restrictions to some use cases. And these restrictions go beyond the realm of the software itself.

In contrast, Open Source copyleft software, like AGPLv3, never go beyond the software itself. It provides guarantees that modified versions of it also remain available for users of modified software (forward carrying guarantees) but do not add a requirement to also provide under the same license other unrelated software (which is essentially a nice way of saying "simply don't do this", turning de facto into a usage restriction).

[1]: https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms

Post reply on HN