Is GitHub Still a Place for Serious Work? A Practical Guide

When a developer like Mitchell Hashimoto—someone who has been a GitHub user since 2008 and essentially lived in the platform—decides it is no longer a place for serious work, you should pay attention. We’ve spent years treating GitHub as the immutable bedrock of our industry. It’s where we host, collaborate, and ship. But lately, the cracks in that foundation have become impossible to ignore.

If you’re building software, your tooling is an extension of your team. When that tooling fails, it isn't just a minor inconvenience; it’s a direct hit to your velocity. Hashimoto’s decision to migrate his project, Ghostty, away from GitHub isn't just a temper tantrum. It’s a calculated response to a platform that has prioritized feature bloat and AI integration over the fundamental requirement of any developer tool: staying online.

Here is the reality most teams are currently ignoring: we have become dangerously dependent on a single point of failure. When GitHub Actions goes down, or when pull requests fail to complete due to backend instability, your entire CI/CD pipeline grinds to a halt. You aren't shipping. You’re waiting for a status page to turn green.

Why does this keep happening? The shift toward AI-heavy features and metered billing often comes at the expense of core infrastructure stability. When a platform tries to be everything to everyone, the "serious work" often gets pushed to the back burner.

If you are feeling the same friction, you need to evaluate your own risk profile. Ask yourself these questions:

1. How much of your deployment pipeline is hard-coded to GitHub-specific services?
2. Do you have a disaster recovery plan for when your primary code host goes dark for an entire afternoon?
3. Is your team’s productivity tied to a platform that treats outages as "incidents" rather than systemic failures?

This isn't about abandoning the ecosystem entirely. It’s about acknowledging that the "de facto" choice isn't always the "best" choice for your specific needs. If you’re tired of the instability, you have options. You can look into self-hosted GitLab instances, Gitea, or even distributed version control workflows that don't rely on a single centralized provider.

The most dangerous thing you can do is assume that because a service worked for the last decade, it will work for the next one. Infrastructure is not a set-it-and-forget-it decision. It requires constant auditing. If your current host is blocking you from shipping, it’s time to look elsewhere.

Here’s where most people get tripped up: they think migrating is too expensive. But calculate the cost of two hours of downtime for your entire engineering team every week. That’s not just a technical debt issue; that’s a massive drain on your bottom line.

If you’re ready to take control of your workflow, start by auditing your dependencies today. Don't wait for the next major outage to realize you’re locked into a platform that no longer supports your goals. Is GitHub still a place for serious work, or have we just been too lazy to move?