I was trying to figure out where the dividing line seems to be for them between forges and GitHub. From some context, it seems like they mean forges as places with centralised structure, as opposed to GitHub which explicitly supports distributed workflow and has some organisation features on top.
For example sourceforge was the home for your project with news and releases up front and development on the side. But GitHub is source-first and even the releases are a not obvious addition.
But that’s just me trying to read between the lines, maybe the authors had a different view.
SourceForge was (is? I’m gonna go past tense from here on because I haven’t used it in forever) different from GitHub in some ways:
It offered a bunch of things besides source hosting, including things like forums and mailing lists, file hosting and so on. Github eventually got some extra features as well, such as wikis, but the general idea was that it was possible (to some degree) for SourceForge to be the place where a project’s community was, rather than just the place where the source code is hosted and bugs are triaged. Remember that this was before Slack, Discord et al., if a project got big enough it would maybe also set up an IRC channel but having a mailing list for developers and a forum for the wider community was pretty much peak communication.
Project pages (this was true for some other “forges”, too) were somewhat more user-oriented, and aggregated news, user reviews and a bunch of other things – sort of like a modern app store, except you could also get at the source. A project’s page was almost like a barebones version of a project’s website. You can still kind of see it: https://sourceforge.net/projects/turbovnc/ , I just picked this one at random. This is kind of like the default repo view page, what with the README and stars/forks display and whatever, but not quite as user-oriented – no reviews, for example, no news (there’s a small mention of releases in the upper-right corner but that’s still a lot more “release management”-oriented than “hello, Random J. User, here’s where you can download our software if you like it”-oriented).
SourceForge, but also some of the other “forges” (like Savannah) allowed people to browse projects by topic, platform, license and many others. This is honestly the one thing I really think Github et al. are doing far, far worse. This was kindda cool, if you were interested in a particular topic (in my case, emulation) you could very easily discover projects on that topic, so if you wanted to learn something, you could find code from which to learn, or new applications to try, a lot easier than you can today. You can still see that, too: https://sourceforge.net/directory/desktop/windowmanagers/ , for example, except this differs from the 2001 experience kind of the way you expect it to differ (i.e. you could fit a lot more content in a much smaller screen and there weren’t as many ads). This was actually just one component of another idea…
…specifically that “forges” were meant to host source code just as much as help users discover new (i.e. your :P) software, find new developers (SourceForge had sort of a “job board” where projects which needed developers could let others know about it – most of these were obviously unpaid volunteer things, but I think there were some “real” jobs there, too) and so on – sort of like being an “interface” with the community.
All that being said, as far as I recall, SourceForge really did end up mostly used for the code hosting feature. New and better communication channels were developed and it became a lot easier to do most of these things (including source code hosting, after a while) externally. Back in 2002 or so, me and some folks who worked on an extraordinarily bad FPS The Matrix rip-off were lucky enough to have our own, fancy phpBB forum for it because two of us, erm, commandeered a server at the company they worked for. But this was before cheap VPSs, it was otherwise unlikely that we could’ve afforded running our own forum, website, CVS, FTP server, IRC and so on. Nowadays you can do all that with like 10$/mo. which is far closer to what you can afford on a student’s budget, and configure as you please, with a lot fewer hoops to jump through, so “forges” are way more limited for how much cheaper they are.
Edit: FWIW, though, all that stuff I wrote above should be taken with a small grain of historiographical salt. The term “forge” predates Github by a good five years, if not more. It likely embodies the same thing that Github embodies – our idea of how we wrote software together back at the time. But, since our idea about how to do it, and our technological means, were pretty different, especially with regards to source code access/version control and how software is distributed to users, the results were also pretty different. That’s why the two seem like they’re very much “the same” thing – they probably really are – but they’re separated by enough of a time difference that they “feel” a lot more different. The difference was a lot more in the “how” than in the “what”, so it’s likely that most of it is somewhat anachronistic.
But, since our idea about how to do it, and our technological means, were pretty different, especially with regards to source code access/version control and how software is distributed to users, the results were also pretty different
This is hinted at in the paper when they mention that SourceForge offered hosted CVS in 1999 when it launched. There really wasn’t an alternative to CVS at the time. Even having a public CVS repo was only just starting to become common at that point. A lot of projects had an FTP site with source tarballs and took patches via a mailing list. Even if they used CVS internally, they didn’t give random Internet people even read-only access to it.
Subversion came out in 2000 and started to gain adoption quite quickly. Most of the hosting platforms supported it fairly quickly, though it took a long time for a lot of projects to move. I seem to remember that it took a long time for both SorceForge and Savannah[1] to gain git repo support and so GitHub was able to grow very rapidly by riding the hype wave that came from Linux’s move to git. This was amplified by the fact that ‘Linux’ has managed to become so conflated with open source that a thread yesterday had several people telling me that I was being unreasonable objecting to the fact that an article about two cross-platform desktop environments was describing itself as discussing the problems of Linux.
[1] If you’ve never had to use Savannah, consider yourself fortunate.
Subversion came out in 2000 and started to gain adoption quite quickly. Most of the hosting platforms supported it fairly quickly, though it took a long time for a lot of projects to move. I seem to remember that it took a long time for both SorceForge and Savannah[1] to gain git repo support and so GitHub was able to grow very rapidly by riding the hype wave that came from Linux’s move to git.
I honestly have no idea what happened back then and why, and… I mean I skimmed the article but it doesn’t shed as much light as I’d hoped, either. Many of the “canaries” they mention, like the DevShare kerfuffle, were pretty late; the way I recall it (but, granted, my memory may be a little foggy here), by 2013, SourceForge was already getting “oh, SourceForge, that’s a name I haven’t heard in a while” reactions all over the place.
Presumably, between the frequent change of ownership and really poor management, the folks at SourceForge really just missed the whole git thing? Maybe some of the “forges” didn’t, but nobody wanted to use them. I mean I don’t think it would’ve helped if Savannah had switched earlier…
It also helped, I guess, that git (and, early on, Mercurial) was pretty good hype wave material. Around 2012 or so there were people at some universities around here were already teaching students to use git, and they were using Github for homework. It certainly helped that there was a lot less ceremony involved in setting up a Github repo vs. a SourceForge project, and that git itself was really easy to use locally. Then you had whole generations of students coming out of school knowing git.
But other than that… Github is one of those things that I admit to never getting. I jumped on the git bandwagon early on because I really did like the distributed VCS idea – my first choice would’ve been Mercurial but we all know how that ended. But Github… I always found the web-based pull request thingies really awkward to use, the issue tracking is pretty awful, and it’s practically useless for discovering new things. I kind of felt like Github was primarily about fixing a lot of things that made git really hard to use for most projects (which, for various reasons, can’t quite adopt the Linux kernel workflow), and there were so many of those that there was never any time to make it as good a platform as SourceForge was.
Many of the “canaries” they mention, like the DevShare kerfuffle, were pretty late; the way I recall it (but, granted, my memory may be a little foggy here), by 2013, SourceForge was already getting “oh, SourceForge, that’s a name I haven’t heard in a while” reactions all over the place.
That matches my recollection. If I found something on SourceForge after about 2010, maybe a couple of years earlier, my reaction was ‘oh, they’re still on SourceForge, that probably means that it’s not maintained anymore’.
Presumably, between the frequent change of ownership and really poor management, the folks at SourceForge really just missed the whole git thing? Maybe some of the “forges” didn’t, but nobody wanted to use them. I mean I don’t think it would’ve helped if Savannah had switched earlier…
I think there was also a more subtle shift that they missed: the Google-led shift to minimalistic interfaces. The SourceForge and Savannah interfaces looked incredibly cluttered. In a world where Google had built one of the most successful companies in the world out of a UI that had one picture, a text field, and two buttons, SourceForge looked incredibly dated.
I kind of felt like Github was primarily about fixing a lot of things that made git really hard to use for most projects (which, for various reasons, can’t quite adopt the Linux kernel workflow), and there were so many of those that there was never any time to make it as good a platform as SourceForge was.
I’ve written about this a bit in an internal memo. Disruptive technologies grow out of flawed products. Subversion was better than CVS but was basically fine for what it did. Subversion GUIs were not very common because the command-line interface was not bad (not great, but basically fine). Git was significantly worse in terms of basic usability than either svn or hg. This meant that there was a big demand for tooling. The git GUIs that I’ve used are all far better than their svn or hg equivalents and are better than the command line interfaces for either. FreeBSD jails and Solaris Zones are another example: they both work well and make it trivial to create an environment with shared-kernel virtualisation. As a result, no one bothered building much tooling on top of them. To get the same thing on Linux, you needed to tie together a bunch of unrelated kernel subsystems and at that point you’ve got a big userspace tool stack that you can add packaging and things to. I don’t believe modern container workflows could have emerged from FreeBSD or Solaris because their shared-kernel virtualisation had reached local optima where the cost of innovation was higher than any benefit. At this point, I think Linux is probably at the ‘good enough’ state for a very large number of things and so I expect that it is going to be displaced by a disruptive technology in a number of domains over the next decade. It’s relatively easy to identify products that are at this kind of local optimum, it’s very hard to identify the things that will displace them.
Sure, I get that they have somewhat different feature sets, but the definition of “forge” provided by the article itself does not encompass any of these distinctions.
It doesn’t, and it probably can’t, since there were a lot of “forges” and their feature sets differed. Plus the term itself is way older than GitHub. If Github had been a thing back in 1999 it would’ve probably been called a forge, too.
I agree on the release management and end user focus. When I wanted some software: codecs, gimp as you mentioned, other things, and I needed it on Windows, that’s where I would look. Rather download the exe from SF then from whatever shady website somewhere.
I didn’t go there for sources, those i would mostly still be looking on FTP sites, if I needed them.
Google Trends shows SourceForge in a long, linear decline starting in 2006. GitHub only began in 2008 and took 5 years to reach the traffic that SourceForge had back in 2004. So it’s not a straightforward story of GitHub replacing SourceForge. Instead bad management at SourceForge was killing it before GitHub even started.
It probably doesn’t help that SourceForge came out of VA Linux, one of the worst of the dot-com bubble companies, and most of the original developers likely got laid off in the early 2000s.
OK, so like github?
OK, so … not github?
I don’t get it.
I was trying to figure out where the dividing line seems to be for them between forges and GitHub. From some context, it seems like they mean forges as places with centralised structure, as opposed to GitHub which explicitly supports distributed workflow and has some organisation features on top.
For example sourceforge was the home for your project with news and releases up front and development on the side. But GitHub is source-first and even the releases are a not obvious addition.
But that’s just me trying to read between the lines, maybe the authors had a different view.
SourceForge was (is? I’m gonna go past tense from here on because I haven’t used it in forever) different from GitHub in some ways:
READMEand stars/forks display and whatever, but not quite as user-oriented – no reviews, for example, no news (there’s a small mention of releases in the upper-right corner but that’s still a lot more “release management”-oriented than “hello, Random J. User, here’s where you can download our software if you like it”-oriented).All that being said, as far as I recall, SourceForge really did end up mostly used for the code hosting feature. New and better communication channels were developed and it became a lot easier to do most of these things (including source code hosting, after a while) externally. Back in 2002 or so, me and some folks who worked on an extraordinarily bad FPS The Matrix rip-off were lucky enough to have our own, fancy phpBB forum for it because two of us, erm, commandeered a server at the company they worked for. But this was before cheap VPSs, it was otherwise unlikely that we could’ve afforded running our own forum, website, CVS, FTP server, IRC and so on. Nowadays you can do all that with like 10$/mo. which is far closer to what you can afford on a student’s budget, and configure as you please, with a lot fewer hoops to jump through, so “forges” are way more limited for how much cheaper they are.
Edit: FWIW, though, all that stuff I wrote above should be taken with a small grain of historiographical salt. The term “forge” predates Github by a good five years, if not more. It likely embodies the same thing that Github embodies – our idea of how we wrote software together back at the time. But, since our idea about how to do it, and our technological means, were pretty different, especially with regards to source code access/version control and how software is distributed to users, the results were also pretty different. That’s why the two seem like they’re very much “the same” thing – they probably really are – but they’re separated by enough of a time difference that they “feel” a lot more different. The difference was a lot more in the “how” than in the “what”, so it’s likely that most of it is somewhat anachronistic.
This is hinted at in the paper when they mention that SourceForge offered hosted CVS in 1999 when it launched. There really wasn’t an alternative to CVS at the time. Even having a public CVS repo was only just starting to become common at that point. A lot of projects had an FTP site with source tarballs and took patches via a mailing list. Even if they used CVS internally, they didn’t give random Internet people even read-only access to it.
Subversion came out in 2000 and started to gain adoption quite quickly. Most of the hosting platforms supported it fairly quickly, though it took a long time for a lot of projects to move. I seem to remember that it took a long time for both SorceForge and Savannah[1] to gain git repo support and so GitHub was able to grow very rapidly by riding the hype wave that came from Linux’s move to git. This was amplified by the fact that ‘Linux’ has managed to become so conflated with open source that a thread yesterday had several people telling me that I was being unreasonable objecting to the fact that an article about two cross-platform desktop environments was describing itself as discussing the problems of Linux.
[1] If you’ve never had to use Savannah, consider yourself fortunate.
I honestly have no idea what happened back then and why, and… I mean I skimmed the article but it doesn’t shed as much light as I’d hoped, either. Many of the “canaries” they mention, like the DevShare kerfuffle, were pretty late; the way I recall it (but, granted, my memory may be a little foggy here), by 2013, SourceForge was already getting “oh, SourceForge, that’s a name I haven’t heard in a while” reactions all over the place.
Presumably, between the frequent change of ownership and really poor management, the folks at SourceForge really just missed the whole git thing? Maybe some of the “forges” didn’t, but nobody wanted to use them. I mean I don’t think it would’ve helped if Savannah had switched earlier…
It also helped, I guess, that git (and, early on, Mercurial) was pretty good hype wave material. Around 2012 or so there were people at some universities around here were already teaching students to use git, and they were using Github for homework. It certainly helped that there was a lot less ceremony involved in setting up a Github repo vs. a SourceForge project, and that git itself was really easy to use locally. Then you had whole generations of students coming out of school knowing git.
But other than that… Github is one of those things that I admit to never getting. I jumped on the
gitbandwagon early on because I really did like the distributed VCS idea – my first choice would’ve been Mercurial but we all know how that ended. But Github… I always found the web-based pull request thingies really awkward to use, the issue tracking is pretty awful, and it’s practically useless for discovering new things. I kind of felt like Github was primarily about fixing a lot of things that made git really hard to use for most projects (which, for various reasons, can’t quite adopt the Linux kernel workflow), and there were so many of those that there was never any time to make it as good a platform as SourceForge was.That matches my recollection. If I found something on SourceForge after about 2010, maybe a couple of years earlier, my reaction was ‘oh, they’re still on SourceForge, that probably means that it’s not maintained anymore’.
I think there was also a more subtle shift that they missed: the Google-led shift to minimalistic interfaces. The SourceForge and Savannah interfaces looked incredibly cluttered. In a world where Google had built one of the most successful companies in the world out of a UI that had one picture, a text field, and two buttons, SourceForge looked incredibly dated.
I’ve written about this a bit in an internal memo. Disruptive technologies grow out of flawed products. Subversion was better than CVS but was basically fine for what it did. Subversion GUIs were not very common because the command-line interface was not bad (not great, but basically fine). Git was significantly worse in terms of basic usability than either svn or hg. This meant that there was a big demand for tooling. The git GUIs that I’ve used are all far better than their svn or hg equivalents and are better than the command line interfaces for either. FreeBSD jails and Solaris Zones are another example: they both work well and make it trivial to create an environment with shared-kernel virtualisation. As a result, no one bothered building much tooling on top of them. To get the same thing on Linux, you needed to tie together a bunch of unrelated kernel subsystems and at that point you’ve got a big userspace tool stack that you can add packaging and things to. I don’t believe modern container workflows could have emerged from FreeBSD or Solaris because their shared-kernel virtualisation had reached local optima where the cost of innovation was higher than any benefit. At this point, I think Linux is probably at the ‘good enough’ state for a very large number of things and so I expect that it is going to be displaced by a disruptive technology in a number of domains over the next decade. It’s relatively easy to identify products that are at this kind of local optimum, it’s very hard to identify the things that will displace them.
[Comment removed by author]
Sure, I get that they have somewhat different feature sets, but the definition of “forge” provided by the article itself does not encompass any of these distinctions.
It doesn’t, and it probably can’t, since there were a lot of “forges” and their feature sets differed. Plus the term itself is way older than GitHub. If Github had been a thing back in 1999 it would’ve probably been called a forge, too.
I agree on the release management and end user focus. When I wanted some software: codecs, gimp as you mentioned, other things, and I needed it on Windows, that’s where I would look. Rather download the exe from SF then from whatever shady website somewhere.
I didn’t go there for sources, those i would mostly still be looking on FTP sites, if I needed them.
Google Trends shows SourceForge in a long, linear decline starting in 2006. GitHub only began in 2008 and took 5 years to reach the traffic that SourceForge had back in 2004. So it’s not a straightforward story of GitHub replacing SourceForge. Instead bad management at SourceForge was killing it before GitHub even started.
It probably doesn’t help that SourceForge came out of VA Linux, one of the worst of the dot-com bubble companies, and most of the original developers likely got laid off in the early 2000s.