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.
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.
If Albert Einstein had a blog post about relativity, I would rather read that than someone’s interpretation....
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?")
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.
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?)
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.
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.
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.
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.
Google did the same thing with Java. It’s up in the air how that will turn out.
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 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.
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.
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.
sometimes it's okay though.
but AWS monoculture is not a bright future.
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.
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?
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.
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.
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.
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
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.
IIRC this strategy was tested by Jay-Z with little success. Taylor Swift also came back to Spotify...
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.
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.
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!
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.
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.
Presumably that's why, in the words of the parent poster, the dream is dead.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
I guess only when developing their own engine is cheaper for them.
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!)
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...
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.
Market Cap 31.055B
S&P 500 Component
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.
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.
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.
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.
GraalVM would never exist with weekend developers.
Top level JIT and almost non stoping GC algorithms don't get implementated with late nighters.
Oracle engineers work hard on java and deserve their money but the vast majority of people employ OpenJDK which is OracleJDKs derivative.
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.
if oracle wanted to continue to be the owners of Java they shouldn't have called their bluff and sued Google.
Oracle did the right thing against Android J++.
CentOS is more of a repackaging of Redhat -- the binary files are almost exactly the same there so the comparison isn't quite valid.
OpenJDK is (a subset of) the Oracle JDK.
> OpenJDK is the official reference implementation of Java SE since version 7.
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.
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.
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.
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.
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.
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)
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.
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
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.
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.)
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.
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.
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.
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.
EDIT: and searching HN comments, there's multiple people claiming AGPL is entirely banned inside Amazon too
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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...
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.
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.
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.
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.
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.
Then again the reverse is also true. Just look at all the software providing an S3 compatible API.
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.
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.
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.
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?
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.
> 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.)
It's more like AWS RDS for MongoDB.
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.
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.
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.
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.
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.
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”.
And even then they don’t host your database in your own VPC which is a big deal to some companies.
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)
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...
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 -
They even copy SaaS hosted on AWS if the number are good -
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.
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.
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.
When purchasing RI I saw 800K a month.
I don't understand. Can you please clarify?
They do not stream out of AWS (because AWS bandwidth is too expensive for that application).
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.
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.
Open Source is a red herring here - the problem is with selling software when AWS sells “performance, scalability, and availability.”
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.
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.
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.
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.
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.
- 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.
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.
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.
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.
Amazon is the new Microsoft.
But without a license payment much software might not be available at all.
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.
Copyright 2003 Oracle Corporation.
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.