How was SourceForge not like Github?

A few days ago, this got posted on lobste.rs and a few other discussion forums. And, not that it's unexpected by now, one of the questions that popped up every now and then was "so... forges were kind of like Github, right?" Was SourceForge basically like Github?

The short version is that yep, it was. Well, is, I guess -- SourceForge is still around after all -- but I'm going to talk about it in the past tense because it's mostly dead. But lots of things have changed about how we do open source and I wanted to talk about them for a bit.

Way back in 2013 or so, was already finding myself explaining some of my younger colleagues what SourceForge had been all about, and there was already a bit of a culture gap to cross. By now, I think this gap has widened enough that there's actually some lessons to be drawn from it, and that having a better understanding of it might help understand why some things about Linux, BSDs, and popular Unix and Linux programs are the way they are.

A note about anachronism

First, a bit about terminology. The term "forge" -- which denotes websites like SourceForge or Savannah -- is pretty old, and it predates Github by several years. It's likely that, if Github had been around in the early 00s, we'd have called it a "forge", too. We would've probably said it uses a rather strange VCS, and that it's somewhat lacking in features in some departments, but also that it was certainly far ahead of the others in other departments, so this isn't a "back in my day" thing.

But either way -- and this is the point I want to make -- it's important to resist the temptation of reading too much into a change of terms. SourceForge and Github are both embodiments of the same set of ideas: they embody our idea of how open source development happens. But, since they come from different ages, the ideas they embody turn out to be pretty different in some ways.

Which ways? Well... that's what we're here to talk about!

Forges and community hubs

I think the biggest difference in terms of "what forges were" and "what Github is" lays in the features that forges offered besides code hosting.

Remember that the heyday of SourceForge was in the late 90s and early 00s. This was before the days of cheap VPS. Back in 2002, me and a couple of nerds working on an extraordinarily bad The Matrix rip-off first-person shooter were enjoying an extraordinary luxury: we had our own (phpBB!) forum, we had a FTP server with a lot of file hosting space, and even an IRC server.

That could happen because one of us worked someplace with not so much supervising and he pretty much commandeered a server and that was it.

That wasn't easy for everyone. But SourceForge got your back: SourceForge had file hosting, forums, even mailing lists. The "default" project page was kind of like a project's website, aggregating news, user reviews and a bunch of other things.

In addition to that, SourceForge also featured a bunch of "cross-project" forums, like a... job board of sorts, although I'm not sure that would be the correct term, since most of the positions were obviously volunteer positions. But it was very much like a job board: maintainers of various projects could post "help wanted" ads in various boards, depending on what their projects needed -- development, documentation, graphics, sound production and so on. I think some of them were paid, but I'm not sure -- most of them were definitely not, though, they were "help wanted" posts from indie development teams, not job ads from real companies.

SourceForge was, to some degree, a community hub, more so than Github. This was true of other "forges" as well, but to various degrees, and in various ways, the feature set wasn't entirely uniform.

Forges and software discovery

SourceForge was also, in some ways, kind of like an app store. It indexed its projects by category and allowed you to browse them. In turn, when creating a new project, you could provide a whole lot of data about it -- it wasn't a free-form README.md, but a whole form with a title, a description, a set of features and so on. This is the one feature I really, truly miss -- SourceForge was a wonderful place to discover new things and learn new things. Github is really bad at this.

This was pretty common back then. Freshmeat, later Freecode, aggregated indexes and release news from several sources, including SourceForge, and had... some of the good parts of app stores, without most of the bad parts. Its modern successor, freshcode.club, is still around, but it's not good for much other than serving as an example of how these things worked.

Running development and distributing software

These differences don't look entirely substantial but they are worth putting in context. Developing and distributing open source software happened along somewhat different lines back at the time, and forges evolved to facilitate that kind of development, and were in turn influenced by them.

First, it's important to remember that all of this happened before pervasive, easy and cheap (to the point of being practically free) CI. Releases were a big-ish deal. If you didn't get something through your distro's package manager or the ports tree, the way you'd get it was usually by compiling from a release tarball. Checking things out of the development tree was mostly done if you wanted to contribute patches or reproduce bugs. It was infrequent enough that, back at the time, I didn't really know CVS incantations by heart.

Second, development in general, even open source, was often not quite as... open as it is today. Prior to forges becoming mainstream it was not completely uncommon for source to be open as in, you had access to release tarballs, but it was usually only the contributors who had access (even read-only) to the main repo. By the early '00s, read-only anonymous CVS access was the norm, but a lot of development still happened by mailing patches.

Forges were not very involved in this stuff. I don't recall SourceForge ever gaining something akin to the Github pull request system (but I may be wrong here, I never used it much). They sought to serve as community hubs, but not so much as central workflow hubs.

They did serve as distribution hubs, but in a pretty different fashion: releases -- in the form of release tarballs -- really were important. Unless you had very specific reasons to do otherwise, you'd compile from the release tarball, rather than check out a specific CVS revision, the way you now checkout from specific git tags. But that meant the source code management flow and the release management flow were separate to a much higher degree than they are today.

Github did, at some point, develop the "releases" feature, which is actually pretty close to how SourceForge handled them. But it either never really developed some of the additional dissemination tooling around it, like release alerts or a frontpage with release news, or it didn't really feature the parts it did develop.

That's because, in many projects today, a release just isn't as major a milestone as it was back when half your users ended up getting the new release from a CD bundled with a magazine or by downloading them at work and installing them offline at home. Firefox has a new release every month -- to say nothing of SaaS "applications", which barely have "releases" to speak of.

Was it better? Worse?

It was very different. In many ways, git and the services it spawned, like Github and Gitlab, are embodiments of the "worse is better" story. git is dirtier and less ambitious than many version control systems from the 1990s, and needs a lot more additional tooling to use it in non-trivial projects (NB: someone on lobste.rs has a few more relevant points on this topic). At the same time, by focusing on doing fewer things, it can do them better, and by being less generic and less ambitious, it can do them with a lot less architecture astronautics. That's true of git, but also of the tooling around it -- like Github.

The software index, with its easy discovery and browsing, is pretty much the only part I really miss. For everything else, I think the tools we have at our disposal today are generally better. Even the tools we had at our disposal back then were generally better, if you could afford them: SourceForge project forums were pretty dead, for instance, because as soon as a project gained enough traction to be worth spending some money on (or have enough volunteers with spare CPU cycles on their servers), they got a "real" forum.

The article I mentioned earlier is worth reading. It's a good history lesson, and most of the points it makes about running large web-based services, with large communities, are relevant to this day.