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.

8 thoughts on “The SourceForge treason

  1. re: Github Releases – For most of the things I use Github for, I don’t need it. But…

    I was, for a while, both an R programmer and a KomodoEdit user, and the lack of syntax highlighting for R in KomodoEdit was frustrating, so I found an abandoned set of code, used (and promptly forgot, and forgot to document) the build process, installed the xpi, put the code on Github, and eventually moved to SublimeText and Perl and Javascript.

    Until I noticed the requests for that project. There’s a “max-version” field that was set for 8.* and Komodo moved to 9, breaking it. With Komodo devs help, I set it up, built the new xpi, and made a release.

    If I’m just distributing source code, like my Python FitBit stuff, you don’t need it, but for this purpose, Github Releases make sense.

  2. When you talk about ” a real gap in the accessibility of open source to the casual user” I afraid you overlook bintray.com. Being a cloud-based download center, it is highly tailored for distributing software (binaries, installers, etc.) and it’s totally free for open-source projects. The owner of the project gets access to metadata, download logs, near-real life statistics, and more, and the user gets, among other features, blazing fast downloads from CDN, information about the project and ability to subscribe to new releases.
    Lots of OSS projects already migrated from sourceforge, github and google code to Bintray, including Mac’s Homebrew, official Ruby installer for Windows, HashiCorp’s products, Groovy distributions, Spring.io projects, Netflix opensource projects and many many others.

  3. Just went to the FileZilla site tonight and Chrome put up a huge banner page saying I probably didn’t want to download software from this site due to the fact that it would install undesirable programs and plugins.

    I’m feeling a little sad now.

  4. Baruch, you’re absolutely right. I did overlook bintray.com. I’d actually never heard of it until after this post was published yesterday. I’ve only taken a quick peek at it, but it looks like a great service. Hopefully more OSS projects will continue to move toward it.

  5. @Doug, Nice of Chrome to let you know, though. Apart from grabbing code for my master’s thesis, I can’t remember the last time I downloaded something from SourceForge.

  6. @Baruch, how about if I take some time in the near future to try it out for myself and then write a follow-up post on that?

Leave a Reply

Your email address will not be published.