Having been on both sides, it often makes a lot of sense. A lot of companies have surprises requirements in contacts, such as HIPPA or military/classified or whatnot. The cost of adding a new vendor can be astronomical compared to the cost of dealing with CodeCommit.

In truth, though, Amazon should have bought gitlab instead.

> In truth, though, Amazon should have bought gitlab instead.

We would be in very deep shit now.

Funnily enough when my infra team talked to AWS solution architects about this topic, it seems they were very upfront: don't touch CodeCommit, AWS/Amazon teams mostly use GitLab internally. And we do have a partnership plus discounts conditional to minimum usage volumes.

Slight correction, the sales org uses GitLab, mainly to segregate any “code” they build for customers. Internal AWS/Amazon teams use an internal git-backed UI.

The fact that there was no dogfooding in many years here tells everything one needs to know about CodeCommit.

If AWS forced their teams to "dogfood", it would quickly morph into the Testuo blob monster from Akira -- there are too many products/services popping up too quickly, and the amount of time and knowledge lost to the constant changes would be catastrophic.

Dogfooding is for simpler companies. It's also bullshit and best for product managers and sales. Let tech work with what's best for their specific internal environment.

The thing I like about AWS is they're very practical.

Here's a project from AWS using the CDK to setup a CI/CD pipeline with Github actions:

https://github.com/cdklabs/cdk-pipelines-github

Software devs fall to hype sometimes. It's not just management. But I guess it's easier to always look for blame elsewhere.