Homebrew removes MongoDB from core formulas
github.com
github.com
Cloud providers have been able to stand on the shoulders of giants, profiting immensely from millions of lines of open source code while giving little of it back, and we seem to be largely fine with this. Will we be fine depending on their services when the cloud providers become the new Oracle, free to raise prices extravagantly when we have no other choice?
If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be? Licensing to cloud providers would have been ideal, but the response from AWS in this case wasn't encouraging. By boycotting MongoDB in this case are we telling future innovators that their work will simply be stolen and resold for profit if it gets popular? That scares me a lot more than some project changing their license.
Of course, this is just one of the many so called "open source" companies that chose open source because they thought it would get them more users but in reality don't care much about FOSS.
MongoDB was advertised as being Open Source and Free Software, distributed under an OSI-compliant and FSF-compliant license. Now they are trying to eat their cake and have it too.
> "then are lambasted when they try to prevent a competitor from copying it wholesale?"
Because that's not what open source is about. Open source is about contributing to the commons, such that your competitors can make a profit from your work.
If your competitors aren't able to do that, then the software is not open source. Period. And in this case, we should point out that MongoDB Inc by owning the copyright doesn't have to play by the same rules, they aren't beholden to the same rules as everyone else.
> "If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be?"
Why the fuck should we care what their business model would be? That's for them to figure out.
But if they sell something as open source and they close source it, then we, the schmucks that bought into it, will point out that MongoDB is no longer open source and treat it as a proprietary piece that comes with the caveats of proprietary software, like lock in, etc.
So I hope somebody forks MongoDB from the version when it was open source.
To what end? Why should we use a fork that's supported by a few people when we can still use the Community Edition that's from the horse's mouth? The idea of forking things for the fun of it actually perpetuates the problem that we already have with OSS. We want to get things for free, use them to make money, but still expect support for new features and bug fixes. This is worse when someone does this in their 'free time'.
Let's discuss the merits of forking from when it was open source. Percona has a fork, or is it not fit for purpose as they also adopted the SSPL thing?
Wait, how has a fork of MongoDB also adopted MongoDB's evil license? How are they able to take contributions from MongoDB and package them under the same license? Do they share the source code internally, or do they upstream changes that are in the open?
> Why the fuck should we care what their business model would be? That's for them to figure out.
Isn't restricting Amazon and others from profiting from their efforts part of figuring out this business model?
> But if they sell something as open source and they close source it, then we, the schmucks that bought into it, will point out that MongoDB is no longer open source and treat it as a proprietary piece that comes with the caveats of proprietary software, lock in, etc.
Did MongoDB sell you their product as open-source? Which specific product? Was it the Community database, or the Enterprise one? Your argument lacks substance, because you're responding to someone who's asking why people are moving to another closed source product, one whose source code you can't even inspect.
(edit: typo)
Free software: free for modification, expansion or forking. Possibly free for profit (BSD license)
Source Available: Source is available but under restrictions. Locked room source viewing under NDA to confirm there aren't vulnerabilities for example.
Source-available: You can view the source, perhaps freely, but can't modify or release your modifications.
As you can see, "open source" give s only half of those freedoms: to study code, it is not mandadory that you actually can modify it.
So, not all opens source software is free. Check out licence comparison and approvals page at Wikipedia.[3]
[1] https://www.fsf.org/ [2] https://www.gnu.org/philosophy/free-sw.en.html [3] https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...
At the same time, we see a MongoDB example: a software, which definitely is open source, but also definitely is non-free.
It's an AGPL + AWS-is-killing-our-support/monitoring/ops-business license.
If I found a bug, and was adventurous to fix it, I can still open a JIRA and submit a PR to the project ...
The license is no longer OSI approved, so how do you know what you're allowed or not allowed to do?
How do you know that what's keeping AWS from using it isn't also creating a problem from you?
Have you consulted with a lawyer?
That's one benefit of using actual Open Source. You have a definition that all licenses have to comply with, such that developers know exactly the set of freedoms that's common between all of them.
Once you step out of that definition, you're on your own. So you know, I wouldn't take legal advice from random people on HN, you might run into problems.
That no one has done that already suggests that no one thinks it’s worth doing. And it isn’t, Postgres is properly free, and more than surpasses Mongo in all aspects.
MariaDB, the MySQL fork, didn't happen over night.
Give it time.
That said I dislike MongoDB but for various other reasons.
In a few occasions I see that I need to alter the library, if I do not have the rights to do that then I would probably end up dropping the library as being inadequate to the task.
In some occasions I have seen that I would like to get rid of the library but I am generally not allowed to by other business decisions, in those cases I have always been able to find some hack that allows me to do what I need to even if it goes against the preconceptions of the used library. I then make extensive comments in my code explaining why, probably referring to the other solutions I would prefer to use and explaining why I was unable to do so.
Why? What do you do?
Then you've misunderstood what "open source" means. The term "open source" was invented specifically to describe software with the following properties (among others) [1]:
~~~
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
[...]
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
~~~
Any software which doesn't meet those criteria isn't open-source.
[1] https://opensource.org/osd
(edit: formatting)
I believe this because I also believe there used to be two terms open source, and free, that these were distinct, and that all things that were open source were not necessarily free or vice versa. But it seems to me with the above definition that all things which are open source must then be free although all things that are free still do not need to be open source.
on edit: clarified I was referring to HN in first use of the term "site"
Following the "paper trail", the chronology is:
1. the "Open Source Definition", last modification in 2007, is based on "The Debian Free Software Guidelines", I suppose v1.1
2. the "Debian Free Software Guidelines" v1.1 was ratified in 2004, and is based on v1.0
3. the "Debian Free Software Guidelines" v1.0 was ratified in 1997
so ultimately, in strict terms (but that's arguable), the "Open Source Definition" is newer.
The culture for free open source software (and its benefits) was prevalent. But by the 70s companies we’re changing their attitude about this IP. I’m a reaction to increased restrictions Richard Stallman founded the GNU project in 1983.
Is there an Other World theory where this was not the case?
https://en.wikipedia.org/wiki/History_of_free_and_open-sourc...
as I am not a prescriptivist in language as a general rule it may be that I should alter my usage of the term to follow OSI usage, but then I feel that a useful term is needed for software where you can inspect the source as needed - perhaps inspectable source.
People have used the term 'source-available':
> I could swear that this has not always been the exact definition
> I believe this because I also believe there used to be two terms open source, and free, that these were distinct, and that all things that were open source were not necessarily free or vice versa.
In this perspective, the history, as reported, matches: originally, there was a "free software" concept and movement (the formal definition was given in 1986), then, in 1998, the "open source" term was coined.
Based on Stallman's critic to the Open Source ideas (https://www.gnu.org/philosophy/open-source-misses-the-point....):
> For example, “Open Watcom” is nonfree because its license does not allow making a modified version and using it privately.
The parent's doubt has verified grounds.
However, there's confusion, because it seems that the "Open Source Definition" is _now_ closer to "Free software" than it was when Stallman expressed his opinion: by that time, Open Watcom qualified as "Open source", but nowadays, based on the "Open Source Definition", it wouldn't.
We’re not talking about the proverbial ‘historical house in private hands’—can we look around at this excellent example of early Frank Lloyd Wright house in Chicago. We’re talking about ownership and control for profit.
Mongo wants to wiggle out of the bind they find themselves in. Does anyone else feel this discussion is starting to feel like ‘workshopping’ the legal definitions entrepreneurs and coders can both agree on?
Maybe the parent is asking as a curiosity—Isn’t there also a second origin story about inspection without rights?
But, in the context of the original post’s topic of Mongo and the pickle they’re in, I reserve my normally generous nature, lest I find myself the cuckolded against my own interests.
There seems to be a curious spate of discussions lately about legal use, copyright, and trademark.
Google patenting some machine learning techniques [1] here on HN.
On a Philosophy Podcast I listen to there is an interview with on a legal scholar on his work defending plagiarism [2]
And for the record I am an ardent advocate of FOSS. I believe Mongo is in a pickle, and they should do the right thing to honor the spirit of OSS. And if they can’t, then they should surrender the property to someone who can.
[1]: https://news.ycombinator.com/item?id=20863515
[2]: https://podcasts.apple.com/us/podcast/elucidations-a-univers...
There are certainly ideological differences between the two; but I think it's primarily in terms of focus. The FSF primarily aims at promoting "software freedom" as an end in itself; RMS claims that it is unethical to give people software but prevent them from sharing or modifying it. As such, they much prefer to use copyright law to promote "software freedom", by things like the GPL and AGPL. But (as I understand it), since more permissive licenses like BSD or MIT licenses do allow the "four freedoms", they consider them "free software" (albeit second-class, because unlike copyleft licenses, they don't fight to keep derivatives "free").
"Open source" was meant to focus more on the benefits of the open, collaborative software development model, without denigrating proprietary software; and, in particular, to be more palatable to large companies. As such, permissive licenses (BSD, MIT, Apache, &c) are considered just as valid as copyleft licenses (GPL, APL, &c).
But saying, "You're not allowed to run a service using our software because it might compete with us" is Right Out.
Cloud providers are now barred from using new MongoDB versions.
Is that fair? Well, the developers (a company) made a choice. They want the revenue from the support/monitoring business, AWS is eating their lunch. So either they completely change their business or try to somehow stop AWS et al. from doing that.
Since MongoDB just recently released 4.x with distributed transactions, it made sense to do the license change thing. Otherwise no one would care (and anyone stuck on AWS would just continue to use whatever 3.x compatible AWS provided).
And still, it's likely that AWS will continue to offer their non-feature-parity fork for quite some time.
So, in that sense anyone who cares or cared for AGPL MongoDB tech should have advocated for this license change a lot sooner.
No, people sending patches are not necessarily benefiting from it. Patches can be very expensive and it can be cheaper to pay for actual support with a proprietary solution that's at least honest about its nature and won't pull a bait and switch on you.
This kind of first order reasoning is nice, but the reality of software economics is a tad bit more complex. The assumption that the market is large, that the commons helps everybody sort of equally are not true in a lot of sectors. Namely, as IT transforms itself a lot of things become almost zero-marginal-cost. Starting a new server? Setting up a new database? Backup/Snapshot? Load balancing? Scaling? Just click that AWS web console shit, and you're good to go. And this out-competes the others.
I'm not saying that changing licenses is super-A-OK, but the fact is the license was never good in the first place, because it failed to take into account what will happen when AWS starts to offer MongoDB.
Furthermore, I have no problem with anyone holding the view that MongoDB should then compete with AWS, and/or focus on on-premise computing, and/or slowly pivot away from building MongoDB itself to whatever. But anyone holding this view should recognize the aforementioned reality that cloud computing is happening, IT is not just a hydra, it's an ouroboros too, it's eating itself.
Not sure what we are talking about, personally I don't make that assumption, although I recognize that others might.
Yes, roads and highways help big companies more than they help small companies. That doesn't mean that smaller companies don't benefit from the existence of roads and highways.
> "the fact is the license was never good in the first place, because it failed to take into account what will happen when AWS starts to offer MongoDB"
Without that license, let's be honest, MongoDB wouldn't have gotten popular in the first place. MongoDB has been plagued by technical issues too and without it being open source, one of the carrots being used, MongoDB wouldn't have been a blip on anyone's radar.
So this is a conundrum and I understand the reasons why MongoDB Inc has switched, I do, but I just don't care.
Because the nature of the thing has changed — and for example I would now need a lawyer to find if my own product is safe or not with an on-premises MongoDB solution, because I can no longer rely on OSI's definition to tell me if my use is OK or not. And yes, we've got random opinions on the Internet about what you can and cannot do, but that's not valid legal advice.
And even if my use of MongoDB is OK for now, who's to say they won't change the license again in the future to something even more abhorrent. This means that for me going forward is that MongoDB is no longer reliable from a legal standpoint.
MongoDB Inc's license switch may earn them some hate but I think the bigger issue is what license terms will open source contributors be comfortable with? What license captures the same spirit as the GPL, should that spirit still be desired, as software moves to the cloud? When every piece of functionality, no matter how trivial, can be used by a cloud provider to bolster their closed ecosystem, are the developers that created that software comfortable with a license that allows providers to do so without giving back?
AWS et al. are committing no violation here of course, they are taking advantage of a market opportunity to offer hosted software, some open source and some not. The market is overwhelmingly saying that they value the convenience of having all of these services available at the click of a button and that the closed source nature and potential for Oracle-style vendor lock-in is not a concern.
There's certainly value there and some folks may feel perfectly comfortable contributing to such an ecosystem, as is their right. Others may desire a more reciprocating agreement, and perhaps the AGPL is a first step towards such a license. I think we as software engineers need to recognize just how high we're standing on the giant's shoulders and put some thought towards helping a community that is trying to adjust to the new cloud reality. "Fuck you give me your stuff for free" is unwarranted and not likely to encourage contribution.
MongoDB Inc does NOT play by the same rules as everyone else because they own the copyright.
When a piece of software is useful on its own and survives, without dual licensing from the copyright holder, then and only then we can talk about the spirit of the GPL.
Also people here seem to be confused. The GPL is a super permissive license because it allows you to use it for whatever purpose. You can use it for commercial purposes, you can use it for controlling sharks with lasers to conquer the world, you can use it in combination with any other software or hardware package, doesn't matter. This was by design.
The GPL is just a copyright license, not an EULA and that's part of its genius.
Now you can say that this company or that have been circumventing GPL, but I think that AGPL licenses have been an abomination, a scurge on this industry, only used to lure developers into dual licensing deals and having nothing to do with actual Free Software.
And now we are seeing the effect of allowing AGPL. For one I see an entire forum of really smart individuals that don't really know what the spirit of GPL is, yet we talk about it.
MongoDB with its current license - in my opinion - would have gotten just as popular as it is now.
Yes, the legal questions are real, and were MongoDB just starting up they would work with OSI and experts to clarify things, they would put up a FAQ and so on to get people to trust them.
One in which OSI obviously is paid by cloud vendors to denounce alternative licenses, lobbies for developers to be treated like kattle open for abuse, yet portrays themselves as representing developers, and bogusly claims ownership of the term "Open Source", contributing to monopolization and the weaponization of developer's work for surveillance a la Android.
The bait and switch strategy is deceptive. It's aim is to milk customers to give some money back the the VCs. But this license minefield is user-hostile.
Users don't like companies exhibiting hostile behavior towards them. Simple.
They didn't use an Open Source license with the intention of getting popular and then pulling the rug out from underneath users.
They tried to make their money by offering their tech as a service and found that they couldn't compete against the resources of large cloud providers who were happily profiting off of their (and the community's) hard work.
And now the community's hard work is licensed under a new and restrictive license which, due to legal constraints, cannot be used in entreprise setups.
And now the community's hard work is licensed under a new
and restrictive license which, due to legal constraints,
cannot be used in entreprise setups.
I feel like if just cannot be repeated enough: You control which license your software is supplied under! If you want to create open source software, you have to live by that decision and follow the license. You can’t slap an open license on the software and complain when people “abuse” the fact that it’s open.
- There is nothing wrong with Proprietary software. MongoDB is vilified because they built community on the assumption what this software will be Open Source. Because of this many spend a lot of their own time helping to promote MongoDB and one day MongoDB changed their license. Amazon's DocumentDB makes no Open Source promises
- Your competitors can copy your software is one of the downsides of having your software Open Source. You however may get much better adoption curve in return.
- This is not MongoDB boycott. If repository promises to its users it will only contain Open Source software and MongoDB is not any more it naturally has to be removed. Keeping it will mean breaking promise to repository users
- MongoDB can't compete with AWS is quite far fetched statement. Competing with AWS could possibly slowed MongoDB growth of course.
Every time I run `brew update` (or perhaps _any_ brew command), I make 6 requests to "https://downloads.mongodb.org/current.json" (one for each version of the formula), and one request to get the SHA for mongdb-shell?
This defaults the whole point of a formula - metadata describing an installable. If that .json file is compromised in any way then suddenly you are downloading anything from _anywhere_ with no checks. By embedding the hash and the download URL in the formula, like literally every other formula does, the download will fail if the release is modified. And there is a git audit trail of any formula modifications.
No thanks.
I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake.
They really need to come up with a per mb per hour option.
Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product.
With a managed MongoDB (even though it's on AWS) you need to get buy in from dozens of people and go a vendor comparison to get through Procurement. It's why for many companies AWS dominates and in the future could well end up owning everything under the application layer.
There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of processes".
We had a large local bank choose not to pursue a good opportunity because "our procurement process takes too long". This instead of investing in fixing the procurement process.
What happens if a company that uses Software A has good motivation to use B, but their support functions don't understand B? Aren't the support functions supposed to improve by seeking to understand B, even at the initial inconvenience of time and resources?
Also, Amazon doesn’t have the same reputation as Google for killing products, so it’s a pretty safe bet. And AWS will be around for quite a long time. The financial stability of MongoDB (the company) isn’t as guaranteed.
Maybe the parent’s company’s processes did work in this case.
It's not about the safety of the bet, because from an OSS perspective, the issue seems to be that many are moving away from MongoDB to something even more opaque. I don't follow AWS, but do they publish a roadmap of planned changes in their document DB?
In a .gov environment, we literally paid 5x more for certain services because the contract terms demanded were too costly or onerous for OEMs to handle. So everything funneled through middlemen of dubious value, who basically borrowed money, pushed paper and carried insurance for a vig that pushed up the price.
The procurement people were very happy, because they got their three bids that varied less than 1%.
I evaluated DocumentDB and price wasn’t the issue (at our scale, the price is OK).
Main blocker is that it’s locked at Mongo 3.4 API compatibility, which is several major versions behind. But worse, their implementation of the 3.4 API is incomplete, so while they advertise “Mongo Compatible”, it really isn’t a drop in replacement.
As much as I love a managed service this was a very disappointing effort from AWS.
But we can do Hunger Games too. There's no wrong answers.
>... they continue to build on top of a broken foundation (MongoDB) ...but last I heard Stripe was still running a very outdated version ...
Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?
Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better so next they changed the license.
If it had been SQL it would have been easy to drop in another database. But Mongodb is so different from anything else that you need a major rewrite to get away from it. Postgres has some similiar functionality but it’s not drop in. Amazon has a more or less public beta of DocumentDB which as far as I can tell is a mongodb compatible interface to aurora backend - it works but doesn’t have the polish of RDS yet.
Well actually....
One corner case. If you are using Mongo with the Mongo Linq driver in C#, you can switch it out for an RDMS without changing too much code with just a little foresight.
Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model?
In C#
var seniorMales = from c in context.Customers
where c.Age > 65 && c.Sex == “M”
You get autocomplete and compile time checks.
When you want to add an record to your Mongo collection, you work with strongly typed
IMongoCollection<Customer>
Anything that you can store in object database you can normalize and store in an RDMS. ORMs have been translating relational models back and forth to object models for decades.
In the case of Mongo, you just create one object containing other objects, lists, arrays etc and the driver serializes it to a JSON like structure and stores it as is in the collection.
In the case of an RDMS, you create your C# classes to model your tables and relationships.
The driver translates the LINQ to the appropriate query language.
Well I can't tell you what the right choice in your system is, but in the general case I think going with a relational model by default generally makes sense because it's rather future proof. By that I mean a relational model gives you the most flexibility in the future to evolve your system in ways you couldn't/didn't anticipate when the system was initially designed.
No point using a relational db for that kind of thing.
Not to mention the LINQ driver....
And you can’t do updates on individual JSON fields in Postgres.
The problematic part with PostgresSQL JSONB is modifying a JSONB column content. In any case, we totally replace the old content by a new one. So, the update operations turn to the complex queries that can lose the content. You can avoid this by performing the full JSON reorganization before the persistent operation.
You still don’t have the richness of MongoQuery and the aggregation framework and the tooling around working with JSON data isn’t there. Let alone the native driver support.
When I did implement a system with C#/Mongo, I fell in love with changing my database schema just by changing my C# objects. With the C# driver you can include a Dictionary as part of your object to round trip unmapped fields.
Not to mention that after you go through all of your modeling and figuring out your aggregate roots, you can just store the entire object graph with one .Add and the entire object is stored atomically without having to worry about transactions, table locks, etc.
Unlike with an RDMS where your beautiful aggregate root has to constantly be composed and decomposed.
I think it’s just going to take somebody shaking the cobwebs off of their X.500 manuals and making the query syntax and schemas a little more ergonomic for them to come back en vogue.
It’s one thing to have the ability to mold your DB to model hierarchical data but have your DB engine support it non-awkwardly might be a game changer. People are already used to apps needing a DB, cache, queues, S3, filesystem, service discovery, that adding one more thing would hardly break the bank.
If the companies got lured into using MongoDB as a service, then I understand that prices could increase and companies could be in a pickle. But if companies got lured into using MongoDB as software, I don't see how they could have a problem.
The parent comment states "their sales people started coming around and asking for insane sums of money" but I can't find any reference to this.
If MongoDB really is sending salespeople to make claims against companies who they convinced to use their OSS database as a data-store, than they are indeed abusing their license and no one should use their database or support their company.
From what I read of the license, that shouldn't be the case though.
The only major change to the license is in adapting to the rise of cloud services.
That's one of GPL's biggest strengths.
Also successful software packages that are GPL are GPL for everyone. You don't have a mother company that can bypass the GPL due to them owning the copyright. And when you do it's usually a scam that people can smell.
You can't say about a license change that it is in the "spirit of GPL" when the mother company, MongoDB Inc, doesn't have to play by the same rules as everyone else.
So I'm sorry, but when you're talking about the "spirit of GPL", you don't know what you're talking about.
The FAQ for the license change very clearly indicates that your reading is what was intended. Question #4 particularly contains the complete text of the section that was altered, and it's hard to see how they could have left themselves any room to penalize regular users.
> If it had been SQL it would have been easy to drop in another database.
More likely, though, is that Oracle users use Oracle-specific flavors of SQL in lots of legacy apps that no one wants to touch, and rely on the support contracts for continued assistance in keeping the database performant for its query load.
There’s no incentive to not extend or try to improve SQL semantics because for proprietary databases it increases lock-in which is good for sales and for OSS databases the extensions are genuinely positive and increase developer productivity and you don’t feel bad about locking your users in because it’s OSS.
We tried to do a migration from Sql Server to Postgres.
Even went as far as building a parser/compiler to transform Sql. Certain things are just too difficult to handle.
1. Sql Server supports arbitrary sql statements in queries. Postgres does not.
2. Data types are not the same.
3. Feature sets at the 'interface edge' between the client library and the engine differ. For example, Sql Server queries can return an arbitrary number of results.
It's true that Mongo uses a custom language, but with Mongo - you are unlikely to have any significant business logic in your data layer.
Also their API surface is relatively simple.
For example, FoundationDB has a layer that mimics the Mongo API. Amazon has one as well.
To really take advantage of a database engine, you will probably end up using engine-specific idioms.
Postgres and Sql Server support recursive CTEs. MySql probably doesn't?
Sql Server supports cursors but is dog slow and generally not recommended for any sort of large scale operations.
Isolation levels and locking are really important as well. Do all engines even support the same isolation levels?
CouchDB is quietly weeping in a corner.
Hahaha. No.
If anything, migrating from something like Mongo might possibly be easier. Because it's non-relational, you probably have very little business logic in your database layer.
Unlike with Sql.
And even though Sql has a standard syntax, beyond vanilla CRUD queries, there are many differences. Even if 2 engines support the same synatx, the idiomatic way of doing something will differ.
(For example, cursors in Sql Server is extremely slow, whereas its a perfectly acceptable way of doing list operations in Postgres)
MongoDB had a good run, I enjoyed it before migrating away. This license definitely hurts companies.
What to? I built my own Open Source solution (MIT/Zlib/Apache2).
Around same time Firebase was getting popular, and Graph databases were the way forward.
Combined them all together, now have Internet Archive and HackerNoon running it (https://github.com/amark/gun) in production!
Link to tech talk for others: https://www.youtube.com/watch?v=BEqH-oZ4UXI
Could you elaborate on how companies are hurt by the license?
Additionally I'm curious how the license is harming companies, as I mentioned in this comment: https://news.ycombinator.com/item?id=20862996
And I am still yet to find any database that even comes close to its single tuple update speed.
2) Of course. But MongoDB is orders of magnitude faster in some cases, has better horizontal scalability capabilities, better drivers and some nicer semantics e.g. around streaming.
https://hn.algolia.com/?sort=byPopularity&prefix&page=0&date...
No hate, just always amused me that someone on HN had MongoDB as their hobby horse.
I had the opportunity to redesign the architectures of few productions running apps because of this superstition "Companies are falling due to MongoDB, lets switch to another DB"
Every single time, as an architect I have found that developers are just being fancy about their first-hand experience with some other database and they are unable to think in new direction which MongoDB is built for.
Following are the things most people miss:
1. MongoDB is not safe/secure. Anyone can hack it -> the default configuration were not optimized in previous MongoDB version but it doesn't mean it lacked User security API.
2. MongoDB does not support JOINs or query API just sucks -> No, it doesn't. First, You need to learn about denormalization and schema handling. Second, MongoDB supports JOIN semantics such as $lookup & $graphLookup. Third, it supports ElasticSearch like text searching capabilities and scoring. Fourth, it supports data aggregation pipelines with various ways to compose the data transforming operations including above 2.
3. It does not have triggers like RDBMS -> It has "change streams" which is more flexible than Trigger. This feature also enables multiple application servers in microservice architecture to use MongoDB as a central store. Want a custom ETL streaming pipeline? You got it.
4. It does not scale like ABC or XYZ DB -> Again understand point #2. Also, look into docs how distributed sharding works across replica sets. Spend some quality time figuring out what should be the KeyField to be used for distributed sharding of Data.
5. Licencing sucks -> Have you understood the whole project cost and complexity ? Have you actually looked at all the terms and conditions or are you just a big fan of OSS and for that you can support any stupid alternative?
Also, you got downvoted by the same people that upvoted the stackoverflow post on the problems of downvoting on technical problems on the internet.
People might not like or know the technology and are guided by older tech gurus from the previous generation such as Edgar Frank "Ted" Codd, although he was a genius, now the market is much larger and there's a lot more use cases.
Additionally, most people know RDBs such as mysql and that's what they are comfortable with, i.e. can't get out of their comfort zone and give an honest and good try to something else or don't even have time.
Also it's what's taught in courses as superior to non relational databases.
I would not change our MongoDB clusters for Postgres/MySQL/etc even if I could do it with a single command. In this case it's not relational data though, for a large business relational model I would stick with RDBs.
After several years of pain e.g. cursor timeouts (even when supposedly disabled), iterating over the same document multiple times in the one query etc. and of course no transactions (since added). I eventually migrated to PSQL (using some custom scripts) and everything is so much easier to maintain, much more stable and much faster.
We're still using MongoDB for our analytics though, as it's inherently unstructured non-relational data, so MongoDB does actually do an okay job. Well, except for the run away memory usage which leads to k8s killing the DB server for violating memory constraints every so often. Yes, MongoDB itself is configured with memory constraints, it seems WiredTiger ignores them.
Licensing was considered, however honestly MongoDB itself is (or at least was) so bad that licensing wasn't the primary motivating factor.
EDIT: Just to clarify, most of our data is relational, however we do have some unstructured data in PSQL stored in JSONB columns. They work a treat and in some cases have complex indexes on them - they far out-perform anything MongoDB was able to offer us.
Why do we do it? Cost saving. It's that simple. For your information, I wouldn't say we do it "properly" either. We do a decent job though.
Basically, for us (and many other businesses) DBs are not the bottle-neck. Our business model facilitates a heap of static content that's served (via a CDN) without even hitting the DB. When the DB is used, it's 99% read-only; except for the analytics which aren't business critical.
As with all things, it's a trade-off.
Maintaining VPS infrastructure just to run a DB is a huge amount of overhead. More so, when the DB crashes and/or wildly consumes memory. You need disk/memory monitoring, logging, process monitoring, availability monitoring etc. What if the VPS itself goes down? What automated system is going to spin it back up?
A self-managed VPS DIY solution is substantially more expensive to maintain than using well-established tooling like k8s. These are all already solved problems. Not just that, it's a standardised work-flow with the rest of our infrastructure i.e. no manual futzing around with VPC etc. to get our cluster and externally managed VPS talking to each other.
For us, a DIY solution was never even on the cards. It was either a fully managed service or what we have now.
However, fully managed services don't just cost more per month. There's frequently additional development overhead, as the offerings are "off the shelf" software and not necessarily easily customised. For example, right now our PSQL deployment is running a custom PSQL extension that seamlessly handles BSON (MongoDB) Object IDs, semantically converting them to UUIDs. Thus, post-migration from MongoDB, application code isn't riddled with code handling legacy IDs.
Monthly service provider fees are but one consideration when performing costings.
EDIT: It's probably also worth noting that our entire infrastructure, including DBs, can be spun up as a k8s cluster on a developer's work machine in one command. We of course also have a staging environment, which mimics production. Development also ought to mimic production as closely as possible (but still be debuggable).
I'm not enough of a DB person to know if it was Mongo, or the ORM I was using (Waterline), but my data is extremely structured and relational. Once I switched over to Knex/Objection with a Postgres DB, everything went much smoother. The transition, though, took around two months, was hell, and I almost turned back many times.
What I don't understand is the many people who are talking about AWS' replacement being a solution for people migrating from MongoDB.
From the comments, it seems:
- it's expensive to use. Someone spent $15 for 2KB data over 3 days [https://news.ycombinator.com/item?id=20862196] - it's only compatible with MongoDB 3.4, which seems not to be enough for some people.
What are the reasons to move to AWS' very offering that MongoDB (and others) are trying to prevent from making money off their investment? Is it a feeling of 'betrayal' that the license has now changed?
MongoDB has had an attitude that the source for the community product is available, but that they mostly develop their product using their core team. [https://www.techrepublic.com/article/mongodb-ceo-tells-hard-...]
So, did the change to their Server License thing result in people having to pay for the Community Edition?
Is the move from MongoDB because it's incompatible with one's data needs (in which case, why didn't one do enough research)?
Why move to AWS' offering instead of 'supporting' these companies? If AWS and Azure thought to create MongoDB Compatible abstraction layers, then surely they saw something useful/good in parts of the database? Then why punish the companies that innovated in creating these technologies?
Lastly, the idea that companies will be fully-OSS and make money from unicorn dust fails once those holding these opinions are on the driver's seat. How many foundations do you donate to, that support the OSS that you use?
The current trend of continuing to want things for free from companies, but being willing to spend an extra fee for a 'managed service' from a cloud provider will hurt a lot of otherwise innovative companies in the coming decade.
People tend to come to believe something organically and then later cherry-pick facts and observations that back those beliefs up. So even if MongoDB did what it had to do, or did what would otherwise be morally defensible in the most popular moral frameworks (as I personally believe to be the case), people who have a personal or emotional stake in the future of OSS will be looking outwardly for a villain. If it failed, it must be a failure of someone who crossed OSS. MongoDB seems the only choice for a villain in that regard.
Rationally, MongoDB's decision made sense because of the real actual threat of AWS and others offering alternatives (at various levels of baking) that seek to undermine MongoDB.
If this is the path that we choose to take, we'll see more companies go back to the closed source model (which MongoDB hasn't gone in).
Depends on what you think 'open source' licence means. The source is literally openly available. There are just some extra restrictions on what you can do with it. The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence.
Ref please?
The FSF was certainly around pushing for "free software" long before "open source" was commonly used to refer to copyleft / permissive licenses. And the sole purpose for OSI's existence is exactly to define what is and is not "open source".
In any case, it is very important to define terminology and protect its use. The goal of "open source" is certainly not to simply let people look at the source, but to let people use the source in certain ways. People have thought long and hard about exactly what the minimum standards are to consider something "free software" or "open source".
You can find the core criteria for OSI here: https://opensource.org/osd
And the "Four Freedoms" for the Free Software Foundation here:
Both ESR and the OSI will tell you this.
For example http://www.catb.org/~esr/open-source.html
> Yes, we're aware of the specialized meaning "open source" has in the intelligence community. This is a feature, not a bug.
The OSI tried and failed to trademark 'open source' - because it's simply a description.
https://opensource.org/pressreleases/certified-open-source.p...
> We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark "open source"; the mark is too descriptive
Maybe it turned out to be a bug after all!
From Wikipedia [1]:
> Open-source intelligence (OSINT) is data collected from publicly available sources to be used in an intelligence context.
IOW, the "source" in "open-source context" isn't actually talking about "source" as in "source code", but "source" as in "source of information". Not really related.
Whether or not they could trademark the term, when people in our community say "open source", they specifically mean something which matches OSI or FSF's definitions.
ESR says specifically that it's related - he says the relation is a 'feature' of the name, even.
ESR was the president of the OSI when it published the Open Source Definition and applied for the trademark. Justifying a weaker definition can’t be why he called it a feature.
Here you go:
You are misinformed, at best.
1. FSF predates the term "open source", that much is true. 2. OSI coined the term "open source." And FSF has has always had issues with that. 3. OSI, on their front page, above the fold, advertises their mission as stewarding the definition of "open source". Again, FSF isn't so keen on that.
In any case, if you want to come up with your own definition of "open source" you are asking to be the third person in a three-way fight. Good luck with that.
Anyway, I have not looked at MongoDB's license. If it is too restrictive for the taste of this or that distro, then I guess it has achieved MongoDB's objective.
The trademark office didn't think so. And ESR said they used the existing term from the intelligence community, which I guess is why.
Regardless, the word isn't really the important part of Homebrew's decision. Whatever you want to call it, Homebrew has decided it can't include MongoDB in its repository while guaranteeing the freedoms of its users. A semantic debate over the meaning of 'open source' won't change that.
That doesn't mean the semantic debate is useless, but regardless of where you fall on that debate, MongoDB's license does not guarantee freedom 0 of the FSF's definition, and that's going to effect which open source organizations are willing to distribute or build on top of MongoDB. You should expect platforms like Homebrew that care about freedom 0 to continue to abandon MongoDB.
Undisclosed personal definitions are an unnecessary impediment to mutual understanding.
[1] - The freedom to run the program as you wish, for any purpose
In practice, it's impossible because you aren't the copyright holder of your kernel, firmware, webserver etc. so you can't change their license to SSPL.
And besides, there's a difference between the practical impossibility of building a kernel and the idea of the actual impossibility of complying with the license terms.
That said, I think the argument that the SSPL makes it difficult enough to use the software (due to the bookkeeping requirements of tracking every piece of software that interacts with the SSPL software) has some merit.
Article 13 requires you make the source code of only vaguely related software available. So if you use a proprietary backup system, or someone else is doing your hosting stack, you can't use the license without breaching.
Having to either own your entire stack or only using FOSS for the entire stack doesn't really fit the "freedom" part of open source.
Section 13 of the mongodb license notes that all supporting software must use that license. That impacts everything in your stack. Consider kernel drivers, javascript libraries in your UI, and everything in between. Use Ansible to manage you stuff? That won't work with this license.
The goal of this license isn't to get all the "Service Source Code" under the license. They know that the people who would run a service don't have that within their power.
Instead, the goal of the license is to force many folks to have to purchase a separate license from the SSPL. The whole point of the license is to limit freedoms.
This just doesn't happen in any other industry, if you go to a baker, you must pay for the bread, you can't in most cases even ask how this bread was made or know for sure that price was fair or not, and mind you this is just slice of bread, while in technology it takes years of experience and knowledge just to create something as crucial as a database, and yet people expect everything to be free, very liberal licensing to even profit from the product without sharing it with the original maker. I don't even like or even respect MongoDB as a database, but the amount of hostility towards anybody trying to make money off a FREE and OPEN SOURCE complex software is totally beyond me.
A better metaphor would be if the bakery had started by using volunteers to create all the recipes, and then the baker decided that people could only use those recipes if they followed his terms so that the baker could stop other bakeries from competing. This obviously upsets the people who contributed to the recipes thinking they would be open for anyone to use.
Mongo started as an open source project, used that openness to build community (and indeed their product itself), and then pulled the rug out from under everyone to gain a competitive advantage.
I can understand why some people would not choose to give their code away for free, but trying to be both open source while having the benefits of being closed source seems like they are trying to exploit the open source community.
It's also unfair to pretend that companies who are setting up managed services are universally not contributing back- by open sourcing their code MongoDB has been able to benefit off of the issues that these other companies have found, often without having to do more than review a pull request.
There are benefits of open sourcing your code, just as their are downsides. Companies like MongoDB can't have their cake and eat it to- by closing their source code like they have they are exploiting the open source community. They spent years taking the benefits of the community, with the community having given them these benefits with the assumption that the community would be able to benefit from the openness of their code. MongoDB deciding to no longer offer a true open source option for their software is exploitative and a slap in the face to every open source developer.
Being technically within the bounds of your agreement and being exploitative are not even close to mutually exclusive.
>It's also unfair to pretend that companies who are setting up managed services are universally not contributing back- by open sourcing their code MongoDB has been able to benefit off of the issues that these other companies have found, often without having to do more than review a pull request.
It's also unfair to pretend that you know for certain that the benefit of this exchange was significantly in favor of MongoDB compared to the detriment they experienced from having their work repurposed.
It is not a good defense of OSS to say that this is working as intended.
Your mug analogy isn’t great. Mugs are finite in number and cost money to produce, whereas software is infinitely and freely distributable. Google running a managed MongoDB service doesn’t directly impact Mongo’s bottom line.
Furthermore, Mongo’s own managed service almost certainly runs Linux in its infrastructure. Google is one of the largest contributors to the Linux kernel, whereas Mongo makes no notable contributions. Why is it okay for Mongo to profit off Google’s open source labor without compensating them, but not vice versa?
MongoDBs use of Linux is not adversarial to Google and does not make it impossible (or even slightly difficult) for Google to benefit. In that situation, it definitely feels like the "rising tide lifts all boats" situation that OSS was intended to create. If MongoDB's use of Linux was somehow adversarial and somehow significantly affected Google's bottom line, you can bet your ass Google would change how it uses and contributes to Linux.
Cloud vendors' use of MongoDB is also only adversarial because MongoDB chose this particular business model. They could have charged all users like Microsoft and Oracle, released separate community and enterprise editions like MySQL, or charged for support like SQLite. It's fine that MongoDB wants to monetize this way, but it doesn't mean that anyone has to accommodate them.
I also want to say that I'm not opposed to people charging for software! It's just that MongoDB seems to want to reap the benefits of being open source, while still restricting how people can use their software.
Nothing helps them recoup this. Open source is a public good, IMO. It doesn't benefit the creator nearly as much as those who can consume it. I'm not trying to say I think it's okay one way or another that Google isn't making money on its Linux contributions. I'm saying Google is okay with their position because no one is using their contribution to the public good against them, and they would have made those contributions to the Linux codebase anyway (because it benefits them to do so) so why not help everyone? Again, rising tide lifts all boats kind of thing. That's the difference here. Google wants Linux to be better because it makes their platform better. But Linux being better is not the product they offer. And the world having a better Linux doesn't undermine their product. At least, not in the same way that offering MongoDB managed infra for cheaper than Mongo can undermines Mongo's product.
I think you're trying to say fair is fair, and the license must be applied evenly and consistently or your reneging on the deal. Which I think we can all agree on. Where we differ is that I think it's okay to change your license if it's killing you.
The other sticking point for me is the idea that it's "exploitative" for cloud vendors to run managed MongoDB instances without paying them. MongoDB has existed for over a decade, but their own managed service only came out in 2016 — before that, they offered an enterprise version and support. So were cloud vendors offering a managed MongoDB before still exploiting them? Or did it only become exploitative once MongoDB decided to enter that market, too?
More practically, MongoDB offers their own managed hosting service. Are they paying the Linux Foundation for the OS they’re almost certainly running? How about nginx / HAProxy / Let’s Encrypt / whatever else they’re using in their stack? This isn’t to say that there’s anything wrong with charging for software, but it’s pretty hypocritical to point their finger at others for profiting off free software whilst doing so themselves.
[1] https://en.wikipedia.org/wiki/The_Free_Software_Definition
Put another way: Amazon is a corporate member of the Linux Foundation. Why is it okay for MongoDB to profit off Amazon's labor without paying, but not vice versa?
For the case of Amazon sponsoring linux, it's in the very interest of Amazon that Linux stays alive and active because all their billions from AWS comes by running linux kernel as infrastructure, not to mention having the advantage to influence the components being added and maintained that result directly in more profit for them. Linux foundation is totally different in its structure and goals from a for-profit company like Mongo.
What about charging all their users? It's worked out fine for Oracle.
The current licensing scheme is fine, too. Again: no one has any issue with Mongo charging their users! It's just not open source software.
> For the case of Amazon sponsoring linux, it's because the very interest of Amazon that Linux stays alive and active because all their billions from AWS comes by running linux kernel as infrastructure, not to mention having the advantage to influence the components being added and maintained that result directly in more profit for them.
The question remains, though: why is it acceptable for Mongo to profit off Amazon's open-source contributions without compensating them (or at least donating to the projects themselves), but not vice versa?
> Linux foundation is totally different in its structure and goals from a for-profit company like Mongo.
I don't understand your point here. Mongo isn't owed anything extra just because they've decided to structure themselves as a for-profit company.
To your baker analogy, I don't have any objection to a baker withholding their recipe. But if a bunch of bakers want to share recipes, and they form a special supermarket where only these recipe-included products will be sold, why is it considered hostility for them to exclude a product that doesn't make its recipe freely available?
Nobody's being mean to MongoDB. Even with Homebrew, MongoDB can still distribute its own source. It's just that MonboDB doesn't belong in the same store aisle that they used to be in. People are only getting ticked that MongoDB is trying to position itself as some kind of open source savior, that its advocating that MongoDB should still be allowed into the recipe-included bakery chain, even though it's not following the same rules.
If I run a vegan bakery and I don't include sausages, that's not me being mean to the meat industry. If I run an Open Source repository and I don't include proprietary software, then what part of that is hostile?
I was not able to find an active fork; the closest thing I'm finding so far is here, but it hasn't seen any activity for 7 months:
[1] https://www.postgresql.org/docs/9.1/datatype-character.html
Mongo provides you computer code packed into a tarball and forbids you from profiting from new code derived from it by your own work. Is this ethical?
Is either example more or less ethical if the price is, or is not, $0?
That’s the debate in a nutshell.
(I declare no position on either scenario presented, and will not, so that the explanation stands apart from my ethical opinions.)
I don't have any problems with it ethically: if they did the work and own the copyrights, they can make whatever conditions they want as far as I'm concerned. It's just not open source.
It also gives you source code but attaches some pretty significant conditions that in most cases would prevent you from profiting from new code derived from it.
With the GPL someone could take your unique product, make it their product, undercut you on price and then put you out of business.
GPL is unquestionably great for consumers. Not so great for commercial businesses.
In the AWS case, Amazon already spent many multiples of MongoDB budget on their platform, so they were easily able to undercut.
These restrictions mean it is no longer an open source project. It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings them more money.
Since mongo has reached the point where they're competing on license terms, not on service or via their product, mongodb may not be the best choice for someone starting a new project. At this point lots of other options exist, with stable and open source solutions like postgres having document store features built in as well. In fact for a lot of use cases postgres already performs much better than mongodb, leaving the real question to be why anyone would choose to use mongodb at this point.
Ultimately this is only a worry for people who choose software that is apparently not good enough right now, but hope it will become good enough in the future.
At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.
However, the number of documents is large, and for some documents previous versions will have to be stored, as well.
With Mongo out, do you have any suggestions? Is PostgreSQL the best option here? I'm fairly new to this space.
Has this changed?
I've run into some weird issues in the past with data types changing by themselves, but it may have been user error: in any case being able to reindex from scratch fixed the problem.
As a counterpoint, mongo also still has some outstanding issues with jepsen tests, but they are working on being compliant. Honestly, as far as resiliency, I’m not sure either has solved the problem perfectly.
For a long time, the only reason ElasticSearch was not the ugly duckling of distributed systems was because MongoDB existed. It does not have a good history at all. There was a time that Elastic even claimed that it beat the CAP theorem, which always makes me chuckle when I'm reminded of it, and historically they also have been quite vague about the distributed properties (and shortcomings) of ES.
It works fine as a secondary datastore when you would benefit from all of the implemented search functions, but I wouldn't trust it for consistency (so I guess in a way it is a replacement for mongo \s)
Not only that but having operated ES clusters before, it's a tricky thing to manage, and depending on your workload they can be very resource hungry.
PostgreSQL is very solid though, and will scale well for the majority of people. I highly recommend this over ES, not to mention it does have some search features too, you should check them out.
I work on a team at Target that provides a log aggregation product and we’re finding that a single index with a well-defined schema used to troubleshoot applications via logs is very easy to manage and scale. We support some legacy patterns like “index per application” that are a pain in the ass to manage.
Just to provide some context, we manage about 40 clusters that range from a few data nodes to about 160 data nodes with the majority falling in the 16-60 node ballpark. We don’t have a problem with data loss due to elasticsearch, generally speaking.
Example:
Here’s a fantastic new mixing machine. You can make your own for free and use it in other applications such as making smoothies or cakes. You may not start an industrial mixing biz and charge money for it. That’s my biz model.
* Yes, but that's de facto _not_ open source, because all OS licences allow commercial use by definition;
* A licence isn't a magic bullet, you can have this model but if you're not prepared to enforce it it's useless.
The idea is probably that one would have to pay for commercial usage, which absolutely is compatible with open source.
Are there any forks with momentum?
IMO the use case for mongodb in its heyday was great support for schema-less storage, which was perceived as a way to give your team velocity. And also great support for operating a cluster over primary keys.
(The performance story vs SQL is overstated -- a lot of their early benchmarks were from tuning down safety margins like fsync. You can do that in SQL DBs too).
postgres has pretty good json support these days and mysql is getting there (managed mysql tends to lag a version).
No idea how that works as I don't have any experience with either of them.
But if you really do need NoSQL to deal with scalability or more advanced requirements, I like DynamoDB. I like it not because it’s user-friendly (it’s not very), but because its limitations are very clear and out-front, and if you try to do something it’s not suited for, you’ll quickly realize it’s hopeless.
Mongo is the opposite—it gives you the impression that you can use it for all kinds of things, and it feels easy in the beginning. But without careful planning, it will lead you merrily into awful traps, because its underlying limitations are glossed and patched over by the api rather than being made explicit.
https://opensource.com/article/19/8/open-source-licensing#co...
My 2 cents: Best to keep data normalized and in separate columns. If you gotta keep data in jsonb, keep only the data that you don't need to query on. Anything you need to query, you better put it as a column. You'll thank me later.
I use lmdb pretty extensively. It is single-file (well, it has a lock file) key/value store, can be read-from/written-to by multiple processes, and embeds nicely. It has Python bindings, but I've only used it from C.
It supports querying, see json_extract function.
https://www.sqlite.org/json1.html
I use it a lot to return JSON from normalized data, for apps to consume.
It's worth noting that sqlite's typing is very flexible, so you probably want to add a `check (data is null or json_valid(data) = 1)` to ensure the data is _actually_ valid json.
You can then index based on json queries, eg `create index some_index on something((json_extract(data, '$.someField')))` and then do an indexed query, eg `select * from something where json_extract(data, '$.someField') = 'blah'`.
In our experience it's all working quite well :-)
(Groking json_each and json_tree took a few goes, but now is working well (eg we join onto json_each to allow a row "labels" containing a list of label (rather than a one-to-many table join for something_labels)).)
Downsize or diversify
Good luck!
At this point I think it's a coin-toss whether we move to an RDBMS or try to use their newish JSON Schema support (and other features) to achieve some sanity.
And, to be fair, Mongo's hosted management console is really good, the support has been excellent, and since we switched over to their hosted solution I don't think we've had a single problem that wasn't of our own making.
My guess is it won't have a big impact, because customers who care about the license being open source probably wouldn't have been paying MongoDB in the first place.