[viccis]

Not surprised. CodeCommit was released alongside a stable of other mediocre tools for CI/CD (CodePipeline and CodeDeploy if I recall correctly) that reflected the pinnacle of AWS's mid-to-late 2010s attitude, which is to find something popular and offer an incredibly mediocre alternative to it that will still be used by those teams who want to move as much as possible to AWS. Seems like that stalled out a bit, mostly due to it being so insanely bad that even the most dedicated AWS fanatics didn't bite. I feel like a lot of the recent stuff is just drop-in replacement AWS alternatives to popular tools (like Kafka and Cassandra) with outrageous price tags.

[rgblambda]

>be used by those teams who want to move as much as possible to AWS

By teams that have been mandated to move as much as possible to AWS by their company's senior leadership, because it simplified accounts/they negotiated a "great contract" etc.

[grobbyy]

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.

[benterix]

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

We would be in very deep shit now.

[hocuspocus]

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.

[deeebug]

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.

[outime]

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

[neongodzilla]

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.

[latentsea]

AWS CantCommit

[ctvo]

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

[g15jv2dp]

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

[vasco]

Doesn't it reflect more on the quality of the people involved? These tools came out at the same time as a bunch of other AWS tools that are still used. The platform itself, the company around these teams was the same, so why did Code Commit suck but other AWS products from the same vintage turned out great?

[scarface_74]

You’ve never been part of a large organization have you?

I have a little insight on how things like CodeCommit fall behind the competition.

I worked at AWS in the Professional Services division. For a little over two years I was on a makeshift team maintaining and improving a very popular open source project in its niche.

The project was hosted on “AWS Samples” (https://github.com/aws-samples). Once approved for the initial release of a project in this Github organization, there is no oversite on updates. In my experience from releasing 8 of my own projects to the repository, it takes about two days to get the initial approval and it’s really based on the honor system as far as following the guidelines after that.

We released features and improvements like gangbusters based on customer demand or if we just wanted to scratch an itch.

Then, it became popular enough to be promoted from “AWS Samples” to an “AWS Solution” (https://aws.amazon.com/solutions/).

Everything slowed to a crawl, releases, approval processes, you had to justify everything you wanted to add based on revenue potential, everything had to be approved by higher ups. We were the sane developers. I dropped out of the project then.

But I saw the storm coming, so my last major contribution before it got transitioned was to introduce “hooks” functionality that allowed you to change the processing pipeline by adding a custom lambda arn to it in settings.

Before it became a “solution” former AWS employees who use to work on the project who were still in the industry would make changes and submit pull requests that we would merge.

But back to CodeCommit, can you imagine how hard it is to convince senior leadership to give you funding for a service that neither gives you a competitive advantage nor is a revenue generator?

Hell they just added support for viewing images inline in markdown from the console this year.

[neongodzilla]

Hey fellow nerd. What project was it? I'm just curious if I came across it. I loved digging through the solutions repositories every quarter or so -- always something new and legitimately useful.

[scarface_74]

https://aws.amazon.com/solutions/implementations/qnabot-on-a...

[vasco]

When I mean the people involved I didn't mean mostly the software engineers, like you show they probably have the least contribution to the success of these projects. But the point stands that the products have to exist in the same level of bureocracy and disfunctional leadership, so someone must've been better at dealing with that in the successful products. I definitely had really good experiences as a user of several of AWS's things from the same time. Maybe it's more on product leadership but I was just musing about it. To your original question I haven't worked on such big corporations no, max size I've experienced is ~2k people for ~6 months, other than that 10-400 - so I can see how it's also a different beast.

[scarface_74]

Bezos was well known for focusing on things that “make the beer taste better”. It didn’t give AWS a competitive advantage or any real revenue by trying to host a git repository.

For years they have been making sure that their other services like CodeBuild and CodePipeline work with other hosted git providers.

Uncharacteristically, they even support creating third party git repositories with CloudFormation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

As far as working for large companies, I would rather get a daily anal probe with a cactus than ever work for a large company/“FAANG” again. I’ve repeatedly ignored overtures from Google (GCP), Microsoft (Azure) and even Oracle (OCP).

My BigTech story:

https://news.ycombinator.com/item?id=38474212

[thr0w]

CodeDeploy is kinda good for blue/green deployments to EC2. A little painful to set up, but works flawlessly once you get it going.

[rkwz]

> find something popular and offer an incredibly mediocre alternative to it that will still be used by those teams who want to move as much as possible to AWS.

Any insights on _why_ they turned out to be mediocre? Is it because of them being released as MVP and staying that way for many years or just a lack of interest afterwards?