It's not meant to have 100% feature parity with things like GitHub, it's meant to have better integration with their other services that need a basic repo.

And that is generally the AWS MO - the first version or 2 of most of their services are super basic but will provide capabilities for customers that don't already have that capability from another vendor. If it gets traction or other customers start to say "we'd use it if it had feature X" they'll start to build it out more.

It's horrible, but it serves a purpose. I've worked on projects where qualifying a vendor is a ton of work. CodeCommit is.... adequate, if you just need hosted git.

AWS and Azure tend to be easy to work with, if you're dealing with anything with regulatory requirements. I have projects which can't go on github, hosted gitlab, or bitbucket. We host our own gitlab, but if we were doing this in 2022, we might use CodeCommit since AWS is qualified.

It makes sense too. Each vendor expands your security perimeter. This isn't just dumb bureaucracy (but that doesn't make it less annoying either).

I believe there's a term for that in the context of very large organizations evaluating competing offerings / bids. Checklist something? I can't remember.

The idea is that a huge - say - government organization has a set of requirements, and bidding organizations will create MVPs only functional enough so that the line items in the requirements can be checked off by the bid evaluator.

+1 the amazon model of pushing out an MVP is not something I enjoy working with, especially when other dev shops put so much effort into the experience

Developer tools is pretty wide bucket, some of them are indeed suck, some are pretty good like Cloud9, CodeBuild, CodeArtifact