GitHub is in the news right now, and not in a good way: Engineer Julie Ann Horvath has resigned from the company, alleging serious incidents of harassment and inappropriate behavior.
People seem to be focusing on some of the more prurient allegations - office hula-hooping and so on - but are largely ignoring what to me might be the worst offense: another engineer “passive-aggressively ripping out [her] code from projects [they] had worked on together without so much as a ping or a comment.”
Unfortunately, outside the engineering community it’s not always obvious what GitHub is, and why this kind of behavior, bad anywhere, should be especially unacceptable there. But to understand GitHub, you first need to understand how software engineers work together.
How Do Engineers Collaborate?
Putting aside the jokes about progammers’ social skills, software engineering is, first and foremost, a collaborative effort.
This is both a social challenge and a technical one: Have you ever tried to edit a document at the same time as another person? It gets chaotic pretty quickly, with multiple revisions and corrections flying back and forth. Now imagine not one document but thousands of source files, and not two collaborators but dozens, or hundreds, or thousands. Obviously some system is needed to keep people from stepping on each others’ toes. These are known as revision control systems.
What is Revision Control?
A revision control system (RCS) manages changes to large collections of files, called repositories, or ‘repos’ for short. A repo lives on a server that all the developers have access to.
To work on the codebase a developer “checks out” the code from the repo into a local copy on their computer. The developer then makes changes on that local copy, in isolation. When finished, the developer “commits” the code back to the repo, so others can see it. During this commit process, the system helps the developer properly merge their changes in, resolving any conflicting edits without stomping on other peoples’ work.
The RCS also makes it easy to cleanly revert bad commits, such as ones that introduce critical bugs, even when those commits touched many files.
What is Git?
Revision control is at the heart of any software engineering project. It’s the core technology that allows engineers to collaborate. Naturally, the choice of revision control system is of great importance. And one of the most popular choices is a system called Git.
Git is a revision control system developed in 2005 by Linus Torvalds, the originator of Linux. Git initially served as the RCS for the Linux kernel, which was an early example of a massively collaborative open-source project. However Git use spread quickly, and it’s now the RCS of choice for most new codebases, especially those of startups and open-source projects.
What does GitHub do?
Which brings us, at last, to GitHub.
GitHub is, simply, Git-as-a-service. Recall that in a revision control system the code repository lives on a server that all developers have access to. GitHub provides that server for millions of projects: any individual or organization can create a repo on GitHub. These repos can be proprietary and private, just like an in-house Git server. But the big benefit of GitHub comes from using it openly - allowing people all over the world to browse, share and contribute to open-source projects.
If you regularly contribute to projects on GitHub, your account becomes something of a calling card: any other engineer can read your code, and review and comment on changes you’ve made to those projects.
Coding Conduct
It’s important not to confuse GitHub users - developers who work on projects hosted on GitHub - with developers who are employees of GitHub and work on the code of the GitHub system itself. For example, a recent article stated that GitHub had been embroiled in a diversity controversy over racist and sexist slurs embedded in source code. But that content came from users, not from GitHub employees.
However this distinction cuts the other way too: GitHub is a bit like a bank, except that instead of managing money it manages code. And just as you expect the highest standard of financial conduct from people responsible for the systems that handle other people’s money, so would I expect the highest standard of engineering conduct from people responsible for the systems that handle other people’s code. And this standard was, according to Julie Ann Horvath, trampled on.
Of course engineers are always tinkering with each others’ code - fixing bugs, tweaking designs, adding features. But wholesale deletion of large chunks of code in a live project should never be done without first consulting the original author whenever possible. This would be offensive at any company, but at one founded on the very ethos of engineering collaboration, it’s more than a slap in the face. It’s a declaration of war.
The treatment Julie Ann Horvath describes is not just harassment, it’s nullification. And no engineer, of any gender, should have to tolerate that.
GitHub are currently investigating the issues. I hope this investigation includes an honest look not just at their HR practices but their engineering culture. Respectful collaboration is a key factor in building a high-quality, trustworthy engineering team. And if GitHub wants to host our code, they have to first have our trust.
