AWS, MongoDB, and the Economic Realities of Open Source | Hacker News Reader

AWS, MongoDB, and the Economic Realities of Open Source

stratechery.com

502 pointsabd12248 comments

Two comments:

Firstly, the discussion at the front about the music industry is quite insightful, but I'd go further - they didn't want to sell convenience at first. Used to the physical embodiment of recordings rather than the de-materialized reality of digital music, they spent years working on mandated inconvenience through DRM and other legal actions. Always remember that if the music industry had won unopposed you'd have to pay a license fee to set a MP3 as your ringtone, as well as having to license every copy on every device separately.

Secondly, about mongodb: I'm reminded of https://www.gwern.net/Complement "Commoditize Your Complement", but in reverse.

Open source software is by definition commoditized. Everyone can have a copy at no cost. So what is an "open source VC funded" company doing? Creating complements and selling those. It's just that there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS. It's not a law of nature that e.g. Redhat should be the best people to provide consultancy on RHEL.

The music industry did not expect their product to become free to distribute at the margin, but every company operating as an "OSS startup" has to know from the start that their software can't be charged for directly.

> there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS

There are no guarantees that they will provide the best complements to their own product, but the common sense is that they will. From a marketing perspective, I think it makes complete sense, especially when selling to enterprise customers.

But they don’t.

The best complement for server side software is often being able to do it reliably, globally, redundantly, managed, on demand, and cheaply. The only three companies that can do that reliably as far as most customers are concerned are Amazon, Microsoft, and Google.

I agree, I think Docker is an example on how to almost completely fail to take advantage of being first to market. Redhat, AWS, Google and others were quicker to monetize on docker (the runtime) than Docker the company.

Docker are actually an example of a pattern, one that also impacts MongoDB and many other companies. That pattern is that they intentionally branded the product and the project with the same name (in this case Docker) to help with slipstreaming on the community mindshare they were building.

The flip side of that which eventually comes home to roost though is that it means the two are easily confused . If I'm a customer and I can download X or buy X from you, and the two are virtually identical, you better have a damn good story as to what your value proposition over and above the project is.

Red Hat actually arguably only just got themselves out of this. Originally there was just Red Hat Linux, regardless of whether you paid them a cent. The split into Fedora (Core) - the free distribution - and RHEL - the enterprise distribution with paid support subscriptions - is a not insignificant part of why the company still exists today. This transition was not without controversy, and arguably created the space into which Canonical and Ubuntu emerged, but it was a necessary step to disambiguate the project and the thing people actually pay for with its own value prop and messaging around it.

It's somewhat surprising that so many of these companies proclaim they want to be the next Red Hat, but ignore the prior art for how that came to be.

I don't see anything Mongo could have done differently. Even if Mongo were completely proprietary software, it wouldn't have affected AWS. They didn't use Mongo's code just emulated their API. That's basically the same thing that kicked off the entire PC industry -- clean room cloning BIOS.

Emulating a propietary API would open up the door to litigation with uncertain outcome, generating distrust and bad press for Amazon. So not the same.

The original PC BIOS was also proprietary.

Google did the same thing with Java. It’s up in the air how that will turn out.

Actuallt the courts already decided in Oracles favor, the only remaining thing to establish is how much money Google will have to pay.

Actually the courts already decided in Oracles favor, the only remaining thing to establish is how much money Google will have to pay.

This has already been settled in the courts: APIs are not subject to copyright and may be freely reverse engineered, provided the usual cleanroom methods are followed.

After the Google vs Oracle case i thought the courts decided the opposite of what you are saying: APIs are copyrightable and Google will have to pay aot of money for using them in Android.

> After the Google vs Oracle case i thought the courts decided the opposite of what you are saying

Are you posting from the future? Because it isn't after that case yet; Google plans to appeal (given that they filed for an extension to the 25th of this month) the latest Federal Circuit decision to the US Supreme Court and, if that doesn't succeed and end the case in Google’s favor, the next step would be a third trial in the District Court, followed—however that turns out—by another appeal by one side or the other to the Court of Appeals for the Federal Circuit, possibly another petition for en banc rehearing after that appeal, and potentially another appeal to the Supreme Court.

> as far as most customers are concerned

Probably true for the average punter, but we shouldn’t overlook the other players, like Alibaba, DigitalOcean, IBM, Vultr, Oracle, Linode and more.

A serious enterprise is not going to bet their cloud infrastructure on Linode. AWS offers a lot more than just a bunch of hosted VMs.

A serious CTO whose neck is on the line is not going to go with a small player.

To paraphrase an old saying.

“No one ever got fired for buying AWS”

For an MS shop, the same could be said for Azure.

more than VMs. yes, and that's the vendor lock in part.

sometimes it's okay though.

but AWS monoculture is not a bright future.

All of the services with no lock in

Elastic Cache - hosted Redis and Memcached

Aurora - compatible with MySQL and Postgres

RDS - hosted versions of Mysql, MariaDB, Sql Server, and Oracle.

Redshift - yes it uses a proprietary/columnar store engine but it is compatible with Postgres.

Etc.

But the bigger point is that you’re always locked into your infrastructure, do you think your CTO is going to move from their million dollar Oracle infrastructure because you used the Repository Pattern?

AWS has quite a few other solutions that you haven't mentioned that are not so portable.

I'm not advocating simply ignoring AWS's strengths because let's say Lambda/EBS/ELB/etc. is proprietary, but this is a very real, very simple risk. As AWS can, it will raise prices.

And sure, maybe it doesn't matter because you can always just fall back to using whatever you use on simple VMs, and AWS will always have some competition in the simple VM hosting space and VM prices will therefore will be low.

However, I'm on the opinion that institutional inertia will "kick in" (to use a rather bad figure of speech for something that is about as agile as a drum of molasses) and will simply let AWS rent-seek.

So you’re going to “move to the cloud” and just host a bunch of VMs.

Congratulations, you now have the worse of all worlds. You’re spending more than baremetal, you’re spending just as much on maintenance and management instead of letting someone else do the “undifferentiated heavy lifting” and your developers are moving slower than they would have if they took advantage of your cloud vendors offerings.

Win????

You can't just "move to the cloud" by firing Ops people and giving an AWS account to your Devs.

Or, well, you can, but then don't forget to set your billing limit to infinity as well. Because AWS wants to make money.

Anyway, I'm not saying RDS/Aurora/etc. is bad, but eventually the heavy lifting will be available for anyone ( https://github.com/beekhof/rss-operator and similar projects ), and it's not like AWS likes to pay when they don't perform according to their SLA.

There is more to the cloud than “managed Kubernetes”.

While you can’t fire all of your ops you can reduce the headcount by a combination of managed services/servers, automation, outsourcing to managed service providers, and an auto healing fault tolerant infrastructure

If you go with AWS because they have the best SLA, or GCE because they have better managed K8 offerings, then fine.

But going with AWS because ‘no-one ever got fired’ for it, or picking Azure because you play squash with a guy from Microsoft’s sales team is just lazy. Not that I’m saying it doesn’t happen.

Forbes and Gartner might ignore the other players, doesn’t mean we can’t be better informed.

Well, let’s look at where the phrase originated and how that turned out.

If someone had bought a mainframe IBM system in 1980 to run their COBOL system over their competitor, 40 years later, they could still buy a compatible system from IBM. It’s competitors - not so much.

On the other hand, idealism has its place, but when things hit the fan because of your choice of vendors, it’s a lot easier to justify a buying decision by saying the vendor was in the second quadrant of Gartner’s Magic Square.

I realize that the idea of “Commoditizing Your Complements” has gained new life lately on HN, but let’s give credit where it’s due - Joel Spolsky in 2002.

https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

Credit for what?

For “commoditize your complements” strategy, which was probably popularized by Stratechery but GP found earlier piece by Joel Spolsky about the same idea.

So credit for a phrase? Neither invented the actual strategy.

Well, Einstein didn't invent Relativity but he gets credit for describing it.....

So every discussion involving relativity has to mention Einstein even when it's not germane?

Everyone keeps linking to the Gwem.net website instead of using the primary source.

If Albert Einstein had a blog post about relativity, I would rather read that than someone’s interpretation....

He wrote books about it, have you read them?

Well actually....

The Gwern post is better: it starts by linking, quoting, and summarizing the Spolsky post, but then goes on to give many more examples.

He did invent it. Our scientific models are just that: models that can make accurate predictions.

There is a lot of value in distilling some amorphous concept or unclear practice into a simple rule that makes sense and frames it in a template, making it easy to both recognize and implement.

Well this is like an inverse for that strategy. If your core product is OSS you aren’t commoditizing its complements, but rather trying to build and charge for those complements (such as hosting or management services, consulting, etc) because you can’t charge for the product itself.

For a profit seeking corporation, your core product is the product that makes you money.

Roku sells hardware, but the CEO has said in no uncertain terms that their core product is aggregating user data to sell to advertisers. That they don’t consider themselves a hardware company.

IBM was also big into open source to sell mainframes and services.

Sure, but Spolsky didn’t invent the concept. The idea is probably hundreds of years old.

The first four words of the linked Gwern article are "Joel Spolsky in 2002". In fact he gives him credit 3 times!

Yes but why not link to the original (which is also more readable)

I think the use of revenue is a little disingenuous.

Producing, packing, and shipping a physical copy and marketing on broadcast television were major expenses of the pre-2000 world that they no longer have to the same extent (maybe they still buy TV ads but I haven't seen one in a decade at least, used to be all over the place). If you keep smaller part of $12 or a larger part of $0.99 your revenue could fall with profits staying the same.

Maybe the overall picture stays the same but this was very distracting for me from the argument made in the article. It made me wonder what else isn't quite right.

The peak on the graph is 1999.

At the start of the decline, there wasn't really a good way to buy music in digital format at all. iTunes launched in its current form in 2003.

The decline between those years was essentially the industry losing $12 sales to $0 sales: either directly to piracy, or to competition for time and attention on the Internet.

Youtube blew even more of a hole in the industry in 2005, replacing purchases with streaming. This plays $0.0006 per stream.

(The corresponding profits graph is really hard to find, which suggests that the data may not be so publicly available?)

> It's just that there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS.

AWS's version will likely always lag on features, whether it's their Elasticsearch service or this new DocumentDB thing. So to continue the music industry analogy from the original article, sure Taylor Swift may or may not be able run the most reliable streaming service but she'll still get business if Spotify/Pandora only has covers of her songs.

A closer analogy would be “Spotify/Pandora cannot stream new albums for a period of X months” since AWS has the option to develop the missing features, and will if they’re requested by enough customers (AWS is extremely pragmatic when it comes to product roadmap). So, to strain the music analogy further: if you’re happy with the back catalog and you can wait a little bit to listen to the latest songs (say, while others test if they’re any good) then you don’t have to put up with the unreliable streaming service.

IIRC this strategy was tested by Jay-Z with little success. Taylor Swift also came back to Spotify...

Used to the physical embodiment of recordings rather than the de-materialized reality of digital music, they spent years working on mandated inconvenience through DRM and other legal actions.

Isn't GPL and AGPL Copyleft another form of mandated inconvenience for companies? Come to think of it, many laws are mandated inconvenience with the stated purpose of correcting for some masked externality.

So what is an "open source VC funded" company doing? Creating complements and selling those. It's just that there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS. It's not a law of nature that e.g. Redhat should be the best people to provide consultancy on RHEL.

The historical record indicates that there are indeed network effects at play with communities of experts. However, the historical record also indicates that such effects on pools of expertise aren't powerful enough to create monopolistic single factions which can lock out all competitors.

every company operating as an "OSS startup" has to know from the start that their software can't be charged for directly.

All money made from open source really comes down to the application of expertise to do things with software. The ultimate question is whether software expertise itself can be commoditized.

(EDIT: Another way to phrase it: Is software an ouroboros? It's a snake eating its own long tail. Software keeps eating itself, but it continues the process by creating sufficient change to allow itself to grow as an industry. As time goes on, there are more experts needed. This then begs the question, "What could possibly cause that to change?")

> Open source software is by definition commoditized.

I thought commodity means something that can be produced by many different companies without substantial differences in cost, quality, functionality etc.

Open source software usually is siganificant in their complexity and utility. Also they have strong gluing effect to customers' own code.

To say they are commodity in the sense that they are free of charge, seems not the right way of thinking them as commodity.

You can't treat open source software as a commodity but you can treat any version of open source software as a commodity.

i.e. debian and ubuntu may not be interchangable commodities but ubuntu 16.04 from a torrent vs given from a friend vs downloaded from a mirror are interchangeable.

The services around opensource software such as troubleshooting or being able to spin up a server without having to supply anything but a password (and cash) are what makes a specific version differentiable, not who supplied the bits of that version. Since opensource is free and anyone can distribute it any 1 version is a commodity.

Agreed, the dream of a megacap open source company is dead. Mongodb shows this, the Unity fiasco (I'm surprised nobody has put the two together) shows this: https://news.ycombinator.com/item?id=18874400 Guys, charge for your work. Don't place the economic value of your company to be ancillary to your product. That just invites another company that has that ancillary as their core competency to come and do it much better than you while you waste time creating this free thing that other people free-ride off of.

More on unity: https://arstechnica.com/gaming/2019/01/unity-engine-tos-chan...

Here's the main difference between unreal and unity. Unreal costs 5% royalty per sale, meaning their product is extremely expensive to the developer if sales are high. Unity is generally royalty free and relies on "support and services" to make money. This is why Unreal will always encourage the growth of the ecosystem while Unity jealously guards the actual profit centers of the business, because Unity makes nothing on its core product!

Why would you expect a viable open source company to be a "megacap" anyway? The whole point of the open source development model is that, properly applied, it's more efficient and less costly than its closed-source alternative, while delivering significantly more value to its userbase. By contrast, the complementary services that an OSS-focused company actively sells (such as support) are in fact quite expensive. You wouldn't expect a support business to be "megacap", unless it actually manages to reach IBM- or RedHat-scale, which by definition very few businesses ever will.

The real competition is not Unreal vs. Unity, but both Unreal and Unity vs. e.g. Blender. (Which was actually funded as an open source project by its users, back in the day. But at a relatively low 'valuation', compared to Unity!)

> more efficient and less costly than its closed-source alternative

This is just not true in reality. Open source projects cost generally the same as closed source projects. Companies like mongo and unity employs about the same amount of engineers to work on it and the idea of high cost savings due to thousands of randos contributing code is vastly exaggerated. Same cost + no profit + having to develop a secondary core competency in a competitive commodity business like support and hosting = dangerous and non-scalable model.

Also never heard of a game using the Blender game engine...

> Open source projects cost generally the same as closed source projects.

https://www.linux.com/publications/estimating-total-cost-lin... (mind you, that's 2008 data. I couldn't find more recent estimates)

Mongo is quite unrepresentative here - not least, because they're selling the very same software (MongoDB) under both OSS and proprietary licensing! A better comparison in the database space would be e.g. PostgresSQL - the latest versions of which, BTW, are including "NoSQL"-focused features that make it quite competitive with the likes of MongoDB.

I don't know if blender is comparable at all. There's a lot more to a game engine than rendering, and AFAIK blender is not even intended for real time animation. Ogre is an open source 3d engine, although I don't know about its funding: https://www.ogre3d.org/

Maybe Godot engine is more comparable?

Yes, Godot is more comparable. And indeed https://twitter.com/TimSweeneyEpic/status/108347697531294925... does mention Godot

Blender has a full game engine included in it, although it looks like it's getting cut with the next release: https://www.blender.org/features/game-creation/

Blender 2.8 has removed the game engine.

https://www.blender.org/2-8/

Blender started as a closed source, venture-backed startup and was purchased and released to the community by a foundation set up by one of the founders when the startup failed. So it too was subsidized by corporate interests that ultimately saw no return on their investment.

> megacap open source company

Isn't this by itself an oxymoron? Open source isn't shouldn't be one's marketing stunt to gain attention, if you want to charge your software make it proprietary and charge people for license. Using open source as a last resort bait isn't cool.

My only jab at Amazon is that they should give back their code to the community or they need to be forced to do so, not that they can't make money from OSS software, if that is what license at the time, permits.

> Isn't this by itself an oxymoron?

Presumably that's why, in the words of the parent poster, the dream is dead.

The problem is the licenses suck. Parity and Prosper solve these problems with Parity covering your use case:

https://licensezero.com/

Those aren't Open Source licenses, so that's the same as the suggestion in the parent comment to make the software proprietary and charge for licenses.

Parity is an open source license that should achieve the goal of contribution sharing better than the others since it's wording focuses on changes, not distribution models.

https://licensezero.com/licenses/parity

It also has a patent license, unlike many permissive ones. They shouldnt even qualify as open source if you can get sued under patent law for using that software. Need some patent protection in license.

> Parity is an open source license

No, it isn't: https://opensource.org/licenses/alphabetical

A few issues:

> 3. Contribute software you develop, deploy, monitor, or run with this software.

That goes farther than the OSI, FSF, or DFSG allows, extending into software that is not in any way derived from the licensed software.

It's also not obvious from the license that it allows private modifications that aren't distributed to anyone.

> To contribute software, publish all its source code, in the preferred form for making changes, through a freely accessible distribution system widely used for similar source code

This requires that you publish your code publicly, rather than just providing it to those you provide binaries to.

license-review deja vu! To recite my views:

Parity conforms to the Open Source Definition as written. "Is it open source?" and "Has OSI approved it?" are related, but distinct, questions, as acknowledged by OSI process.

OSI-approved copyleft licenses already sweep broader than derivative works of the licensed software.

OSI has approved copyleft terms requiring contribution back of private changes.

Have you considered submitting for OSI approval?

Ok. So, you're using the technical definition of open source from that organization instead of the popular one I was using. That's fine. The goal of copyleft is supposed to get modifications shared. Parity does it better than any popular license. They all screwed up allowing people to dodge their goal. So, I'd say Parity is better at making open and free software than all of those. They need to update their requirements to match reality or just get results they say they're after.

That's less important than another realization I've had since we last talked about licenses. I've determined that most OSS/FOSS licenses actually oppose freedom in practice. You get less software freedom and high-quality software with source over time following those models due to their built-in weaknesses. I wrote specifics in one comment and a follow-up replying to Cantrill's recent analysis:

https://lobste.rs/s/0h98nl/it_s_not_okay_pretend_your_softwa...

https://lobste.rs/s/kbcjnx/open_source_confronts_its_midlife...

> So, you're using the technical definition of open source from that organization instead of the popular one I was using.

The OSD is the popular, widely used definition, as opposed to simply "source available". In general, I've found a roughly 100% correlation between people who try to say that "open source" should mean something other than the OSD and people who have a vested interest in pushing something that the OSD wouldn't permit.

> The goal of copyleft is supposed to get modifications shared.

Under an open source license. Otherwise it's just an incompatible proprietary ecosystem that happens to encourage sharing within its walls. That doesn't help or contribute to the open source community at all.

> They need to update their requirements to match reality

Proprietary software vendors come and go, and they often think that the requirements should change to accommodate them. The world goes on, and people whose requirements include open source licensing continue to ignore software that doesn't meet those requirements. This is not new; there has been a steady progression of custom non-open licenses that try to blur the line for just about as long as FOSS has existed. Long before there was "commons clause" and "license zero" there was Microsoft's "shared source". It failed then, and it'll fail now.

I've already seen a number of conferences this year with talks on the agenda about the problems of non-open licenses that attempt to pretend to be open, and how to work around them.

Regarding the comments you linked to, "License Zero" is even more blatantly non-open. And multiple people already provided detailed issues with those comments, to which I have little more to add.

"open source" is a bright true/false line for a reason, much like "non-toxic" or "food safe". If you want to build something proprietary, go ahead, but trying to pretend it's open is harmful FUD.

"Under an open source license. Otherwise it's just an incompatible proprietary ecosystem that happens to encourage sharing within its walls. "

Remember I shifted to talk about Parity license which forces all modifications to be shared regardless of intent or distribution model. As in, every change is available to anyone who wants it. Whereas, your open source licenses have led to many "incompatible, proprietary ecosystems" that used their code to build such things. Parity leads to more open code than open source given it tries to allow no loopholes to build walled gardens or hide code.

""open source" is a bright true/false line for a reason, much like "non-toxic" or "food safe". If you want to build something proprietary, go ahead, but trying to pretend it's open is harmful FUD. "

It's not, though, because it's built on a legal system that isn't true or false. Quick example where we'll apply a modern strategy to older times:

1. UNIX spread everywhere. Your goal is to make a UNIX application that every gets and benefits from under open source license. You do that.

2. AT&T sues you for copyright infringement. They claim API's are copywritable. They win. Your app is now illegal and you owe money.

3. They promise to sue other people who didn't buy app-building licenses from them.

Is your open source app really meeting the goals of open source if you (a) can't legally use it, (b) can't legally share it, and (c) anyone who tries might get sued? I don't think so. Next example:

1. 3G is invented. Some company patents it. Telecoms standardize on it.

2. Your goal is to write open-source stack for cellphones. Folks want 3G. You develop and release as open source a 3G stack people start integrating.

3. You and many of them get sued in patent courts that determine you're infringing on a patent. Note that patent law says you not only can't distribute patented works: you can't even create a duplicate. You have to stop distributing it immediately, pay damages, and, if wanting use to continue, negotiate a licensing package with them with upfront, annual, and/or royalty costs.

Is your open source app meeting the goals of open source if you (a) can't legally write it, (b) can't distribute it, and (c) anyone who uses it might get sued? I don't think so.

Now a big picture example. Microsoft and Apple use BSD-licensed code to help build their proprietary platforms that rake in billions of dollars. Then spend millions of that bribing politicians to strengthen copyright and patent laws in a way that facilitates lawsuits against competitors, including OSS developers or companies. They set things up so building compatible products is either illegal or financially dangerous. They also push for the patent laws to stay allowing broad, non-really-built inventions that exist only on paper to make lawsuits numerous and easy to win. The open source code has actually facilitated a reduction in software freedom across the board by sending piles of money to evil companies opposing software freedom who actively change the law to support their goals.

So, you have lobbyists, courts, and patent law attacking software freedom. Whoever has the most money on that gets more ground over time. The good folks maximizing freedom need piles of money to fight back (see Oracle vs Google). Within this environment, you are pushing licenses that mostly send money to the folks opposing freedom while only giving a trickle to those supporting it. You're also pushing licenses that allow them to hoard software in many cases that generates this wealth. Those licenses not only don't help the goal overtime: they erode it by giving the other side power and ability to build walled gardens. Obviously, something needs to change to reduce the fortunes evil companies can build off of software to send more of that money (or at least opportunities like w/ code changes) back to the good guys.

The loophole-filled licenses that you're pushing already led to laws and court rulings that worked against freedom. Folks were warned. FSF had right idea but tried to be too soft on commercial side. Look what happened. Now, you're still acting like the licenses aren't contributing to the problem while saying your goal is more software available with source for more people with less walled gardens. Parity forces source to always be shared with no walled gardens possible. I don't see how you talk about proprietary and walled gardens in relation to Parity if it makes them impossible, but the licenses you push already led to a ton of them.

I mean, feel free to reject Parity for any flaw in it achieving its goal of opening and sharing software. Just don't make stuff up like how forcing release of source code creates walled gardenes. Maybe you were thinking about Prosper, which is proprietary with its own benefits. Since you're an OSS guy, I was highlighting Parity since it's more in line with your goals. With no loopholes benefiting companies fighting against software freedom.

Fascinating to refer to "loophole-filled licenses", while referencing a license with no legal history of enforcement. Meanwhile, the GPL does have a long history of legal enforcement, and has successfully gotten code released on numerous occasions. What rulings are you referring to that "worked against freedom"?

Apart from that, this is nothing that hasn't been seen in every past "it's hard to make money on Open Source" argument. Meanwhile, people are busy making money on Open Source.

Please don't build random non-open licenses and call them open. If you'd like to call your license open, go get OSI to call it open.

"Fascinating to refer to "loophole-filled licenses", while referencing a license with no legal history of enforcement. "

They might come up with something. License Zero author has done a remarkable job of focusing on root causes and simplicity to prevent that. When he worries about commercial use, he says commercial use triggers the requirement. When he wants changes released, his license says any change has to be released. Use, changes, and combining with other works in an app are about as all-encompassing as you can get in a simple license. Whereas, Open Source and Free Source focused on linking and distribution which have plenty of complexity that corporate imaginations might work around. Which they did to tune of billions of dollars and plenty unshared improvements.

"What rulings are you referring to that "worked against freedom"?"

Oracle's API ruling, risk of patent suits, and next string of problems lobbyists and lawyers invent. Stuff would've been worse if we didn't luck out with giants IBM and Google paying for the legal battle. With [F]OSS-centered lobbying, we might have even got better laws and protections on these issues. [F]OSS sends most of the money to the opposition, though, with their main licenses and strategies.

"hasn't been seen in every past "it's hard to make money on Open Source" argument. "

I said you can loose money if they patent sue you or pull some stuff about API. These are real things in real court cases. I said it isn't really open and free to distribute if that risk exists. So, we have to mitigate it. I don't believe you when you say it's what open source discussions have always involved if my comments are the only ones I've ever seen here bringing this stuff up. Most comments about money and open-source are about making it profitable to the developers, not funding work in Congress and courts to protect our freedoms.

"If you'd like to call your license open, go get OSI to call it open."

I call mine shared source or source available per your prior advice on that. (Thanks again btw.) Prosper is shared source. Parity is free with source-sharing with maximum copyleft and some patent-suit protection. Looking at OSD, Parity appears to meet every requirement except No 9. That one specifically facilitates proprietary software and walled gardens built on top of or alongside open source code. Since Parity has copyleft for bundles, it can't be open source under that definition. Debian has that same provision, too.

It does have the four freedoms in a mandatory way that kicks in on any change, not distribution models or other guesswork. So, it's Free as in Speech Software that forces all freedoms to happen on derivatives of and bundles with the software with some patent protection. More freedom-preserving than OSI licenses in more situations. So, you're right that it shouldn't be called open source since those are less free and allow more corporate damage than Parity.

> [F]OSS sends most of the money to the opposition

That's where we fundamentally disagree. People who are building and contributing to FOSS are not "the opposition" just because they're large companies; on the contrary, it's a huge success story of FOSS that it's powering billion-dollar industries, both by supplanting proprietary software and by enabling use cases that don't even exist in proprietary software. The size of the whole pool is growing.

> I said you can loose money if they patent sue you or pull some stuff about API.

There are multiple licenses that address that, such as by including an explicit patent grant; that prevents the "submit code and then sue people who use it" problem. And there's absolutely nothing you can do to prevent patent lawsuits from people who aren't subject to the license, short of reforming the patent system (which, please, by all means do if you can).

And regarding API, similarly, some licenses include provisions that would prevent someone from suing over code they submitted, and beyond that you can't protect against people outside your ecosystem suing you or others inside your ecosystem.

> not funding work in Congress and courts to protect our freedoms.

There's a substantial and constant conversation going on regarding how to better improve laws to support FOSS.

> I call mine shared source or source available per your prior advice on that. (Thanks again btw.)

Thank you, I really appreciate that.

https://opensource.org/faq

Can I call my program "Open Source" even if I don't use an approved license?

Please don't do that. If you call it "Open Source" without using an approved license, you will confuse people. This is not merely a theoretical concern — we have seen this confusion happen in the past, and it's part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem.

Is <SOME LICENSE> an Open Source license, even if it is not listed on your web site?

In general, no. We run all licenses through an approval process to provide an accepted standard on which licenses are Open Source, and we list the approved ones. Be dubious of claimed Open Source-ness for licenses that haven't gone through the process. See also the license proliferation page for why this matters so much.

I recently published my first, draft attempt at an SSPL-style license, too: https://writing.kemitchell.com/2019/01/12/Shared-Component-L...

Don't think it has to be an oxymoron. Look at Red Hat: fully 100% open source code, but a multi-billion $ revenue.

> the dream of a megacap open source company is dead

    https://finance.yahoo.com/quote/RHT/
    Market Cap	31.055B
    S&P 500 Component

Or does this exemplify your point w/r/t RH for-fee bolt-on addons?

Red Hat does not have any "for-fee bolt-on addons", everything we ship is open source (or will be soon after acquisition of a closed-source company).

Responding to some of the other comments, Red Hat revenue is nearly all from providing enterprise support for completely open source software. This is critically different from "services", ie consulting. These are yearly contracts that provide clients insurance if/when they have a production issue, a new major vulnerability is disclosed, etc, that someone knows the technology from the ground up and also knows the details of their deployment and can get them back into a good state. Our support+engineering teams are top notch, so retaining customers year over year is relatively easy.

I work in Red Hat Consulting, which is a much smaller share of overall revenue. It doesn't scale nearly as well, since you only get revenue periodically for weeks to months at a time, with a lot of overhead to sell and manage assignments.

To say "everything" Red Hat ships being open source isn't quite true. There's a lot of proprietary code floating around, especially in the supporting infrastructure. When a product is put together, the upstream sources are bundled together and released - often behind the paywall.

Paul Cormier has it right - "We're an enterprise software company with an open source development model". Not an open source company.

However, you're correct. Red Hat's value prop is in top notch support.

The only software that redhat "sells" that is not open source is: RHN and insights. Former would be pointless to open, the latter is virtually a service offering anyway.

apologies -

I nearly added a parenthetical that these were typically open source under a different name if bolt-on (e.g. 389 vs directory, etc). will edit.

Is 5% supposed to be a lot? For that you get an entire game engine, which seems certain to save way more than 5% in total costs from not having to write one from scratch.

Steam and the major app stores take 6X that much (30%) just for distribution!

If Unreal is better than Unity, then it seems worth paying for.

5% is absolutely a fair price, even a great price. But it's a lot compared to free of course. For some games this is millions or hundreds of millions of dollars which is objectively a lot and hence *not worth it. Unreal is also not definitively better than Unity, which is really good. Anyway my post shouldn't be taken as a criticism of Unreal but rather telling Unity that they should be more like Unreal rather than the other way around.

> For some games this is millions or hundreds of millions of dollars which is objectively a lot and hence not worth it. *

I guess only when developing their own engine is cheaper for them.

Developing their own engine isn't the only other option, Unity's model where you pay a flat-fee for the engine regardless of your sales is another, and if the game is selling really well, that is a much cheaper option.

Not if Unity doesn't perform well enough for their needs I suppose.

It doesn't appear that there are any AAA titles made using the Unity engine though. It may simply not be good enough. The Unreal engine, by contrast, has many AAA titles built on it, including quite possibly the biggest game of all time, Fortnite.

> Don't place the economic value of your company to be ancillary to your product.

In other words: Don't do open core?

Dual licensing, more than any other common open source business model besides paid development, maintains the link between value of software produced and value for which customers pay. If a customer can't use the software under its public license, perhaps because the license requires release of code they want to keep closed, they pay for a license. The value of the software they become able to use, under paid license, sets the price you pay. Meanwhile, all the development work the vendor's people do goes into the product for which customers pay a price.

The article seems to imply that dual licensing is all or the crux of Mongo's business model, when it's only a relatively small part of their package offering. That can be hard to see, since both under AGPL and under the new SSPL, Mongo's choice of public license doesn't prevent developers from creating closed, proprietary applications using Mongo as data store. As they seem to intend it, Mongo dual licensing covers only platform developers who offer Mongo itself as-a-service to application developers. I hear tell the company has actually spent substantial time sending letters to users clarifying that they didn't need to buy a separate license to use Mongo in their closed apps under AGPL.

When you give money to redhat, you buy insurance that if you encounter a problem, they will support you. It is expencive, but there is clearly a lot of work involved in producing new release. IMHO redhat deserves its money.

When you give money to Oracle, you are financing lawyers who try to find the best way to make you pay more without improving the software.

There is lots of juice in Oracle SQL that even PostgreSQL is lacking.

GraalVM would never exist with weekend developers.

Top level JIT and almost non stoping GC algorithms don't get implementated with late nighters.

"IMHO redhat deserves its money". I agree. But the vast majority of people employ CentOS which is redhats derivative.

Oracle engineers work hard on java and deserve their money but the vast majority of people employ OpenJDK which is OracleJDKs derivative.

For a long period of time I regarded Oracle as absolutely undeserving owners of the JDK; they didn't write it, it was bought from Sun, they shipped adware in the installer, tried to sue Android out of existence, and were poor stewards of the language.

You wrote in the past tense. Did something change your view?

I lost track of the detail and am vaguely aware of a Java renaissance, but not clear whether that's real or whether Oracle are responsible or whether it's Clojure. So now I don't know whether I have reasons to hate Oracle. But I keep a little resentment warm just in case.

well, with openjdk nobody remembers oracle now. so I guess that changed.

if oracle wanted to continue to be the owners of Java they shouldn't have called their bluff and sued Google.

OpenJDK is mostly developed by Oracle employees. There isn't OpenJDK without them.

Oracle did the right thing against Android J++.

Exactly. I avoid Oracle tech or products for all those reasons plus the fact that dollars to them support their lobbyists and lawyers. Those keep trying to undermine software freedom (esp API ruling) and patent troll successful companies. I refuse to support that kind of company. So, I tell people about EnterpriseDB being Oracle-compatible and cheaper. ;)

Oracle is in the Java world since the early days, they even collaborated with Sun on the whole Java workstation idea of the Network Computer. They used to have their own JVMs.

Also only IBM cared to make an alternative offer to acquire Sun, during the initial round.

The adware contracts were done by Sun, not Oracle.

Google has managed to create Android J++, and as Java developer that cares about the integrity of the Java platform I stand by Oracle.

OpenJDK is a pretty significant rewrite of the Sun/Oracle JDK to stay open and completely GPL.

CentOS is more of a repackaging of Redhat -- the binary files are almost exactly the same there so the comparison isn't quite valid.

You're thinking of GNU Classpath, maybe?

OpenJDK is (a subset of) the Oracle JDK.

> OpenJDK is the official reference implementation of Java SE since version 7.

and https://en.wikipedia.org/wiki/OpenJDK#Release_of_the_class_l...

> OpenJDK is (a subset of) the Oracle JDK.

Not anymore. With Java 11 it is entirely the same code, at least until somebody takes over maintenance of the Java 11 branch from Oracle in two months.

Except now you're paying IBMs lawyers ;)

> It is hard to imagine [AWS, Microsoft, and Google] ever paying for open source software.

It's surprising that someone setting out to write about the changing economies of open source ends up missing the point so thoroughly. These companies are some of the biggest contributors to open source.

What they aren't likely to want to pay for is a site license from some company trying to sell them a MongoDB under terms practically identical to what Oracle does for Oracle DB. That's the "CD" model the article could make a comparison to.

I don't think we're ever going to have something like an open source version of the Oracle model that's equally sustainable, just like the notion that you're going to buy an entire album to listen to one song isn't coming back.

Rather, open source is going to be something where you might run a database like PostgreSQL, and if you're a big enough user contribute to its development, either yourself or by paying some support company of core devs. That company might also provide support, or you could go with another provider for that etc.

I agree. It's important to point out specifically that many companies are paying for OSS with developer time instead of money. IMO, that is better than money and fits the OSS ethos.

> IMO, that is better than money

IMO, it's not. SF developer time is hella expensive, and OSS projects can hire developers on their own, somewhere cheaper. Where a software company can help OSS cheaply and effectively is by providing support for interoperability with their own business area, and by relicensing their existing, non-core-business IP under favorable terms.

> OSS projects can hire developers on their own, somewhere cheaper

A lot of the bigger OSS projects require an expertise you're not going to find outside of megacorps, because they have internal scale/process problems/otherwise that necessitate interesting problem solving

Also large companies often value creating documentation and other "admin" much more than individual developers - individual developers appreciate this admin work having happened but often detest doing it themselves, where for a decent company the value of a smooth skills transfer process is more obvious and baked into the culture.

This is far from always the case, of course, but projects that get a lot of input from commercial entities often have documentation that is more complete and (more importantly) more accurate/up-to-date than those that don't.

> These companies are some of the biggest contributors to open source.

I wouldn't expect AWS to make a lot of code contributions to MongoDB when they've built something else that's 3.6 compatible, though. It's not like they're going to make contributions to a new, incompatible version of MongoDB. They've already made the call to fork.

I agree with what you're saying about other products, but not this particular case.

Well yeah, that's the point. MongoDB's business model before was trying to sell Amazon CD's. Then they turned the screws on that and switched to an even more onerous license that a company like Amazon wasn't going to accept, so they wrote their own replacement.

If it's an economic lesson in anything it's that companies and individual open source users alike are going to be a lot more careful about using any project where one for-profit company demands copyright assignment and can re-license the project at any time to squeeze existing users.

MongoDB's bet was that they had enough of a moat that Amazon et al would fold up and accept their new terms, that was obviously miscalculated, but there still might be other similar cloud companies who'll fold.

But both Amazon and other users are going to be a lot more careful in the future to not run critical infrastructure on some project that's likely to be subject to a future bait & switch by upstream.

It isn't a fork, it's an entirely new database that implements the same API.

c.f. https://twitter.com/nathankpeck/status/1083385031207387136 from someone at AWS DevRel.

There's nothing about Mongo's license that's super relevant here -- it's a similar situation to other cloud providers offering "S3"- or "EC2"-compatible APIs.

(IANAL, but AIUI API copyright/fair-use isn't entirely settled in the US, Oracle v. Google nonwithstanding, since 9th Cir. isn't per se controlling precedent nationwide in copyright matters)

Also important is the API that AWS is compatible with was itself part of the OSS licensed code of an old version of mongo. Oracle vs. Google is different as Java was never OSS licensed.

I'm not sure how much AWS contributes back to Redis or Elasticsearch, but in this case, MongoDB has already made the decision for them. AWS certainly won't be contributing to MongoDB, but it's not on AWS from now on.

> These companies are some of the biggest contributors to open source.

It depends how you look at it. Take Kubernetes for example, Google open sources it, but there is a caveat, it's not really useful without all the necessary complementary services, that Google happens to offer you. Or take Android, exactly the same problem. Sure, there are some things they truly contribute to open source, but even among them a lot are not necessarily useful outside of those companies and are contributed purely to reduce costs or worse, to gain control. All of this is very different from Redis contribution for example. They never do things like that.

> What they aren't likely to want to pay for is a site license from some company trying to sell them a MongoDB under terms practically identical to what Oracle does for Oracle DB.

You are missing the point. MongoDB never wanted to sell a license to Amazon or to anyone trying to compete with their own hosted offering. Same goes for any company trying to make money through SaaS. So it's not just unlikely, it's by design. And Amazon making their own implementation is expected outcome of this. Although I suspect no one is going to repeat MongoDB's mistake and release client libraries under permissive licenses after that. Next time Amazon tries to reimplement something, it won't be as drop in of a replacement, as it is now.

> These companies [AWS, Microsoft, and Google] are some of the biggest contributors to open source.

True, but their contributions are quite selective. Google writes very good infrastructure code. However OSS DBMS services are quite different. They tend to originate in companies with data problems. Sometimes that's a company like Google or Microsoft, but more often it's a company like Facebook that has an issue processing a lot of data.

BTW I'm not so sure AWS counts as a big OSS contributor. They use it but don't really make a lot of contributions back. This may change over time.

Disclaimer: I work at Altinity, which offers support and software for ClickHouse. (Incidentally written by Yandex to process their clickstream data.)

Honestly at this point I would rather use Closed Source software than Open Source that isn’t “Free as in Speech”. It’s a wolf in sheep’s clothing. At least closed source is honest about its intentions.

I use Free Software not because the price, but rather so I can be Free. So I can know I am free to use software I develop with it in whatever way I want.

I find the push to market open source by limiting it’s use one of the most distasteful things in recent software history.

No. The best is the enemy of the good. I do not want to live in North Korea rather than (say) in the UK, because at least the NK government is honest about its intentions.

Really, it's simply not Open Source software, that's nothing more than a marketing lie, so we should stop calling it that.

The open source that you call "isn't free as in speech" is actually Free Software. You are able to develop with it in whatever way you want. The requirement is that whatever you develop is also Free Software and is distributed whenever it is used. This is what Stallman has in mind when he talks about free software. Your freedom to develop above free software developed by others cannot come at the cost of others' freedom to develop above your software that has enjoyed the fruits of said freedom.

This distinction seems highly misleading. Free is not free if it comes with a litany of restrictions. Licensing concerns pretty much blacklist a swath of open source software for actual use in a business context. Sure, many companies are willing to open source their developer friendly projects. Microsoft with VSCode is a great example. Same with Atlassian's contributions to complex open source UI components. Frankly, these are not done as revenue drivers, but instead as recruiting tools and ecosystem builders. Those benefits are ancillary to the core competency of the parent company.

It does not make sense for companies to open source all of their code. It's far too easy in today's world to stand up a highly reliable, performant and scalable SaaS application. Protecting the code behind a SaaS application allows companies to grow and protect themselves at an early stage. IMO this is a significant benefit to the open source community given the open source contributions that established SaaS companies tend to eventually move into.

"Free" software is not free at all if people are unable to use it in their systems for fear of legal repercussions.

Yes it is confusing but that's what Free software means in the original incarnation when Richard Stallman coined it: https://www.gnu.org/philosophy/free-sw.en.html

So you prefer the BSD licensed software ?

MongoDB's new license does not in any way prevent you from using MongoDB in whatever way you want. It simply requires you to, in some cases, release the changes you make to it publicly. You know, like the GPL did before companies found that a SaaS model let's you side step the release changes requirement.

>* like the GPL did before companies found that a SaaS model let's you side step the release changes requirement*

Unless you use AGPL where the trigger for releasing your modifications is making the change available by any means (direct or otherwise) rather than with the standard GPL where the trigger is distribution of outputs compiled from the modified version.

MongoDB did use the AGPL and still had issues with companies trying to argue they didn't need to release their changes. So they switched to their own license which was even more explicit on the matter.

What problems did MongoDB run into? Can you link to any specific instances?

I think it was specifically Amazon not releasing their changes.

Maybe AGPL would cover them and force the release, but if Amazon stuck their heals down it would be an expensive legal fight. My guess is that it was just easier to change the licence used going forward to one that is more explicit and unambiguous about the matter.

It was my understanding that AGPL was supposed to cover this specific type of use, so would also be interested in know if there is a real problem or if the licence change was simply to make the point without needing to go lawyer-to-lawyer with someone in possession of Amazon's resources.

I'd actually be kind of surprised if Amazon did actually use it - most of the big tech companies are allergic to AGPL, and e.g. Google does not allow it to be used at all, even internally.

> I'd actually be kind of surprised if Amazon did actually use it

They did, which is how this discussion started.

Until 4.0.4 / 4.1.5 MondoDB was released under the AGPL licence. Upon those releases it switched to SSPL (which IIRC is APL plus extra "commons clauses"). Amazon have stopped using MongoDB as they do not want to (or for some reason are unable to) abide by this new license, but had previously been happy to use the code under [their interpretation of] AGPLv3.

I haven't seen a source clearly saying that Amazon had been using MongoDB - I thought the DocumentDB release last week was the first MongoDB product they offered?

EDIT: and searching HN comments, there's multiple people claiming AGPL is entirely banned inside Amazon too

In which case I don't see why this is such a big issue. Amazon couldn't use it before the change because of their licence use policy, and can't after the change either. So the change represents no change in that respect.

Implementing an interface compatible with something that you can't use for licensing reasons is no biggie. Other projects, Free/free/OS/commercial, do that sort of thing all the time.

I wonder where the problem that drove the change actually was... RH dropping it from their distro is an issue related to the licence change, but I don't get the impression that was the intended target.

I should probably find time to dig back into the details, as I feel I've missed something notable.

>What problems did MongoDB run into? Can you link to any specific instances?

MongoDB does not specify, to quote their FAQ on the new license:

>As a result, we have observed organizations, especially the international cloud vendors, begin to test the boundaries of the AGPL license.

I am happy to see someone mention freedom in this thread. I believe the term "open source" distracts from the more prescient issue of user freedom.

One of the issues with SSPL is that it intertwines the ideas of an AGPL style copyleft with an allowance for SaaS use cases, specifically in section 13 of SSPL. I would argue this is more pernicious than an openly proprietary license for precisely the wolf in sheep's clothing reasoning you mentioned. People adopting MongoDB and its endorsement of SaaS may believe they're supporting the values of "open source", but they're sacrificing user freedom as Stallman points out in this blog post.

https://www.gnu.org/philosophy/who-does-that-server-really-s...

It is a good read, with good insights. The conclusion - "This tradeoff is inescapable" is true only to the extent that a new model for open source does not arise. Stepping back a couple thousand feet, open source is an amazing thing - a bunch of people alone or in collaboration, building great things which other people then use to build other ... etc. If we can find a way to sustain this it would be great.

It is to me absolutely clear to me that Amazon is benefiting from the work MongoDB has done, and without commensurate compensation. (Is anyone proposing Amazon does not benefit?) And having watched Microsoft embrace, extend and extinguish way too successfully, it is at least a concern that the effect of Amazon's action will be to the long term detriment of MongoDB.

This to me is the problem that must be solved. One possibility is to modify the OSS model and licenses by creating a distinction between the members of the community and non-members like Amazon and Apple. If you want to use any OSS software (with the new license) then you must become a contibuting member of the community. If you don't want to be a member, then NO OSS software is available to you. In other words, Amazon could not pick and choose which OSS to use, but only to be a member of the community with all the benefits or not.

I'm not saying this is the answer, but I am saying this is the problem we need to solve.

OSS is an ecosystem - one that should and must protect itself from predators.

Isn't it what GPL is about? Forcing users to follow the rules of the club?

It makes sense why orgs choose not to use GPL software, though. For those reliant on proprietary tech, it's a loose thread in a knit sweater.

I worry that backing orgs like MongoDB are being punished by their position, to the extent that their ability to operate will cease, which will hurt that project potentially.

So in essence, GPL has a problem, whether or not it is the problem.

I see arguments like this a fair bit, and I'd like to explain why I'm not at all convinced.

Your position is entirely predicated on the assumption that we must protect Open Source companies above the freedom of users/developers, which does not fit my beliefs on what FOSS exists to do.

If MongoDB Corp goes away because everyone is using the AWS version, I would be sad to see an Open Source company end, and would feel bad for the people who lost their jobs, but I wouldn't rewrite the licenses to be Open Source Except Big Bad Cloud.

FOSS licenses exist to encode a somewhat overlapping set of moral philosophies, and if a particular company (or companies) aren't able to monetise around those philosophies, they have made a strategic mistake of some kind.

The response to this should not be for the VCs behind these companies to dilute the essence of FOSS until it can be used to trap users/platforms. That would lead us to a world where we have replaced the monopolies of proprietary software with monopsonies for "open source" companies, and I have zero interest in that world.

Good points, and I may not have said this well, (and here's the obligatory but ) but... - I am not proposing to "protect OSS companies over the freedom of ...". Rather I am attempting to explore a way to provide a boundary between the entire OSS community (users/developers, etc) and those companies that attempt to exploit that community. As others have pointed out, there are many companies that make a contribution to open source on a generous basis - Microsoft, even FaceBook by golly. - I don't think the distinction there is "Big Bad Cloud", it is between those who help build and maintain open source and those who exploit it.

The goal to me is that the people who have created the incredible thing we call OSS should have a reasonable expectation of sharing in the benefits.

I would love it if more companies would get involved with FOSS communities, either by sponsoring work, or getting involved directly, but I would still argue that it's against the spirit of FOSS (and the letter of most licenses) to try and force them to.

When we choose to put our software out in the world under permissive licenses, we can't really turn around and complain when people make use of it in ways that are beneficial to them. On that basis, I object to the use of the word "exploit" in its negative sense.

Edit: I'd like to add one thought - there are different groups of people who could benefit by greater engagement from large corporate use of FOSS. Two that come to mind easily are the funded startups trying to find viable FOSS business models; I admire their optimism and their goals, and wish them luck. The second is individuals and small groups who tirelessly maintain incredibly important things that the rest of us take for granted and have to fight tooth and nail for every grant, every hour of their own spare time and every hour of their employer's time, to keep those things going for us. If I have to choose a group to care about supporting, it's definitely going to be the latter, for whom I have immense respect, undying gratitude, and sadly insignificant donations.

I agree your sentiment in general and especially with the last sentences ... It is one of the reasons I'm interested in trying to find some way(s) that we ensure they (the individuals and small groups) have some appropriate reward and that they are not exploited. I'm really not familiar with mongoDB and I don't use it, but I suspect that it started out as a person or small group that grew and grew and helped many people until ...

But perhaps exploit is too strong a word? It certainly seems that at least Amazon is acting as a bad citizen in this case by taking more than they are giving back. And it is within the realm of possibility that they will damage this project - the EEE syndrome is one possibility.

But yes to the respect, gratitude and sadly the insignificant donations as well.

Not to detract at all from your point, but Mongo (10gen) was very, very well-funded out of the gate, and the original idea was a platform-as-a-service built on open source apps before they pivoted to the open source database idea.

I work on an open core business model, and we spend a fair amount of time thinking about ways to prevent third parties from stealing our lunch.

CockroachDB has an interesting model, where they've tried to closely couple their open source and premium products. This coupling makes it harder for third parties to build against the open source and even easier for enterprises to use it.

Do people here have examples of companies that are taking innovative approaches to the licensing/OSS question?

Elastic? They basically build a lot of extra (and very useful) functionality outside elasticsearch and sell that.

They still suffer from the same problem: AWS is selling it's own elasticsearch service. It comes with a set of severe restrictions and is way less capable than elastics own offering, but it's improving and I see it used more and more often.

If Amazon doesn't want to pay for your product they are not going to. They will just (re)implement it themselves with a compatible API. Even if MongoDB was a proprietary product with an Oracle-style pricelist Amazon still would have done the same: Reimplement it with compatible API.

Then again the reverse is also true. Just look at all the software providing an S3 compatible API.

Well, Google (or rather, the original Android) did that to Oracle with the Java API, and Oracle, being Oracle, sued.

But why did Red Hat succeed then? (this is a genuine question, I'd have guessed IBM would re-package RH's products, and Oracle failed with their Unbreakable Linux)

I think it is because Red Hat sold support and training.

I think RH's longevity meant that it was already in a stronger position. There was also the kernel build obfuscation that happened to supposedly twhart unbreakable linux from taking everything wholesale.

Red Hat sell enterprise services and solutions. The Linux distro is more of a delivery mechanism than a core product itself. IBM could very easily repackage and sell Red Hat's offerings, though IBM can only do so much when it comes to supporting those offerings, as they are not in control of what Red Hat themselves do next. They could also, of course, take a similar approach and create their own, which to some extent they actually do.

Red Hat did a smart thing and used their open source offerings to deliver business value outside of the product space. It's an approach that most other successful OSS companies seem to have have followed.

To put it succinctly, Red Hat doesn't sell Linux, they sell expertise in Linux.

Arguable this is what MongoDB, Inc. sells as well. A big part of their package for enterprise clients is optimization and consulting services.

Then they should be as successful as RedHat. Or maybe their niche is too small and the people in that niche don't need the consulting part.

Consulting is not the main driver of Red Hat revenue, the main thing Red Hat sells is Support.

Support is something enterprise customers want, and they will sign yearly contracts to get it. In return, if/when they have a production issue, 0-day vulnerability, etc, they have someone to contact (or may have contacted them!) to help them resolve the issue. And Red Hat has experts in both support and engineering, meaning resolution can be anything from a config change to a rapidly released patch. Happy customers renew year after year.

I work for Red Hat Consulting. This is a very different beast, consulting involves selling lots of short to medium term projects with the occasional long project, then trying to optimally staff those projects. You only get revenue while consultants are on the ground. It's not surprising to me that an open source company that relies only on consulting wouldn't be sustainable.

The big difference between Red Hat and a lot of these other companies is that if you look at a lot of their products, including the cash cow (RHEL), there is not a 1:1 mapping between the product and a single open source project.

Rather they create enterprise distributions that are made up of a number of open source projects that are (ideally) integrated into a solution. This combined with the right investment in support and training provides a product that is more compelling than "we provide a signed version of $UPSTREAM_PROJECT". I would say OEL is successful for the amount Oracle appear to invest in it (not much).

Timing helps a lot too though, in that they had a lot of success before the advent of the public cloud so are in a better position to weather the storm while they figure out a new model.

Because they are basically a consulting firm just like Accenture or IBM. They sell their expertise / charge big rates for having their experts work on projects.

Bezos and AWS happened. As most of the new growth is coming from cloud particularly for newer stack of projects, the company will have to compete with big 3 providers, who have much better economy of scale, complementary revenue streams and miles deep pocket. If launched today, Redhat would have to compete wit Amazon for maintenance of RH linux vs AWS linux which is done for ~free.

Re AWS Linux support, ~free is about right. You do pay for it. At enterprise levels, you're paying a percent of your total bill for support. That can be significant.

https://aws.amazon.com/premiumsupport/pricing/

But with it you generally get very quick responses to issues, and if your bill is enough, you get a technical account manager who gets paged when you open a ticket. They handle many things, but I believe AWS Linux is in that list of many.

Having the Technical Account Manager is quite valuable.

I don't know if it's innovative, but you can look at https://www.nexedi.com/. They are open source, you can find all their projects on their gitlab: https://lab.nexedi.com/nexedi.

They are selling services and the fact that you have to understand a lot of their tech before you can even contribute (let alone "steal") help a lot.

I think Citus Data is doing something right, they have an alternative to AWS RDS and some additional features. It still runs on AWS, but I think everyone who has tried to run PostgreSQL RDS on AWS has seen how slow it can be. A consumer grade laptop can be 10x-100x more performant than a cheap T2 medium RDS instance.

Managing your own PostgreSQL with HA and replication is a ton of work. And for many small to medium sized companies, using a hosted service makes sense.

But open source has a problem today, there is a huge lack of contribution in some projects. The older the project is, the more it seems to struggle.

Timescale just recently released a new license to complement their open source offering: https://blog.timescale.com/how-we-are-building-an-open-sourc...

Almost exclusively designed to deal with the issue described in the article, of preventing public clouds from running this as a service.

They also published another article about how to make money as an open-source company: https://blog.timescale.com/how-open-source-software-makes-mo...

I'd like to think we're doing something new at Ionic, primarily because we're frontend rather than backend focused.

One big part of our business now is licensing Native SDK connectors/libs. For example, secure authentication that utilizes biometric auth and keystore/keychain functionality. Those aren't open source but any serious enterprise needs that if they are building an app with the open source Ionic Framework, and our target developer has no interest in writing native code to do this themselves. This is also interesting because enterprises are actively wanting us to build, support, and license out key client-side functionality for their apps.

That alignment of free for the community with addons that only make sense for the enterprise has worked well for us so far and I believe the frontend focus keeps us far enough away from the "hosted OSS" problem described here for Mongo.

Android is an interesting case. AOSP is open source, and the OS allows for services that you expect from a smart phone to take any implementation.

Google keeps control by holding on to the best implementation of services, as well as controlling the ecosystem with developer services.

Amazon has shown that Android is still an open platform but the work involved to overthrow Google would be a massive undertaking.

Mostly FUD of a supposed opensource monetization debacle on the aftermath of Amazon DocumentDB.

Not every opensource monetization scheme is the same. Mongo and Gitlab are not the same. One is mission-critical production software, the other is a productivity tool (which can become critical, but in a different manner), thus different ways to monetize. Hashicorp, Canonical, Mesosphere and NodeBB are not nearly the same. Why put everyone on the same pot?

Opensource is not an industry. Opensource is a guarantee, a certificate of transparency. Opensource is global-scale collaboration. And much more.

Neither is everyone moving everything to fully-managed PaaS, at least not in the way described by the OP, who assumes a lot of givens there. Many use cloud infrastructure, but not all the services, some have private clouds or other hybrid setups.

Application platforms are constantly changing, why now assume Mongo or any other opensource models are doomed? MongoDB Inc. is a public company and is perfectly capable of defending their bottom line against a magnificently sized but over-committed competitor like AWS. Mongo has NOT done a good job with their PaaS or enterprise tooling so far, competitors have popped up, so now they have to up their game, that's all.

To underestimate OSS monetization is very presumptuous. To compare musical recordings, an end to itself, to infrastructure mission-critical software is downright stupid.

I don't like the assertion that the only thing that was valuable on CD's was the convenience, not the music. I'd argue that the copyright itself is the reason the music industry had pricing power. As everyone knows, they lost the pricing power with the rise of piracy platforms and it became too costly to try and keep the market cornered as services like Spotify and Pandora started to make deals with several labels. At some point the major labels had to throw their hands up and and capitulate. It's worth noting however, that the most powerful artists- people like Taylor Swift and Garth Brooks retained their distribution rights and did not capitulate for a long time. This is further evidence that the copyright is what creates the shortage that creates the pricing power.

It's really no different from the pharmaceutical industry. The cost of making the first pill of a new drug is billions of dollars. The cost of the second is basically zero. Yet drugs are extremely expensive because the companies that develop them have complete pricing power for several years because nobody else is allowed to manufacture that drug.

I think the point he's making whether directly or indirectly, is that MongoDB made a miscalculation in open sourcing their software at all. I would agree with that except that one would have to wonder whether there is anything so unique about MongoDB's software that would enable them to exert much pricing power. In other words, would MongoDB risen to the level popularity they did if the software was not open source?

MongoDB is choosing a dinosaurs business model, and it's going to hurt them and their ecology.

Mongo the org should play MongoDB like Google does Kubernetes, Golang, Chromium, etc. Have your people in there, funded, steering the project as 'FOSS' while you release actual products.

Mongo dropped the ball by having no on-ramp product like GCPs Firebase. Their Cloud provider hate is just a flailing reaction to bad business and existential fear.

Stop being a crybaby when someone makes a few forms and buttons that spins up a vm with your DB software running. Of course cloud providers would want a tight integration with their systems.

Managed Kubernetes on AWS makes k8 stronger, managed Firecracker on GCP and Azure makes Firecracker stronger.

The article mentions that MongoDB already has its own hosted database service, Atlas.

It does, I've used it, I even have the socks, but it's a managed Database product. It's not equivalent to Firebase, AWS Lightsail, Digital Ocean One-click, etc. So a new MERN developer isn't going to gravitate toward that.

It's more like AWS RDS for MongoDB.

https://www.mongodb.com/cloud/stitch

Agreed, and I was downvoted to oblivion a couple weeks back for saying as much.

> Stop being a crybaby when someone makes a few forms and buttons that spins up a vm with your DB software running

Sure, but that's not what Amazon did. They implemented the API. It's not MDB behind it. (A few HN comments from awhile ago seem to think it's some flavor of PGSQL.)

I think Stratchery made a mistake in think this is about open vs closed source, but rather it's down to Amazon's desire to own core infrastructure.

Amazon wants to have an offering in every major database category. Whether you're open source or closed source, it's safe to assume if you get decent marketshare Amazon will come after you.

Even if MongoDB was proprietary Amazon would have built a competitor in this space.

This whole thing is a race as software itself gets better and better. Just think about how hard it was to run things 5 years ago before the rapid rise of containers and orchestrators. One person with Kubernetes can easily run a large cluster with hundreds of applications, even with private owned hardware. And this is all free now.

Being ahead of the curve with proprietary products is a viable business but just not as big as these companies want it to be. Meanwhile there are thousands of smaller boutique software firms solving problems and making great profits.

Why can't MongoDB can't compete with AWS? Aside from cloud vendor lock-in, and economies of scale that AWS has. Curious if anyone here has experience with hosting using Mongo's enterprise offering. The article makes the point that Amazon is targeting a lower version of the API, can't the enterprise version compete on features?

MongoDB is competing with AWS. Atlas actually runs on top of AWS - Mongo is capturing the spread between their per-instance charge and the AWS charge (or GCE/Azure). What this article ignores is that Atlas is actually competing quite well and has significant adoption. The people who run MongoDB are not dumb, they will try to turn the hosting in to a commodity before Amazon can turn the DB in to a commodity.

I know nothing about MongoDB pricing, but it’s possible that Amazon is taking a loss on DocumentDB to keep companies using solely AWS products, while MongoDB Inc. obviously can’t do that since they have no other revenue stream. So the competition might be both convenience and price vs features. Features sounds likely to lose that battle.

Very possible. They do it with retail too to conquer the market. Very successfully because they have laziness on their side.

You can bet that they don't care about some millions for development. On the contrary, it will help saving taxes.

Amazons behavior has been an amazing long-term, something many companies are thoroughly lacking.

Other than multi-document transactions, many of the changes to MongoDB since 3.6 are to do with performance and scaling - this is AWS' bread and butter.

Something to consider is how many applications depends on cutting edge database features. Developers often consider a database an object persistence mechanism whose details are to be tidied away. See, for example, the emphasis on database portability in ORMs.

MongoDB's most effective enterprise offering is support, in my opinion. They know their database well, which can make a big difference if your company is heavily reliant on it.

I suspect for many users though, AWS support will be good enough. Presumably, that's the danger to MongoDB.

In the spirit of complete transparency, I work at MongoDB. Depending on users' specific needs and the features of MongoDB they use, the differences could go quite a bit further than 'just' support. Some of the important differences to keep in mind include regional availability and approaches to resiliency (Atlas allows you to scale beyond a single node and offers multi-region clusters; DocumentDB limits you to a single primary), role-based access control (DocumentDB currently only supports user that has full access to all databases in a cluster; MongoDB allows fine-grained control), freedom from vendor lock-in (With MongoDB you can always choose to host your own clusters whereas DocumentDB does not afford you this option). These are only a few of the differences between the hosting platforms, on top of that, you would, of course, be limited to an incomplete set of features (https://docs.aws.amazon.com/documentdb/latest/developerguide...) compared to MongoDB 3.6 and you would be missing out on improvements available in MongoDB 4.0 and future versions.

I would not underestimate those two advantages. Even Microsoft and Google are getting outpaced by them overall. It might only be that Amazon competes with so many companies anymore that they choose the second and third place solutions.

Why can't MongoDB can't compete with AWS? Aside from cloud vendor lock-in, and economies of scale that AWS has.

That’s kind of the point. If you want a managed service, Mongo can’t compete at the scale of AWS.

And by definition, if AWS is offering the same API, there is no “cloud vendor lock in”.

MongoDB certainly can compete at scale with AWS with MongoDB Atlas - Managed Database as a Service.

By hosting on AWS, Azure, and GCP...

And even then they don’t host your database in your own VPC which is a big deal to some companies.

But with Atlas, you can VPC peer if you need that level of security and performance between your app and database. https://docs.atlas.mongodb.com/security-vpc-peering/

I agree with you. But, some security folks still don’t think that’s good enough. These are usually old school on prem security guys who don’t really get cloud.

> Why can't MongoDB can't compete with AWS?

IMHO, it's the need for single pane of glass management, coupled with single throat to choke accountability. Buyers are often willing to give up on best-of-breed features/performance/cost in exchange for simplification of process and workflow.

I find it interesting that the price of storage has essentially flatlined for the past five years, although the cost of hard drives have decreased by about 50 percent over that same timeframe dollar-per-gigabyte (https://www.forbes.com/sites/tomcoughlin/2017/12/20/digital-...).

Innovations at the 'business' layer may be the best way to compete with AWS, in the way that it captures a large chunk of value generated through OSS. Decentralized cloud platforms essentially take the principles of open source and apply them to the very infrastructure on which software runs.

At Storj, for example, we have an Open Source Partner Program that attempts to solve the ‘Amazon Problem’ by enabling any open source project to generate revenue every time their end users store data in the cloud.

Storj tracks usage on the network and returns a significant portion of the revenue earned when data from an open source project is stored on the platform. Critically, this enables open source projects to derive sustainable revenue from usage, whether by commercial customers or non-paying open source users.

In my opinion, this can help drive and support the next wave of Open Source monetization models (essentially through this concept of 'Commoditize Your Complement" - where the complement is cloud consumption)

Perhaps this is a good idea in theory, but it’s lacking in implementation. Having used Storj in the past, I’ve found it to be the least reliable service I’ve ever used. The SLA excludes events beyond your control, which sadly includes the availability of your storage network. I wouldn’t say this solution is even close to being production ready.

Storj has spent the last year rebuilding the entire network after hiring JT Olio (Director of Engineering) Ben Golub (Interim CEO, previously CEO of Docker).

The V3 Network is leaps and bounds more performant and economical than the V2 Network. It is compatible with the S3 bucket-object store and is an easy shift for applications already using S3 as an object store layer. You can speed test it vs S3 using the ./cmd/s3-benchmark tool in our distro.

Try it out for yourself: https://storj.io/blog/2019/01/getting-started-with-the-storj...

Amazon has for years been stealing from merchants on their platform and AWS is just another part of their platform. They are everything we caution people against when they depend on a single API like being a superfluous Twitter client getting crushed, just a much, much larger API.

In Mongo's unfortunate case they couldn't stop people from deploying to EC2 before Amazon determined it was worth stealing, but it doesn't even have to be software you use on EC2 it can be your software too.

They copy products from third party vendors selling on Amazon -

https://www.bloomberg.com/news/articles/2018-09-27/amazon-s-...

http://fortune.com/2016/04/20/amazon-copies-merchants/

They even copy SaaS hosted on AWS if the number are good -

https://www.theregister.co.uk/2013/03/08/amazon_copies_partn...

[Meta warning] This comment is being downvoted because of the incendiary language, but it is actually quite insightful. I wish the author changed some of the words used :(

Michael from MongoDB here. Amazon, Microsoft, and Google are certainly big players in this field, and common wisdom is that they are best qualified to scale, but in this case, we have a clear counterexample. DocumentDB clusters are limited to a single region of AWS. MongoDB Atlas clusters can span the entire globe with low-latency reads and writes in multiple regions. In terms of pricing, DocumentDB is cheaper when you choose to go with 2 instances. AWS achieves this by shifting high availability to the storage layer which in turn means that any failover could require between 1 and 2 minutes to happen - this compares to seconds that this would take with MongoDB Atlas. If you go with the default DocumentDB configuration and use 3 instances you end up paying a premium between 20-35%. With this in mind, it really depends on your use case whether DocumentDB ends up being cheaper for you. In terms of reliability and the hosting service is global, Atlas currently outperforms DocumentDB.

This discussion is new because AWS and others are new and growing rapidly and it's a huge mistake to conflate it with conventional discussions and strategies about open source.

The threat is not just to open source but also entire categories of software and hardware.

The situation is so dire that you may create a product that does 10Gbs or something else and AWS offers 5Gbs but with automatic snapshots, high availability, scalability and distributed out of the box, and because of ease of use, access, near free management and scale users will still prefer AWS and your market will be limited to a extremely tiny subset requiring some specific niche and willing to configure, roll it out and maintain on their own.

This completely changes the incentives to create, because to compete you now need to create a 'cloud native' product that leverages AWS and other clouds. Which means a transformation of traditional open source and entire categories of software as we understand them to something new.

How easy is it to migrate to or away from a cloud service like AWS ? I think the end-game for these cloud giants is to lock you in, so that you simply can't switch to a commodity provider.

How you design your system will dictate how easy or hard it is to move. I've always been an advocate of making sure the design is agnostic to where it's running. Problems with moving start coming up if you've tied yourself tightly to specific services, or ways of working. That's not to say you shouldn't use those services, many are really very useful, just be aware of, and have a plan on how to move away from them (if you need to).

This of course depends on how central the app you are building is to your business and how long lifespan you expect. If it's your core product and you expect a lifespan of > 5 years, not getting tied in with a single cloud vendor is smart. Usually that implies some kind of stack where the highest level of abstraction is a set of containers or VMs.

But when for example doing software consulting for a company whose core product and business is not software I personally advocate the completely opposite approach: embrace your cloud platform and use the services with biggest value-add (and coincidentally lock-in). PaaS-style services enable very small teams to deliver functionality very quickly and in a robust manner - and managed services allows for keeping them running very cost-efficiently.

Congratulations, now you have the worse of all worlds. You’re paying more for hosting VMs than you would for baremetal at a colo, you’re not saving money by letting the cloud provider do the “undifferentiated heavy lifting” and your developers aren’t moving faster by depending on the cloud providers services.

Depends if you are using the value add services. AWS is much larger than EC2 and S3, but if you only stick to those it is pretty easy to move around.

When we embarked on our migration into AWS, we thought about this pretty carefully. There wasn't anything that we couldn't move in a year. That provides a sufficient backstop (IMO) to anything becoming untenable in the AWS ecosystem. Most everything could be moved in a handful of weeks of effort, or at least enough parts to achieve the reason to move.

AWS is still in a battle for market share; I think they're extremely "friendly" to their customers at this phase of the game. Will that change in a half-decade or decade? Maybe, but I think they're earning their profits now and likely to continue to do so.

At scale you need to move out of the cloud. Once you hit a certain point there is no economic gain.

That is almost surely true at extreme scale. The interesting question is whether that's true for 0.1%, 1%, or 5% of companies. (I think it's on the lower end of that range somewhere, provided the 5% scale cases are willing to be smart about their hybrid strategy.)

Was at a startup around 2k nodes in AWS. Bill was over 400K on average a month.

When purchasing RI I saw 800K a month.

> When purchasing RI I saw 800K a month.

I don't understand. Can you please clarify?

When buying reserved instances ( 3 year reserved ) the normal 400k spend was doubled to 800 thousand that month

Ah, thanks. What was the monthly spend after the RI purchase?

I believe Netflix and Apple use AWS, so I’m not so sure about that.

Netflix runs their application on AWS.

They do not stream out of AWS (because AWS bandwidth is too expensive for that application).

It's not only about cost. Networking is complex and especially for streaming companies.

1.) They need to know which pipes (to which carriers) are used at what percentage

2.) Be able to upgrade those pipes as they please

3.) Be able to cache content locally with those carriers/ISPs

All of those 3 points are not really possible with AWS.

Tell that to Netflix....

This is wrong, most companies at scale use the cloud nowdays, the operational cost + expertise you need to replicate those cloud platforms is huge.

Despite the dreams of techies, companies rarely change their underlying infrastructure. You’re always locked in to your infrastructure choices without a lot of pain and the upside is usually not worth it.

No, the company you work for is not going to get rid of their million dollar Oracle installation either and move to Postgres just because you told the CTO that you used the Repositiry Pattern and abstracted your database logic from the underlying database.

How would it be different if whole of MongoDB had a proprietary license? Amazon would do the same thing with the same effect.

Open Source is a red herring here - the problem is with selling software when AWS sells “performance, scalability, and availability.”

It's unlikely that the product would have as much usage in the first place to get any attention, nor would the protocol be open-source for AWS to host or build its own version. That's a critical difference compared to proprietary software, in which case AWS would be a customer and the vendor would be just fine.

Why would AWS be a customer if Mongo was entirely proprietary and not when it is mostly Open Source?

Because open-source is free, that's the big difference. Why would they pay for something they don't have to? There's barely anything in the enterprise edition that's worth paying for, especially when most of it is operations tools that AWS doesn't need.

If it was proprietary it would not be free - why should they pay then and not now? I am arguing that they would not, just like they don't now - there is no difference. The problem is with selling software - not with Open Source, if it was entirely Open Source - then they would not have to pay and they would use it.

What? If it's proprietary or closed source then the clouds have pay for to legally offer it to their customers. They can't just steal it without paying.

This is extremely common. How do you think Windows, SQL Server, Oracle, Redhat Linux, Spark Enterprise, Cloudera/Hortonworks, and lots of other products are offered by the clouds?

If there's enough demand for proprietary software then the clouds will do a licensing deal directly with the vendor, however MongoDB gave away too much of the product as open-source so there's no reason to pay them. That's the problem. The other issue is that if it was never open-source then nobody might even be using it in the first place, so it's a hard balance.

If it is proprietary they don't have to pay - they can always write their own - just like it happend in this case. If it is economic to write their own now - it would also be economic to write their own when Mongo was entirely proprietary. There is no economic difference in these two situations. But maybe you believe that it was not economy that dictated the rewrite - but rather it was a kind of tantrum - "others can have it for free why can't we!!!???". I don't think it was an emotional decision.

If that was feasible then they would already have SQL Server and Oracle APIs offered using their own tech instead of buying other vendors. Aurora MySQL and PostgreSQL still uses the open-source code layer on the top and just switches out the storage engines, and it's most likely the same here by using parts of actual MongoDB with a different storage engine.

Isn't the MongoDB code covered by their Server Side license [1]? AWS could not use this legally.

1. https://www.mongodb.com/blog/post/mongodb-now-released-under...

I'm surprised utility-based software pricing isn't being pursued more. The cloud providers are the natural point to bill.

Currently they sell computing resources wholesale to others who then somehow need to monetize it. (I mean raw cycles, storage and bandwidth are worthless on their own)

As a software user, paying a simple usage-based fee that includes compute, storage and software fees would be ideal.

As a cloud provider having people develop product that could be used to sell their own base product at no development risk of their own would be advantageous.

Also as a software development group not having to deal with the complexities of scaling the platform can have advantages.

The next open source model I see being successful is one which open sources it’s code, but keeps models proprietary.

Say I build a system for detecting of pigs leave their pen. Open sourcing it lets people build models for sheep, cows, and chickens. With resources I improve those models and provide additional tuning for onsite locations. There is an open source solution with code and community models, but I provide an “accuracy guaranteed”, upgrades, and maintainence.

We can even lease the hardware (cameras, field GPU boxes, etc.), want a new model for kids in a school yard, no problem! I’ll do that for you, it’ll be $100k and I retain rights to the model.

> No, they are still not selling music; in fact, they are beating piracy at its own game: the music industry is selling convenience. Get nearly any piece of recorded music ever made, for a mere $10/month.

I find it more convenient, to have a DRM-free backup of the music I paid for. Sure, streaming is useful, but not when it's available in the form of rent only. That's why I'm using Bandcamp and not Spotify.

Is it possible to let people use software freely, but if they make money from a service that uses it, you have to pay for it? This seems to me to be the fairest approach, particularly in a hosted environment. Think of something like codepen.io but instead of premium pricing they only charge you when you process payments. In a way, this is what the App Store and Play Store are already doing, no?

Unreal engine charges 5% royalty for projects using it (waived for the first $3k/quarter).

My question - how badly did Amazon get burnt by using Oracle?

In databases in particular Amazon seems to be on a huge kick to not have to pay anyone else. Even if they end up with a bunch of quasi-overlapping products (SimpleDB, DynamoDB, MongoDB) they just seem very aggressive here. At this rate they are going to have 10+ database offerings in the future.

It's easier for AWS for accommodate all their customer's needs (MySQL, MongoDB, Postgres) and reduce the cost of switching than it is to convince them to rewrite an application or legacy application to leverage say DynamoDB. The benefit of DynamoDB is great, but it's just one slice of the computing pie.

Open source works if you:

- Treat your OSS projects like MARKETING tools, not revenue streams.

- Offer a freemium version of what you produce (e.g., offering a "Pro" version that's well-maintained and adds valuable features).

- Back your projects with services (e.g., consulting, fast support, "off the shelf" implementations, enterprise workshops, etc.).

- Back your projects with paid support.

- Scale your performance expectations of the business to the cash flow of your services.

If you want to make money off of OSS, you have to run a business. It's the responsibility of the project's creators to deliver products and services utilizing their technology to provide something better than others can (and charge for it).

Otherwise, keep it closed source.

Indeed, that is NodeBB's business model (and the same model as many other forum software companies, come to think of it).

We provide fast support to anyone that wants it, and peace of mind to companies that utilise our product. We are, in essence, domain knowledge as a service.

Many people have tried to undercut us, which is a great way of keeping us honest, but there's nothing quite like getting support from the guys who wrote the software :)

My only regret is that I cannot support everyone who wants to use NodeBB, for a price point accessible to all.

I'm the furthest thing from a lawyer, but wouldn't it be nice to say my software is open source, and you can use it in your software, but if the software product you're selling with my software in it is making over $X, you have to pay $X?

Or, even more generally, is there a legal way to protect your code from being taken advantage of by the top 1% of companies? Could that become popular?

If I help a million developers and companies make money, fine, but it is immensely frustrating how the Amazons and Googles of the world reap so much of the benefit.

I don't see why big companies like Google, AWS and the like wouldn't fund open source development, precisely because they have realized great returns using those softwares to reap monetary benefit. If I were a CEO and my core business was built on OSS, I would allocate budget to help the projects used within my organization. It's just common sense to do so. Reality might be different but then that makes for some really short sighted decision making on behalf of those companies.

Disclosure: I work on Google Cloud.

Actually, we do precisely this. Google contributes heavily to Linux, KVM, LLVM, and so on in addition to the open source projects we launched (Android, Chromium, Kubernetes to name some popular ones).

Our marketing team decided to highlight this on https://cloud.google.com/open-cloud/ which does an okay job. Feedback welcome, and I’ll pass it along to them.

That's very good. Does Google also donate money to OSS projects they use? Postgres? Redis? uWSGI? Gunicorn? MySQL? I'd imagine they are heavily used in many projects within Google.

They aren't used.

Google definitely uses MySQL (e.g. https://www.mysql.com/customers/view/?id=555) and offers a MySQL deployment/management as a Service in GCloud. No idea what, if any, their contributions back to upstream have been, but I know they've been using it for important internal stuff for years, so I would be very surprised if, at the very least, no patches have come from out from the chocolate factory doors.

Google built and open sourced an entire horizontal scaling cluster management system for MySQL: https://vitess.io/

I think the argument from this article is that the core business for AWS is not the OSS. Their core business is to provide "performance, scalability, and availability". So it is a financial reality that they can (and should) replace the software if they want to.

I read the final point as saying that therefore they won't support OSS. I think that would be misguided.

Amazon has had a documented past of taking massively successful Open Source projects and adding their own bells and whistles to it and upselling them.

Amazon is the new Microsoft.

So its like Mongo is being eaten by AWS in terms of its service offerings after it gains mindshare as DocumentDB is essentially a swap-out replacement for larger companies. That somehow smells to me as it erodes funding from its foundation in some way. I don't know.

Michael here from MongoDB - We're currently still running tests on users ability to change from MongoDB to DocumentDB. It may not be quite as simple as exporting and reimporting the data. Many features present in MongoDB 3.6 do not work in DocumentDB (https://docs.aws.amazon.com/documentdb/latest/developerguide...). Preliminary test results show that DocumenDB is closer to MongoDB 2.0 in its features (with some exceptions). That means people that choose to switch over will have to find workarounds and change their code to work with DocumentDB. We'll be releasing our analysis on this soon with more information.

That is definitely not good for my needs. I'll be sticking to Atlas over DocumentDB or simply plain Mongo latest. Thank you for the comment.

The 'Why Software Should Be Free' case assumes the software exists at all. I think this is the case for a lot of common infrastructure software and I think these will continue to move to open source.

But without a license payment much software might not be available at all.

Maybe the proper way to fund open-source is just governments, altruistic companies and users, not selling? To some extent all of those already happen but growing so slowly, funded open-source software % growth could be sped up.

Everybody follows

Speedy bits exchange

Stars await to gl@ow"

The preceding key is copyrighted by Oracle Corporation.

Dupl@ication of this key is not allowed without permission from Oracl1e Corporation.

I thought the speculation was that DocumentDB was running on postgres and its just the API that's compatible. Open source might have played a roll but wouldn't this move from amazon be just as possible with a closed source API?

I thought so too, it's similar on how BigTable also supports the HBase APIs.

The economic reality of building software is that it is enormously expensive. Yes, you could develop your own operating system, compiler, UI frameworks, databases, etc. Or you could use something that already exists and works and focus on creating something new instead. You'll never get around to building something new if you first have to reinvent countless wheels.

That's why there are only a handful of widely used operating systems, many of which are Linux based at this point and all of which depend on many small OSS components. It just takes too much effort to get to the same level of functionality. The two notable exceptions are Apple and Microsoft that both choose to maintain their decades long investments in their respective software stacks. Even Microsoft has recently joined the club and is now doing open source openly. Sound economics and it has done wonders for their valuation.

Another reality with software is that its value decreases over time. It inevitably becomes a commodity. Design, algorithms, and successful features find their way to competing products and inevitably one of them gets distributed under a very permissive license. As that happens, the way to differentiate and stay valuable (and relevant) is to improve what you do, how you do it, and how well you do it.

This is the economic problem MongoDB is facing: their added value is tanking and they felt they needed to make their already quite restrictive license even less permissive to be able to get more revenue from their users. This makes the product harder to use commercially unless you pay (which is intentional). However, this causes people to look for alternative solutions and causes many of them to find their way to competing products.

The predictable result: several competing products now offer more or less drop in replacement functionality with most or all of the technical features that made MongoDB so cool just a few years ago. Amazon just capitalized on that by launching their own (closed source) product.

The long term economic success of OSS is tied to its development community. This requires ongoing investments to happen. An OSS community is usually not a single company that owns the software but the collective of users and developers of the software that together 'own' the software and derive value from it. There are certain types of software projects out there that are so essential to so many companies that they thrive for decades and are pushed forward by companies and people pooling resources through donations, active contributions, etc.

This requires a pragmatic attitude to licensing. We just saw frenemies Google and MS join forces around chrome. That is not charity: they both have a big enough economic stake in that project to put their differences aside (which are considerable). The licenses are key to facilitating such communities between mutually distrusting entities like that. It fundamentally has to facilitate the software can be used freely by anyone; that is the basis for collaboration.

The irony is that MongoDB brought this on themselves. They created a market for “like MongoDB, but reliable and secure” but were unable to deliver it themselves.

MongoDB has a fully managed service called MongoDB Atlas that runs on AWS (and Azure, GCP).

I'll be interested to see what Jepsen[1] makes of this. MongoDB traditionally lost a lot of data when there was a split-brain in the network. According to the post, AWS is a re-implementation of MongoDB v3. Will Amazon's implementation fare any better?

[1]: https://aphyr.com/posts/284-call-me-maybe-mongodb

Michael here from MongoDB - I can't answer your question about DocumentDB and Jepsen, but there is a more recent analysis from Jepsen: https://jepsen.io/analyses/mongodb-3-4-0-rc3. DocumentDB is built on Aurora, so the architecture is completely different.

Reply on news.ycombinator.com