There’s always room for improvement.

If we’re talking about the Linux kernel or Netflix’s video delivery infrastructure, maybe. But the majority of developers are not working on those. And I’m still going to call it “unavoidable technical debt” because for all intents and purposes that’s what it is.

So… are you using nothing but FOSS from activist projects? That doesn’t seem like a big pool, from what I’ve seen. Or do you mean support as in with your time and/or money?

If you are submitting work, you should understand how the code you're submitting works. Sure, you don't have to know exactly how the code it calls works, but if you're submitting code and there's a block of code and you have no clue how that block works, that's a problem.

I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong.

Have you worked on a production code base with more than a few thousands of lines of code? A bug is always going to be a bug, but 99% of the time it's far harder to answer "how is this bug triggered" than it is to actually fix the bug. How the bug is triggered is extremely important.

Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?

If you don't validate types you can easily run into a situation where you write a value to a variable with the wrong type, and then some later event retrieves that value and tries to act on it and throws an exception. Now you have a stack trace for the event handler, but the actual bug is in the code that set the variable and thus is not in your stack trace. Maybe the stack trace is enough that you can figure out which variable caused the problem, and maybe it's obvious where that variable was set, but that can become very difficult very fast in a moderately complex application. Obviously you should write tests, but tests will never catch every weird thing a program might do especially when a human is involved. When you're working on a moderately large and complex project that needs to have any degree of reliability, catching errors as early as possible is always better.

I'm definitely biased because I love the language, but I think Go is a good place to start. The authors talk about the language design more than I've seen for other languages. The Go blog occasionally has posts like that but Russ Cox's blog is the place to go for the gnarly details. Another good place is the proposals repo, e.g. the generics proposal. I also browse issues on GitHub and look for ones with interesting discussions.

including the syntax, which I know most nerds dismiss as superficial.

Syntax is mostly irrelevant as far as what is possible with a language, but it is a critical aspect of how easy/hard it is to use a language, and most critically how easy/hard it is to read code written in that language. IMO the only thing that's more important than readability is whether the code works as intended.

I can see how systems engineering could fit into that role but the project/program managers I’ve talked to were much more focused on management than engineering

Part of it is an HTTP/RPC interface, but that's not the party I want to test.

I'm definitely not interested in convincing you to change your mind but I do want to reply to some specific items.

the number of users in groups

The only limitation I can find is that top-level groups on the free plan are limited to 5 users. Granted, there are certainly reasons to keep a group private, but public groups are not limited.

moving some basic free features into premium like protected branches, code owners, issue dependencies, epics, roadmaps

Protected branches are available for all plans. I'm pretty certain the rest of the features you mentioned were never free. You can disagree with that choice, but it is incorrect to say they were moved into premium.

I saw in other comments that you aren't happy with the direction GitLab is going in and feel that they're focusing on business customers at the expense of open source users. Can you expand on that?

The project I am working on joined the GitLab for Open Source program and it was absolutely painless. All we needed to do was submit an application and now we're using Ultimate without paying a cent.

I'm not sure it's what you're referring to, but one of the pain points for me is that open source projects (that don't join the program) no longer have access to lots of free SaaS CI hours. That sucks, but I can't blame them - they had a plague of crypto miners taking advantage of those free CI hours. It's not reasonable to expect them to eat that cost, especially when the open source program is so easy to join.

I'd say the biggest categories are chores and minor updates. For example (for the latter category), we finished an overhaul of the API; we developed and tested it, then deployed it to the test environment and had users and app developers test it, then we deployed it to production and closed the epic. And now that it's on production and more people are using it, we've realized it needs some improvements. Where do those tasks belong? They're not high enough priority to do now (there are other things higher on the list), but they should get done eventually, and there's not enough of them to merit an epic.

PHP was the first language I did any significant coding in. I will never use it again if I can at all avoid it.