I was surprised Colin has to ask random strangers on the internet to sponsor his work on FreeBSD for EC2 instances. You'd think Amazon would be interested in this, they seem to have more than enough cash if they're making their own CPUs.
AWS will follow customer demand, when it comes to funding stuff like this. If there's enough customers unable to do what they want to do on Graviton, especially bigger ones like Netflix, they'd likely fund the work.
Same would likely be true if they had evidence lots of customers used FreeBSD on their platform anyway. They wouldn't release architecture that couldn't run Linux, for example.
> they seem to have more than enough cash if they're making their own CPUs.
That's actually a cost saving exercise for AWS. The OpEx cost of a rack is a very large part of the cost of running cloud services. CapEx, staffing etc. makes up only a tiny fraction of it. The Graviton Arm chips are cheaper to run by quite a bit than Intel or AMD chips of comparable performance. Any expense spent in designing and producing their own chips is easily and quickly paid for by the OpEx savings.
Amazon does provide some support for FreeBSD -- they paid for the ENA driver to be ported and maintained, for example. And they include FreeBSD in their CI system; if a change to EC2 infrastructure would make FreeBSD stop booting, they'll notice and fix it long before it gets deployed. They've also been very generous with AWS resources, both letting me spin up lots of instances and hosting mirrors on an ongoing basis.
I continue to hope that some day they'll invent some sort of "part-time contractor" position to provide me with ongoing funding for FreeBSD/EC2 work, but I certainly understand the argument that they should pay for EC2 specific work (like ENA) but not for FreeBSD development.
"FreeBSD works perfectly on Graviton" doesn't seem like it would move Amazon's quarterly financials. Does Amazon have any real history of sponsoring open source coding, when it is not a "d'oh, obviously this'll make Jeff richer and/or more famous" decision?
They have a history of working with open source projects only to the extent that allows them to push some of their work upstream so that the burden of maintaining it is shared, while retaining the rest of it as proprietary solutions that give them advantage over competing businesses.
Amazon has made substantive contributions to OpenTelemetry. Which, I suppose increases consumption of AWS in a roundabout way by ensuring people will not have a crashy, buggy mess when scaling up microservices, but doesn't directly drive CloudWatch consumption (because CW is not a differentiating, big-revenue-driving product, and OTel doesn't lock you in)
The cross section of "Orgs using FreeBSD", "Orgs who need to use FreeBSD on AWS bleeding edge CPU arch" and "Orgs that would bring in enough revenue to dedicate several FTE salaries on making it work" is probably small.
