GitHub as a community management platform?

GitHub is the dominant platform for hosting open source code. It’s hardly ubiquitous, there are other hosting services and many projects self-host. Nonetheless, it’s the go-to place for many FLOSS projects and has lowered the barrier to contribution. Arguably, it’s brought the barrier too low.

At least, that’s my interpretation of an open letter to GitHub published on Thursday. Signed by dozens of project maintainers, the letter identifies troubles that often arise on the GitHub platform and offer suggestions for fixes.

The issues raised in the letter are legitimate, and they’re expressed quite reasonably for something published on the Internet, but they highlight what GitHub is and isn’t. GitHub is a source code management platform, it is not a community management platform.

That’s not to say it can’t be. GitHub is great for what it does, but it could be even better. Managing code is easy; managing contributors and other community members is not. For GitHub to take the next step in promoting open source software development, it needs to provide tools that aid in community. That includes bug and issue tracking, communication (mailing lists?), and other features that turn a project’s users into community members.


I’m a little late to the game, but over the weekend I heard about Hacktoberfest. Sponsored by DigitalOcean in partnership with GitHub, Hacktoberfest is intended to get people to make contributions to open source projects. While I’ve made contributions before, the prospect of a free t-shirt that I don’t need was enough to get me to submit three pull requests on Saturday.

Wouldn’t it be great if I submitted a pull request every week? Then I looked at my todo list and my calendar and walked it back. I think a pull request  (or direct commit to a project I have access to) per month is a reasonable goal. I’ve been meaning to make more contributions to projects for a while, so this may be just the motivation I need.

I need to come up with a catchy name, but I’ll use this blog as a record of what I contribute. In the meantime, if you haven’t signed up for Hacktoberfest, go do that. Happy contributing!

The SourceForge treason

Many of you have undoubtedly heard of what happens to projects that SourceForge deems inactive: the installers get wrapped in a bundled adware installer. Popular projects like nmap, VLC, and the GIMP have found their packages subject to this hijacking lately. Although legally permissible (at least from a licensing standpoint), it’s ethically disturbing. SourceForge says this is a feature — an opportunity for projects to generate a little bit of revenue (assuming they opt in and aren’t hijacked), but it is antithetical to the philosophy of many projects.

Part of the problem is the the “Hotel California” nature of SourceForge. Projects can check out any time they like, but they can never leave. Once a project is hosted on SourceForge, it is reportedly near-impossible for the project to be removed, even if it moves active development to a different platform. On the one hand, this is beneficial to the community, since it ensures abandoned or closed packages will remain available for download. On the other hand, it allows for undesired insertion of adware and other antisocial activities.

SourceForge is clearly no longer a safe place for developers to host projects or for users to download software. That’s a shame, because SourceForge had a take on hosting that other sites seem to ignore. GitHub, BitBucket, and others are very focused on serving as platform for hosting code. They focus on the developer experience. GitHub’s simple interfaces for forking projects and submitting pull requests (whatever technical limitations they may have) have done a great deal for making source code readily accessible and encouraging open development.

SourceForge’s strength was that it provided an easy way for users to search for projects and to download compiled releases. The casual user almost certainly lacks the skills and desire to build packages from source (and many others who are capable certainly don’t want to). The misleading “Click here to Download!” ads aside, SourceForge made it easy for users to get an installer. GitHub has a “Releases” feature which attempts to do this, though it’s not clear that the feature is widely used (full disclosure: I have not used it as a developer or a consumer).

The looming death of SourceForge leaves a real gap in the accessibility of open source to the casual user. It also highlights the dangers of relying on a third-party hosting service (what’s to stop GitHub from doing something similar except the fear of irrelevance?). Self-hosting is not the easy answer it seems, though. Developers are not necessarily systems administrators and may not have the skill or the available resources to maintain their own hosting site, especially for trivial code or code that becomes widely popular. Hopefully SourceForge serves as an example of what not to do and an inspiration for someone to fill the gap better.