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?
AWS, MongoDB, and the Economic Realities of Open Source
121–130 of 257 posts
Re: AWS, MongoDB, and the Economic Realities of Open Source
#122Agreed, 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 bet…
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.
Re: AWS, MongoDB, and the Economic Realities of Open Source
#123Earlier quoted context omitted.
> 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 mone…
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.
Re: AWS, MongoDB, and the Economic Realities of Open Source
#124It 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 m…
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.
Re: AWS, MongoDB, and the Economic Realities of Open Source
#125Earlier quoted context omitted.
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.
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.
Re: AWS, MongoDB, and the Economic Realities of Open Source
#126I 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 comp…
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.
Re: AWS, MongoDB, and the Economic Realities of Open Source
#127Earlier quoted context omitted.
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.
Re: AWS, MongoDB, and the Economic Realities of Open Source
#128I'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.
Re: AWS, MongoDB, and the Economic Realities of Open Source
#129How 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.”
Re: AWS, MongoDB, and the Economic Realities of Open Source
#130Two 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 yo…
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/
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.