Failure of Leadership in GitHub Collaborators for Software Development

By Rich Jones

    GitHub has been massively transformative for people who write computer software. More people than ever are using version control and I would attribute a lot of this to GitHub, both beacuse of its convenience and because of a general cultural shift which has placed GitHub as the default code store. However, the lower barrier for entry of open software development has created an unfortunate void of leadership which may be causing overall code quality to suffer.

The Old Guard and the New Class

    GitHub culture is a lot different than the old culture of open software development, which took place largely on mailing lists and unfederated SVN servers, with binaries hosted on SourceForge. GitHub centralizes all of these functions, makes everything publicly discoverable and adds a social layer which makes following projects and developers easier. The old guard, with their beards, ThinkPads and coffee are being replaced by a new class of clean-cut developers, armed with shiny MacBooks and blister packs of Modafinil.

    On the whole, I think that the rise of GitHub has been a tremendously positive thing, largely as it means that there is now more open source code and that more people are writing Free software, even if they're doing it just because they're too cheap to spring for GitHub's overpriced private repositories.

Leadership

    However, there is a major flaw with the GitHub model of collaborative software development: Leadership.

    I'm going to illustrate this with two opposing examples. They aren't diametrically opposed, one is simply a personal experience and the other is a bit too extreme, but I hope they will accurately illustrate the point I am trying to make anyway.

    As a Django developer, I regularly use a package called 'Django-Userena', which provides a nice accounts management system that allows for private messaging between users, something that a lot of modern webapps need to have. It isn't the best code in the world, but it makes my life easier. So after recommending it to a collegue, I was very disappointed to see that my existing code which I had lent to him was suddenly broken. After much swearing and fiddling in the terminal, it seemed that I was using version 1.0.0 and my friend 1.0.1 - the .0.1 change had introduced a fundamental change which broke all code written for previous versions. I was pretty pissed about this, and found that somebody had already opened a ticket on the GitHub issue tracker about the problem. It turns out that the change had been made as a result of a different feature request opened by a Brazillian college student. His issue was really beyond the scope of Userena, but the core Userena developers are nice guys and introduced some trickery to solve the issue - unfortunately, their tricks broke everything for all the other users. A vocal minority and friendly, well-meaning developers unfortunately caused a lot of problems for a lot of people.

    Now, I'm going to mention the name of a man which might bring up painful memories for some of you. He is not a well-liked man, in fact he is despised in some circles, but I will be saying his name here with praise. Hear me out.

    The name of the man is Ulrich Drepper. Ulrich is the maintainer of glibc, which is arguably the most important aspect of a GNU/Linux system aside from the kernel itself. Now, a lot of people think that Ulrich Drepper is an asshole. A lot of those people have filed tickets with glibc, only to have them rejected as invalid, even the ones bearing patches. And that's what makes Ulrich Drepper a great leader. So many people depened on glibc that he can't simply make changes to the code because it make things easier for a small subset of users - there has to be a real need for the change. Ultimately, his job is to say no, no, no, no, no - to keep the riff-raff out.

    Ulrich Drepper is an asshole, and that makes him a great leader. (As an aside, Ulrich Drepper is actually _too much_ of an asshole to the point where Debian have actually stoped using glibc in favor of eglibc, largely because he's such an uncooperative jerk. Still, my points stands - Drepper himself has written about this in a technical essay called The Dictatorship of the Minorities. I probably could have used Linus Torvolds as a better example.)

Culture

    Now, this is a cultural difference, but it does have a big impact on the process of development. If I'm going to be working on or with a library maintained by the 'old-g(n)uard,' I can safely assume that I won't have any problems if I work from the most recently tagged version. If I want to use a library or componant from GitHub, my first step is always to click on the handy Network Graph tab, which gives me a picture of the development history of the project and where it currently stands. If there are too many forks relative to the size of the userbase that aren't ever being merged back in, or are they are _all_ being merged back in, then I know something might be a bit fishy.

What To Do

    Now, the real question is what to do about this, and to be honest I'm not quite sure. Do I think that people should start being an assholes to each other on GitHub? Absolutely not - I like that GitHubbers are a friendly bunch and I wouldn't want to change that. So then what's to be done about the slipping quality of code, driven by a vocal minority of request issuers and overly compliant maintainers?

    I suggest that we patch the culture with a few simple, common-sense guidlines for about how decisions are made. For instance, patches may not be accepted if they degrade performance. Feature requests may declined if they are outside of the scope of the project. For any updates which break existing functionality must be incorporated into major releases, any documentation must be updated ahead of time and users must be given prior warning. It isn't rude to say 'no' if you explain yourself.

    I don't think this is too much to ask for, and hopefully it will result in a supportive collaborative development environment that still produces high-quality software. My appologies if this read as an extended gripe about a minor bug, but I believe that our culture is important, and worth examination.

See More Posts About:

Github


Posted by Rich Jones

LinkedIn Website