That type check is honestly not pointless at all. You can never be certain of your inputs in a web app. The likelihood of that parameter being something other than an arraybuffer is non-zero, and you generally want to have code coverage for that kind of undefined behavior. TypeScript doesn't complain without a reason.
Not only that but they get to use an individual who they have philosophical differences with. You can say it was 'good security practice', tarnish his reputation, and get to switch the narrative to something sympathetic to yourself all in one go. Very convenient for them.
I think they make a lot of overly strong claims here, even though there are plenty of alternative explanations possible. The mere fact that 3 people had AWS root access during this period but they only identify one and never question that it could have been one of the others is telling. They reallllly want you to just take it as obvious that 1) all these actions were taken by 1 individual and 2) that individual was malicious. Then they sprinkle in enough nasty sounding activities and info about Andre to get you to draw the conclusion that he is bad, and did bad things, and they had to do these things the way they did.
Using what reads like a business strategy email as a 'nefarious backstory' is so bad faith. I bet if you got access to all the board's emails you would see a ton of proposals for ways to support RubyGems that may not all sound great in isolation. They are being just transparent enough to bad mouth Andre while hiding any motivations from their end as purely 'security' related.
-> In my opinion they are now deliberately making the community angry.
This is one thing I think hasn't been talked about explicitly enough within the community (that I see at least) yet, Ruby Central seems to be actively trolling the 'other side' of this situation. It reads to me like they know they have the lawyer power to defend their castle and are enjoying pissing down on people and telling them it's raining. Oh and you should enjoy that because it means there will be flowers soon... or something.
I think the dialogue of 'are they acting in good faith' only works in so far as they even care about the rest of the Ruby community at all. If they are indeed bad actors (motivated purely by greed, ambition, ego, etc) then they are not ever going to come clean and they would let the whole Ruby community die before they admit defeat or wrongheadedness. My favorite term for these types of actors is SCUM - Sufficiently Clever and Uncaring Malefactors.
Sadly mine does :\ Not that I don't support trying to get it approved, but anyone in a large enough corporation knows that approval for an external source often takes... a very a long time lol
Churn is not just rate of commits it is the changing of the same lines/files/functions repeatedly, AI answers seem to get this wrong a few places I checked which is interesting. Rate of change in itself is not 'instability', it can be a sign of new ideas emerging or lot of other positive things.
Package management cannot be a 'solved problem' or there would be no innovation there, and you don't have to look far to find is not the case.
As for the idea that rubygems is 'dead' (not what mperham said), that is still too early to say for sure, as I imagine mperham would also agree, but it is definitely not a good sign. If we only get a trickle of changes to something that was once a very vibrant and lively community repo then that is to the detriment of the whole Ruby ecosystem. That would also be a bad sign.
I am so glad someone else called this out, I was reading the napkin math portions and struggling to see how the numbers really worked out and I think you hit the nail on the head. The author is assuming 'essentially free' input token cost and extrapolating in a business model that doesn't seem to connect directly to any claimed 'usefulness'. I think the bias on this is stated in the beginning of the article clearly as the author assumes 'given how useful the current models are...'. That is not a very scientific starting point and I think it leads to reasoning errors within the business model he posits here.
There were some oddities with the numbers themselves as well but I think it was all within rounding, though it would have been nice for the author to spell it out when he rounded some important numbers (~s don't tell me a whole lot).
TL;DR I totally agree, there are some napkin math issues going on here that make this pretty hard to see as a very useful stress test of cost.
Your name is very accurate I must say.