Tag: SourceForge

Eight months after dropping support for binary downloads, GitHub re-enabled them and calls them Releases. It’s a welcome move, which in my opinion is vital, as offering binary releases is crucial for any project in a compiled language that 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 dependencies. 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 that allows, actually requires, you to tag your release in version control. That’s something I haven’t seen in other project hosting services, and it 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 a plain download counter will do; you don’t need the full-blown download stats SourceForge has. I really look forward to and hope that GitHub will implement this.

Only a few months 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 support for downloading files from outside the code repository. They say that they believe 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’s a hassle for most people except developers (and possibly Gentoo users :-)).

It might be a good idea on GitHub’s part, as they promote themselves as a developer collaboration tool, and also most of their projects are indeed in dynamic languages (see the top languages statistics). The GitHub team offers two solutions in their post: 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.