Binary Downloads are Back at GitHub

Eight months after dropping support for binary downloads, GitHub re-enables them and calls them Releases. It’s a welcomed move which in my opinion is vital as offering binary releases is crucial for any project in a compiled language which targets end-users (as opposed to developers). Plainly put, when a user wants to download and use some software, he doesn’t want to mess with compilation issues and dependency. Unless of-course he is a Gentoo user, and then he’s probably more of a developer than a regular user).

The new GitHub releases have a nice feature which allows, actually requires you, to tag your release in the version control. That’s something I haven’t seen in other project hosting and it’s looks really positive. However, they still lack a basic feature SourceForge has had for years – download stats. It’s really nice to be able to know how many people downloaded each release of your project. Even plain download counter will do, you don’t need the full-blown download stats SourceForge has. I really look forward and hope that GitHub will implement this.

GitHub Stops Offering Binary Downloads

Only few month ago, almost anyone would swear by GitHub and curse SourceForge. GitHub was (and probably still) the fastest growing and by now the largest code repository, while SourceForge was the overthrown king. SourceForge looks like an archaic service despite some major facelifts while GitHub is the cool kid on the block. Recently, GitHub showed us why SourceForge is still relevant for the open-source community.

Back in December, GitHub dropped their support for downloading files from outside the code repository. They say that they believe that code should be distributed directly from the git repository. This is probably fine for projects written in dynamic languages (such as python, ruby, javascript) where no binary distribution is expected. However, this seems to me like a blow to any GitHub hosted C/C++ project. No one expects lay users to compile projects directly from source, it a hassle for most people except developers (and possibly Gentoo users :-)).

It might be a good idea on GitHub team, as they promote themselves as a developer collaboration tool, and also most of their projects a indeed in dynamic languages (see the top languages statistics). The GitHub teams offers in their post two solutions: Uploading files to Amazon S3 and switching to SourceForge, and I’ve read at least a few people recommending putting binary releases in the git repository (bad idea).

Overall, I think this move by GitHub, just turned SourceForge into the best code repository (for compiled code) once again.