Let’s Make Sure Github Doesn’t Become the only Option

GitHub is dominant in today’s software development industry. Most professional developers interact with software created, maintained, or controlled by GitHub daily.

Their own marketing material touts that they are “The largest open source community in the world”, and indeed, the 2022 StackOverflow survey shows GitHub as the most popular version control platform by a wide margin. Many well-known open-source projects use GitHub as their source code platform of choice.

GitHub’s dominance is a risk to the software industry. Making GitHub the primary platform gives one company the power to put their needs over yours, or the industry’s. We risk leaving brilliant developers behind who don’t work well with GitHub’s paradigms. We risk being stuck with our old, technical mistakes because the underlying technology never changes. We risk losing control over our tools because they’re not actually our tools.

Don’t mistake their feature development for charity. They are a large business with a financially driven leadership team and a product roadmap. Their goals only align with yours if your goal is to make GitHub more profitable.

The more you use and rely on GitHub, the more difficult it becomes to find and use alternatives; either because you have too much infrastructure built up around GitHub’s specifics, or because the rest of the industry has homogenized around GitHub’s ideas.

I’m here to show you why that’s such a risk to the software industry and how we can mitigate it by trying some other tools.

Collaboration

One of GitHub’s most popular features is Pull Requests, or PRs. While PRs are not required to use git, they show an abstraction to view git differences (diffs) and offer comments on those diffs. They’re also a formal way to double check our work before it goes out.

This PR-centric way of working can also create a bazaar-style culture of low-trust. Low-trust can be an important part of the software development process. Open-source contributions from unknown developers come to mind, or perhaps a legal team needs to sign off on a change.

But low-trust is the opposite of what I believe most smaller teams want; even teams in big organizations. In those environments you want to encourage autonomy which requires high-trust.

Pull Requests are a blunt instrument that puts gate keeping front-and-center. As Jessica Kerr says in Those pesky pull request reviews:

Pull requests are an improvement on working alone. But not on working together.

The Pull Request workflow is so dominant now that it’s considered the default path for code to permanently enter into a repository. You can see a similar features in GitHub’s smaller competition Codeberg, GitLab, BitBucket, and Gitea. These competitors don’t offer other, major code collaboration tools, and their Pull Request-like features aren’t just there to help users come from GitHub. They are the only tool. They looked at the dominant player and did the same.

I’d like to see what other tools people can offer. Perhaps a tool that promotes ensemble working to share the problem solving and context with a larger group. An asynchronous team could make use of tools that inject code review throughout the development process. Instead of a full review with CI and approvals, you could open up your teammates code as easily as opening a new file in your editor to leave comments. Or what if a tool could helps teams design software before code is written? Right now all guidance and critique happens after, which requires developers to context switch and redo work.

I do not know what these tools are or what they look like, and I’m not saying Pull Requests are all bad either. But I don’t believe that we’ve found the one-and-only way to work together on a code base.

We, as an industry, are defaulting to Pull Requests. Instead, we should be exploring other ways to collaborate and share our knowledge that come with other tradeoffs. Every team is wonderfully different and deserves to have a workflow that fits them. Continuing to only use PRs risks being stuck with them forever, both the good and the bad.

Underlying technology

git itself, while not owned by GitHub, is even more popular. This is largely because of GitHub’s popularity and in spite of git’s poor UX. It would be nice to move beyond git one day and have a better experience for managing complex codebases, and not on GitHub’s timeline.

In GitHub’s early days, picking a single version control system could have legitimately been a way to focus the product. GitHub is big enough now that they could dedicate some time toward exploring other tools. But it’s not really GitHub’s job to do this. GitHub’s job is to make Microsoft money. Features that improve the lives of developers are incidental.

The dominance of any one version control system is the downfall of others, and it holds the industry back from potential improvements. GitHub has sh