I've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation.

A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again.

[1] https://github.com/ralexander-phi/license_approval

GitHub has the advantage of a low barrier to entry for their tools. A lot of their features are inferior to special-purpose tools, but they can expect high usage because a lot of users shrug and live with it.

It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.

These are proplems github customers have.

“Uncover” meaning “believe the same stuff that I believe, based on 20 year old tech history that everyone knows already”. There’s no secret here.

Would you like to spell them out? It's not exactly clear if you're thinking of the same ideas as other people, a conspiracy to take over the world, or something in between.

Why?

Just like with AWS SaaS offerings: All they need to do is have something basic, satisfying 80% customers, requiring little maintenance on their end.

I just want to be able to browse the dependencies of my repo with a web UI. Show me a tree of dependencies in my repo, filter for ones that are outdated, expand them to show what would be in a dependabot PR (the keen description it generates that contains all the release info and links to changelogs and whatnot). Then let me open a PR (or tell dependabot to do so) with the click of a button, or ignore it with another.

The current workflow where dependabot just spams an endless stream of PRs is not optimal. I don't need any new features from dependabot, I just want a better UI.

Last time I tried (which is >2y ago, so things might have improved), dependabot seemed like an afterthought for GitHub.

For example, at some point GitHub introduced a change that prevented CI builds triggered by forks from accessing secrets in CI variables. This made sense from a security perspective (although I would have a preferred a hard failure instead of variables silently being set to empty), but it also applied to all Dependabot PRs, which I have to assume wasn't intended behaviour. It really seemed like different teams at GitHub weren't talking to each other. An issue was opened about this and got quite heated, but wasn't really resolved (except for some ugly workarounds) before it was locked for becoming too uncivil.

I wonder if they fixed it since.

Oh yes, https://github.com/dependabot/dependabot-core/issues/3253. I wouldn't go so far as saying it was locked because it was too uncivil, mostly just because "additional commentary wasn't adding value" ;)

Your read on the situation is spot on, and no, it doesn't look like it's been "fixed" (mostly because "fixing it would re-introduce the same potential vulnerability).

I think it would be possible to fix it properly and without security risk by allowing pipeline authors to allowlist dependabot and/or specific forks for accessing secrets.