> In 2006, Amazon launched what is now AWS, exposing the internal compute, storage, and database services its retail group had built. The internal pitch was identical to Marketplace seven years earlier.
These were not internal services, and it wasn't exactly the retail group that built them (Chris and Ben were dedicated to EC2 and the team ran remote from Seattle). Nor was Marketplace run on the 1P Amazon platform, so it would have been a strange analogy to use for a pitch.
In the end, though, the point is the same as I made elsewhere in the thread — once you are big enough you can try and bootstrap pretty much anything adjacent to your business and have a good shot at success.
This read was mildly interesting, but I'm left thinking that the study of any sprawling monopoly will come up with similar mildly interesting and irrelevant rationalizations of success. Once you get as as big as Amazon was in the early 2010s, provided your culture doesn't melt down (by itself no small feat), you are well positioned to expand and flatten adjacent parts of the economy.
So the question is whether you read this to be inspired by it and attempt to create your own monopoly, or to be afraid of it and start thinking about regulation. Or both :-)
Actually there is a long and storied history of mechanisms created to compel American companies to comply with requests for digital intervention. A good starting point is the concept of the NSL: https://en.wikipedia.org/wiki/National_security_letter
Oh this almost makes me want to go back and consider NFS for our local lab. I used to run it but everywhere having a centralized SPOF was a constant concern, and there isn't a simple HA story for it sadly.
> Without any context provided, the state-of-the-art model, GPT-5.1 (High), is only able to solve less than 1% of tasks. This starkly demonstrates that the data is contamination-free, as the model is almost entirely incapable of solving the tasks without learning from the context.
[...]
[With context provided,] on average, models solve only 17.2% of tasks. Even the best-performing model, GPT-5.1 (High), achieves just 23.7%.
Not strictly but Debian, where member inclusion is done through an in person chain of trust process so you have clusters of people who know each other offline as a basis.
Also, most WhatsApp contacts have been exchanged IRL, I presume.
That's interesting. I was reading their licensing compliance FAQ at https://min.io/compliance and it doesn't allude to that; in fact it suggests that for instance calling a REST API doesn't imply derived work (modulo the specificity piece), referencing the GPL. The omission of the over-the-network AGPL provision is notable. I wonder if it's obscure on purpose?
Nah, the AGPL is pretty clear (and way clearer than the GPL and LGPL due to combined/derived work fuzziness). The issue with it isn't anything to do with the mechanism of the license itself, because it is pretty clear what the criteria are (and offering an API over the network definitively constitutes Remote Network Interaction) and how you can fulfill the source distribution. The real issue is that the AGPLv3 doesn't preclude a third party from commercializing the software (whether modified or not).
> I can explicitly cancel a subscription after a certain date—what is the problem with me explicitly cancelling a subscription after a certain amount of spend?
As someone also involved in billing systems for public clouds: in theory there's no difference, but in practice there is a world of difference. This is the sort of situation where the end user is commonly surprised with the consequences of their own decisions. At MGC we have some "soft shut down" processes, and we constantly hear stuff like "I know I said shut down, but this is the one situation where that really didn't make sense"; where examples are "storage which keeps backups became unavailable", "a very simple but critical user auth system disappeared", "I had no idea this was still running on my account", or "OMG not in the middle of the weekend", etc. You can build heuristics and tracking into the system to minimize these situations, but that's a lot of work.
So yeah, it is a valid use case and something many CSPs would like to provide, but implementing something that is actually better than nothing is non-trivial.
Well, the comment from OP isn't necessarily complete. The AGPL is not about preventing someone from using source code (indeed that would be contrary to the spirit of all liberal and copyleft licenses), but rather the condition under which source code modifications need to be made available.
Specifically, if you offer the software for "Remote Network Interaction" (AGPLv3 section 13), well, "if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version".
I think the original challenge with AGPLv3 vs (to grossly generalize) the VC-backed open source corporate ecosystem was not around source code, but around monetization as SaaS by the hyperscalers. The problem there is even if the hyperscalers publish source code modifications (which they probably have no problem with) they have such sales efficiency and gravitational pull that they will end up eating your business.
> In 2006, Amazon launched what is now AWS, exposing the internal compute, storage, and database services its retail group had built. The internal pitch was identical to Marketplace seven years earlier.
These were not internal services, and it wasn't exactly the retail group that built them (Chris and Ben were dedicated to EC2 and the team ran remote from Seattle). Nor was Marketplace run on the 1P Amazon platform, so it would have been a strange analogy to use for a pitch.
In the end, though, the point is the same as I made elsewhere in the thread — once you are big enough you can try and bootstrap pretty much anything adjacent to your business and have a good shot at success.