Edward Loveall

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 help 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 shown no interest in supporting other systems, even if those systems have advantages over git.

I want to underscore this because I think it’s important: git and GitHub’s symbiosis are holding us back as an industry.

GitHub is what most people use because it makes the complexities of git easier. git remains dominant despite it being complex because it’s not in the interest of GitHub and most of GitHub’s competitors to support anything else.

Other version control software exists that doesn’t need a separate company to make the code accessible from the web or makes dealing with conflicts easier. We as an industry cannot benefit from these alternatives if we continue to use GitHub this heavily.

Code suggestions

Copilot, for all it’s praise, has real downsides. It’s a risk to rely on it for security or correctness and open-source advocates are suing GitHub because Copilot allegedly violates popular open-source licenses.

GitHub’s de facto monopoly makes it hard for anyone to effectively call them on their bad behavior. The only way to definitively opt-out is to remove that code from the platform. Explicitly licensing code under popular copyleft licenses is insufficient.

While the letter of the law here is still uncertain, I believe that Copilot is violating the spirit of these Copyleft licenses. This is deeply disrespectful code laundering at scale. The inability to control the use of your source code is hardly in keeping with the place “where open source communities live”.

It may also be possible to opt-out by making the code private, or potentially signing up for Copilot which exposes a hidden option, but I could find no official documentation that states this definitively.

The mountain of public source code in GitHub’s domain plus their dominance equals a free pass for bad behavior. It doesn’t seem to matter to GitHub that Copilot lifts code directly from the code that makes their platform so valuable. They can do this because we as a community continue to use their platform, thus validating their actions.

Policy decisions

Since 2016, GitHub has been contracting with ICE, the US organization responsible for separating families immigrating to the US. Many of GitHub’s users have asked GitHub to drop this contract.

Some argue that technology is neutral and should be available to all. But technology platforms are absolutely not neutral.

Supporting organizations who seek to harm people, as many believe GitHub is supporting here, only harms more people. That potentially includes your colleagues in the industry, or even you. We should instead be supporting platforms that seek to do no harm.

Who the platform chooses to work with speaks volumes. GitHub’s success as a company also signals that successful companies work with organizations who violate human rights. Again, GitHub’s monopoly in the software industry gives them the freedom to work with whomever they chose without consequence.

Even if you feel that GitHub’s contract with ICE isn’t harmful, it reveals a risk to our industry. GitHub’s de facto monopoly lets them sustain controversial policy decisions. When they make a decision that does harm you, you have no recourse. The only way we get that control back is if GitHub needs its users, not the other way around.

Scope

GitHub makes a lot of things. Here’s a popular subset of the many features they offer, including some I’ve already mentioned:

That’s a pretty large and critical set of developer tools. Using every tool mentioned is the professional equivalent to living in a company town run by a Microsoft subsidiary. While they’re unlikely to take away the popular features listed here, they shutdown, depreciate, or “sunset” features all the time. Even using some of it, if it’s critical to you and you have no alternative, should give you pause.

A tool that is good for you now may change or become inaccessible to you in the future. GitHub may decide to take that tool away. Take the time now to gain some expertise in new tools that can serve as a backup in case your current ones become unusable. And as I argued above, you may even find something that fits your style better.

Homogenization is a risk

I’m reminded of Internet Explorer (IE) in the waning days of the browser wars. IE was once the dominant web browser. If you wanted to make a successful website, you made it work on IE. There were other browsers you could use and build websites for too, but you supported them only after supporting IE.

Having only one platform to build for sounds like it would make web development easy. But after years of ignoring web standards for their own interests, IE lacked modern web features and became outdated and more difficult to work with.

Microsoft had no incentive to support standards; they were the standard for so many years after all. Slowly but surely the other browsers that did adopt web standards gained features that IE lacked, and users could chose the browser that best supported them without needing developer support. As of December 2022, IE is no more.

As a software industry, relying on one company for so much is a huge risk.

You’re allowing a single company who doesn’t have your best interest in mind to have an outsized effect on the industry. While history does repeat itself, these are not web browsers we’re talking about. History also has a tendency to rhyme though, and a dominant company owned by Microsoft sure does feel familiar.

Then what?

I encourage you to try out some other tools. Here are a few things I’ve been trying:

I learn something from every new tool I use, even if it doesn’t become my new default. It makes me more resilient to change and gives me a holistic understanding what I need to develop software.

If GitHub continues to evolve in directions I’m not comfortable with, I have alternatives for some critical tools. I also still use GitHub, but I only choose it when it has something to offer, not because it’s convenient.

For your next side project or experiment, try:

Pick a tool that’s critical to your workflow and find a backup. Understand the features you truly need as opposed to the ones you’re merely used to.

It is a risk to ignore alternative tools and give one company all the power, for yourself and for the industry. Mitigate this risk and get the learning curve out of the way now while there’s nothing personal at stake for you, or financially at stake for your company. Despite it’s success and giant corporate backing, GitHub is not invincible. Better to do this now than under the duress of a future collapsing platform making questionable policy decisions.

A diversity of tools is important to the resiliency of the software industry. Help other platforms and technologies take hold and become viable alternatives. If we don’t, we’re allowing one company to dictate the way we work, sometimes for the worse.

GitHub and git are valid options for developing software, but they are not the only options. Try investing in something else and see what comes of it.