[jrochkind1]

I used to think people who said Github had become very unreliable were exagerating, but I can't miss it now. If you want to keep people, you have to actually go down less.

It's interesting that internally you had a very different experience with Salesforce buying Heroku and Microsoft buying Github. From the outside it appears to be analagous (except github is degrading quicker than Heroku did?)

[WD-42]

Did Heroku ever actively degrade? Seems more like it was neglected until the competition eclipsed it entirely. What GitHub is doing seems worse, like true active regression.

[idan]

Salesforce never understood Heroku. Salesforce's understanding of Heroku, if such an understanding ever existed, was wildly different than what Heroku understood it wanted to be. Benioff's penchant for buying himself a company every year did not help — "no headcount this year, we're buying Mulesoft/Quip/Tableau/Slack/$WHATEVER. And oops we spent too much money on dreamforce. Sucks that your pager rotations are burning people out!" It was very clear they did not give a shit about us, as evidenced by resources.

It's safe to say that I'm hypersensitive to these antipatterns and have been looking out for them at GitHub, and I don't see them.

What Microsoft wants GitHub to be is pretty much what GitHub wants GitHub to be. A home for all developers, playing a central role in the production of both public and private software. That alignment was never there with Heroku/Salesforce.

GitHub is not perfect but I don't think it's "degraded faster" at all. It's _grown_ faster. Much much much faster. And it's had to expand into the AI field, which is not an incremental thing like "hey let's launch a new feature or better dashboards." Nobody knows what AI wants to be when it grows up. GitHub in 2026 fundamentally resembles a pre-PMF startup in many ways because of that. I'm obviously not an unbiased observer, but I wouldn't count us out just because it's an uphill. Everyone's on that same uphill.

Having experienced both firsthand, I fundamentally disagree that there's a parallel. GitHub/MSFT has the median amount of corporate bullshit. Not more, not less.

[amluto]

> GitHub is not perfect but I don't think it's "degraded faster" at all. It's _grown_ faster.

It’s grown in a way that degraded it and that required actual effort. For example:

- The fancy new diff viewer frontend that barely works. Someone wrote that code — it didn’t happen by itself.

- The unbelievably buggy and slow code review frontend (which is surely related to the diff frontend) was added complexity that did not need to happen. Its badness has nothing to do with how many users use it. It’s just bad in a no-scaling-involved way.

- GitHub actions. It’s … bad. I suppose there wasn’t a predecessor that was better.

> And it's had to expand into the AI field, which is not an incremental thing like "hey let's launch a new feature or better dashboards."

No, it did not have to expand into the AI field. A competent AI-free GitHub Core that could have an optional AI layer on top would have worked just fine if not dramatically better than the current mess.

(I say this as a paying user who will probably cancel soon. The Copilot reviews are kind of nice, but they’re not any better than a third-party system, and I’m getting sick of GitHub not working. Plus, the repos I’ve already migrated off of GitHub get to have nice non-AI things like gasp service accounts.)

[AlphaSite]

I knew a guy who worked on it tell me actions is just literally a fork from Azure Devops. Which is why it never really fit into GitHub.

[kdazzle]

I have heard this also. I still find it wild that Azure DevOps had that feature long before GitHub

[ragall]

> GitHub actions. It’s … bad. I suppose there wasn’t a predecessor that was better

There might not have been a predecessor, but it's been obvious for at least a decade that GHA are a very poorly designed programming language, yet nothing was done to improve. They introduced Github Apps that solve many of the issues with Actions, but that requires deploying a service and aren't anywhere near the ease of use of Actions.

[Simran-B]

Isn't it a dumbed down version of Azure Pipelines?

[ragall]

It depends on whether its authors were aware of Azure Pipelines and used them as a source of inspiration. Perhaps.

[amluto]

Amusing new observation due to today’s outage [0]: apparently GitHub never bothered to do the obvious optimization to the /pulls page: when you load it with the default “is:pr is:open”, they seem to be depending on their heavyweight search service, despite the fact that their normal API can enumerate open PRs just fine (and probably at dramatically lower cost to them). Sometimes the common case of a webpage should be simple instead of a relying on something fancy.

[0] Which has been ongoing for hours but hadn’t started when I wrote my comment. https://www.githubstatus.com/incidents/x69zbgdyfzg0

[kryogen1c]

> It’s grown in a way that degraded it

Im an outsider and a layman, so this might be totally off base, but...

The way I hear people talking about github reliability doesnt sound like scaling problems to me. If you drive 20 miles every day but then decide to drive 2000 miles and run out of gas, thats a problem of scale. If you drive 2000 miles and your engine explodes, thats a problem of design.

Maybe their design problems are being made evident because of sudden scale, but they're still design problems.

[IanCal]

I think the fair side of this is that you have to make tradeoffs when you design things. Scaling problems are design problems, but whether they were mistakes or not really depends on how predictable that scaling was.

Car analogies are typical, so I'll add in there.

My car can take the four of us, and we can load it up with things from the shops. I can put a bunch of heavy tins of food in there, or some DIY things, but if I put several tons of stones in the boot it'll totally fuck it up.

Is that a design problem?

Not really, it's a relatively cheap regular car, and it failed at a certain scale.

It would be a design problem if it were a flatbed truck, despite it being the same scaling that showed the problem.

Making my car resilient enough to take that weight would require tradeoffs that would either make it worse for other jobs I want it to do or at least add significantly to the cost.

This is similar in engineering software systems too, you can make it handle scaling up better, but this can require a much more complex architecture that may make it slower at smaller scales. It can make it more complicated to work with, add additional risks of failure as well.

[lwhsiao]

> And it's had to expand into the AI field

Maybe a hot take: no, it didn't.

I think it had all the pieces (api,cli,etc.) already that it would've still be very useful in an AI world without deeply integrating AI things (copilot, etc.). I'd take higher availability over AI features any day.

[ragall]

> What Microsoft wants GitHub to be is pretty much what GitHub wants GitHub to be.

Yes, and what Github wants public github.com to be is free QA for Github Enterprise. My company is a paying customer with 200 engineers and it's pretty clear we're just Guinea pigs for the Enterprise product.

[jrochkind1]

Thanks for your perspective, appreciate it!

[IanCal]

> central role

Isn't this the massive problem? You're trying to do everything, and you can't, and you're trying to do it for everyone all at once, and have tied it all together so much that scaling up gets worse. If it's more than twice as hard to cope with twice the use, then you have to charge a bunch more to customers as you grow - and that's for your customers to get no actual benefit.

> GitHub is not perfect but I don't think it's "degraded faster" at all. It's _grown_ faster.

The experience has degraded. It's really, really bad. I've seen companies spending thousands and thousands of dollars weekly in developer time *hitting rerun on broken actions*. It's so expensive to start with then so expensive in how awful it is to use.

Something I really don't get I guess is what out of all of this actually needs to be cross-project. How much of my github use needs access to something that isn't running on the same machine? I worked with a team building things actively, maybe 20 devs? That's not really a large set of users. Let's say 10 devs with the workload of 20, the cheapest plan would be $40/mo, enterprise would be ~$200. Would ten heavy users really max out a 64GB ram, 6+8 core new i5 with dual nvme drives, a gigabit connection and unlimited traffic? That's about $40 at hetzner for a box.

I'm not arguing a big federated position, I just don't really get why some of these enormous companies need to be so centralised. It feels like the problem is trying to be a big interlinked thing, and failing at it. The only things I can think of are

1. Links between issues

2. Accounts

3. Search

The first is mostly solved with literally just links, accounts isn't a huge problem and search is fair enough - but search is utterly awful and I cannot find things within one single repo or organisation reliably. So global stuff is irrelevant.

> And it's had to expand into the AI field, which is not an incremental thing like "hey let's launch a new feature or better dashboards." Nobody knows what AI wants to be when it grows up

If github persists in being utterly shit for developers, it won't be around to find out. I'm not sure at all what part of the AI stuff needs to make everything else bad, and I'm extremely bullish on AI and agentic coding.

To really hammer this last point home, as agentic coding means we can do a lot more and faster - the unreliability of github has become much more apparent and impactful. Unreliable tests, unreliable code pulling and pushing, unreliable diffs. You're making the agents jobs harder, making the devs jobs harder exactly in the place they now spend much more time.

It makes github dramatically more expensive as a place to work. Also just really fucking annoying.

[jrochkind1]

The federation thing isn't just github of course.

I think the general answer is that it would take real development effort to make federation work, and having to have compatibilty with other installations slows down your own pace of possible features -- I think these things are undeniable. Arguably worth it for society/the community (I wish we had more open standard federation and less centralization), but from the point of view of the company will it actually lead to increased profits sufficient to justify? In fact, it may do the opposite, if you are one of the largest, then lock-in is better for your profitability. Compatibility with other services is only important for the small upstarts trying to get customers from the largest.

I don't like it, but I think we will get proprietary centralization as long as we have capitalism of the sort we have.

[IanCal]

I get what you mean, I think what I'm pretty stuck on is what is the centralisation solving? Federated messages dealing with lots of things flowing back and forth and live updates, etc is one thing - but what is it about GH that makes much of a difference when things are in one place or many? Much of the work is done in very isolated sections.

Imagine each organisation/user was run with completely isolated data, and you used something like google sign in for auth (so one global sign in, then oauth).

What wouldn't work? Global search, that I get. I struggle to think of other things though. Maybe whether links between issues across orgs updates? Every commit, diff, code browser, permissions for writing, reading, org level search, stars, would work with zero federated sort of search-y things. Package management, issue tracking, all that would be the same.

Forks followed by PRs? Not sure that would be much different - maybe you'd have to raise an issue on the original project with a link to your new repo & branch.

[jrochkind1]

Hm, thinking about it.

Some of my attraction to github is just that I am used to and like the UI, and I get annoyed on another platform where I don't understand the UI and don't know where to find things or how to do things (like set up free CI for open source project, or debug existing CI for a PR).

Other than that... auto-linking to issues, prs, and code (with auto-expansion of excerpt in issue) cross-project is nice?

But you are right, git is theoretically something where separate projects are fairly isolated, which does make it more mysterious that competitors are having trouble and it seems like github has some kind of network effect lock-in anyway. It's a good question.

[chimeracoder]

> It's interesting that internally you had a very different experience with Salesforce buying Heroku and Microsoft buying Github. From the outside it appears to be analagous (except github is degrading quicker than Heroku did?)

This pops up on here frequently. People misremember the Heroku timeline with Salesforce. Most of Heroku's growth and glory days happened after the acquisition. Salesforce actively invested in it and turned it into the powerhouse that people remember today.

At some point, they stopped, and it's not clear why.

People flip the order of the first two and remember it as "Salesforce acquired Heroku and then they went on a downward spiral" but that's not really what happened. There were many years of growth in between, including the period that almost everyone who remembers Heroku fondly remember it for.

[jrochkind1]

I am aware, and I am often the one making that point -- but here we have someone who worked at heroku saying he experienced the SalesForce acquisition as immediately negative and with signals that it was not going to get better and this caused him to leave, so I was discussing within that narrative. I was more intersted in learning about his take from his experience than in trying to tell him he was wrong and salesforce was great for heroku despite his experience working there?

But yes, heroku from the outside kept doing quite well for the first years of Salesforce ownership, whether becuase they let them alone and kept their budget going, or whatever. That's why I suggested that from the outside github's slide was much faster.

idan (who again, tells us they worked at heroku) replied to me in this thread:

> Salesforce never understood Heroku. Salesforce's understanding of Heroku, if such an understanding ever existed, was wildly different than what Heroku understood it wanted to be. Benioff's penchant for buying himself a company every year did not help — "no headcount this year, we're buying Mulesoft/Quip/Tableau/Slack/$WHATEVER. And oops we spent too much money on dreamforce. Sucks that your pager rotations are burning people out!" It was very clear they did not give a shit about us, as evidenced by resources.

> It's safe to say that I'm hypersensitive to these antipatterns and have been looking out for them at GitHub, and I don't see them.

At the point we're quoting other people's replies in other parts of the thread becuase we're not all even having the same conversation anymore, we're probably done!