GitHub didn't invent anything. They only made a better UI.
SourceForge was more oriented toward software users. It handles the distribution of binaries. Imagine a time when 90% of software sites would redirect you to sourceforge to download them. Distribution was first. The repo and the issue tracker were in a secondary tab.
GitHub is oriented toward developers. It shows you the repo as the main page. You can't distribute binary releases (well, it was added recently).
GitHub took over by attracting developers right at the start of the project. They need a repo, here it is. UI is nice, site works. The new projects eventually become well known and carry the reputation.
SourceForge went downhill slowly with their shady practices. Ads, confusing pages and software repackaged with adware.
FYI my company acquired SourceForge in 2016 and have been improving significantly. No more bundled adware, eliminated deceptive ads, all projects are scanned for malware, https downloads and project web hosting, 2-factor auth & more. Big redesign coming soon too. This is a great thread, but I just wanted to let everyone know the shady practices in the OP are no more.
Thought you'd like to know that my employer blocks sourceforge by policy but let's GitHub through though they're both code sharing platforms. You'll have to change perceptions at the corp level too.
GitHub launched in 2008. SourceForge added git support in 2009. That year delay surely contributed to GitHub taking over. Git was an absolute breath of fresh air after years of SVN (and CVS...)
An enormous difference (which was one of the reasons that I moved to Google Code and GitHub) was that on SourceForge one had to request a project and the SF staff had to approve the project. They would reject projects for all kinds of silly reasons.
On GitHub, you could just create a project and get going.
I switched to Google Code for the same reason. The fact that I had to ask someone before I could create a new repo was insane. It took days to get a new project up and running on SF. Google Code was a little bit nicer but they just let it fall behind the times.
I put my project (a small, windows-only WEP cracker for a very specific wireless device) on SourceForge "for free" -- it was a huge hassle to be sure, having to upload new versions with FTP and so on.
I've learned (from this topic coming up other times) that there were times you didn't need approval for new projects on SF, but there definitely were times where you did. I don't know when, perhaps when they dropped the restrictions I had already moved on to github?
I remember being so confused by SF in its first years. Why would I want this, instead of CVS in AFS or over SSH?
The idea that most software developers wouldn't have routable workstations, wouldn't have servers they controlled---that we wouldn't keep running networked file systems over the Internet---totally not obvious. The SF people foresaw a need in a changing world and got in front of it.
Not the commenter, but guessing AFS = andrew file system.
This has been used for decades by a lot of the universities who were original internet consumers (MIT, Univ of Michigan, Carnegie Mellon, etc). In fact, it is still used by a lot of these universities and research institutions for data sharing and distributed computing, afaik.
Our department is still using it, but it is crumbling. E.g. the macOS clients are outdated. Even when there were still updates, they would come months after a new OS X release.
(It must be a lot of work for the AFS maintainers to keep everything up to date.)
Richard M Stallman will tell you of the days when people mailed tapes back and forth, but that was in the 70s.
A key development was Larry Wall writing "patch" in the early 80s, which he posted to USENET. That made it much easier to start mailing changesets to the maintainers of programs. This workflow continued basically until Linux wrote "git" in the late 2000s. The idea of the pull request formalises the process of emailing Linus.
In the late 90s and early 2000s, most projects had their own CVS server and mailing list. Mozilla decided they would write Bugzilla to keep track of bugs. Sourceforge grew up as an ad-supported hosting and distribution server for CVS (and later SVN) repositories.
Worth mentioning also that in the early through mid 90s, projects hosted their own version control servers, but you needed an account on the development machine to actually have access to the repo. Most people only had access to release tarballs, not the full history, and couldn’t (e.g.) make diffs against CVS head.
OpenBSD developed anonymous CVS, which gave anybody the ability to get the full project history even if they weren’t a developer. (That’s actually where the “Open” in OpenBSD comes from—it refers not to the license, but the development process.)
Larry Wall's patch was a huge step forward. In case you don't know what this is, it takes the output of diff and
tries to apply those diffs to your source files. If diffed
baseline and your baseline are the same then the patch will
apply cleanly. If they are close the patch may apply cleanly (though it may have some messages like "offset 3 lines" which tells you that it found the place to patch 3 lines away from where it thought it was).
There was a big period of time where the Linux kernel work was all
diff/patch based. So the answer was (a) a mailing list that everyone was one, (b) some way of knowing a baseline (you could just have a baseline tree and a copy of that and you diff -Nur the two trees),
(c) email the patch.
All that worked but it didn't scale which is why Linus switched to BitKeeper and then later Git.
It still is diff/patch based (and several people including Andrew Morton don't use Git, they use stuff like quilt). All of the code review is done on patches sent to LKML, git is only used as a merging mechanism for developers to manage their changes. And if you look at Patchwork and other things like that, they have an insane amount of tooling around tracking mailing list patches.
The only thing that Github's pull request system adds that wasn't being done before is single-click merging. Everything else was there. You would email a patch to the author, or to the mailing list, and discuss the merits of the patch there. Then someone with access to the repository would commit it (I use the term generically; version control was less common back then).
The diff program we all use today has it's origins in the 70s, although the unified diff format that we almost always use was created in the 80s.
Email was invented in the 60s, UUCP in the 70s, and Usenet in 1980.
Version control was invented in the 70s with SCCS.
Web-based bug trackers such as Bugzilla originated in the 90s, as did continuous integration software like Tinderbox.
Of all of these, Git represents the biggest improvement over it's predecessors, while email is pretty much still just email. The diff program hasn't changed since the 80s. Bug trackers and other such tools haven't changed dramatically either, although a lot more attention is paid to UX and polish these days.
I think the largest change is the wide availability of these tools today. Everyone knows about them, and it's seen as aberrant to not use version control or bug tracking.
God this more than anything before has made me feel old.
Is GitHub that strongly associated with open source that alternate models for open source development are a mystery? Somehow that's really troubling to me in terms of the open source paradigm, even though I generally see GitHub as a very positive thing. I don't mean that as a criticism of the poster, just saying that it feels like maybe there's some room for more diversity and competition.
I think others have given pretty good descriptions of pre-GitHub models, so I'll leave that to them.
Before the web there was usenet. People would assemble and curate lists of links and post them to newsgroups dedicated to particular languages or fields of interest. People would assemble CDs stuffed with code, you'd send them a few bucks and they'd send you a copy by mail. In the 1980s you'd buy computer magazines and check the classifieds. For a few bucks you'd get a floppy disk mailed to you.
Netscape did a lot to move project management to the web. Bugzilla was written in the mid-1990s. Before that all bug reporting and issue tracking was done via email. If you were good you'd email a patch to the author to fix a bug or add a feature, just as people still do with Linus. He wrote git initially as an improved tool to merge patches received by email.
Walnut Creek sold a CD-ROM that gathered up a lot of usenet source lists. To those of us who had limited access to the internet this got us pretty far.
I remember writing some extensions to usenet software and emailing the author. That opened up a whole world I never knew existed.
I started being involved with Open Source in the early 00s.
For source code, people typically used CVS or (later) SVN. The repos were hosted by platforms like SourceForge, berliOS or Savannah, or on the projects' own servers.
Releases were tarballs hosted on servers. End users sometimes got software by downloading and compiling those, but there were already package managers and repositories. Before most people had Internet at home, at least in France, you could buy CDs with Linux packages at the press store.
Communication between developers typically happened on IRC for casual chat and through mailing lists (hosted with mailman) for serious stuff. Sometimes there were web forums to communicate with users. And conferences, of course. A lot of projects were developed by people who were physically close, for instance people who met at the same Linux Users Group.
Some projects used bugtrackers actively, some did not. It was mostly Bugzilla or Trac. That did not really change too much with GitHub.
The main difference in my mind is that forking was usually regarded as something bad. You would not fork a project and then send pull requests to fix issues.
For a simple fix, you would generate a patch and send it to the project's mailing list, where it would be discussed and eventually checked in by one of the owners. If you wanted to really engage with the project, you would become active in the community and eventually get commit rights.
I think what led to that change of model is: cheap branching in Git, GitHub as a platform with users account, and maybe Continuous Integration making it easier to validate patches.
Self-hosting. SourceForge was certainly popular at one time, but it didn't own the market, certainly not to the extent that GitHub currently does. Many projects were simply run on whatever hardware and connectivity the project could scrounge up. For a project I founded I initially bought a used SPARCstation on EBay and installed CVS, Apache, Mailman, Bugzilla, etc. I traded consulting time with various local ISPs in exchange for bandwidth.
I don't think anyone is claiming that GitHub can't host a mirror of a big git repo. That's not what parent is claiming is "too big".
The problem is that the tooling for reviewing changes on GitHub doesn't scale and also doesn't match the model that Linux uses (deputies). Hell, I would argue large projects like Kubernetes and Rust are hitting these same issues.
You know about the kernel but not how to use your compose key‽
The fact that the kernel is mirrored on GitHub doesn't mean they use it in any sense like the way most projects use it. The real point is that the way Linux is developed has no relation to that GitHub mirror, so it's an example of open source development outside of GitHub.
Mailing lists and Newsgroups (usenet) were both quite popular. Before the internet, it was over dialup BBS systems and CDs/floppy disks.
Just remember that Git was designed around the workflow of the Linux kernel originally. That's why there are commands like "git format-patch" and "git am" which have help messages like "Prepare patches for e-mail submission" and "Apply a series of patches from a mailbox".
It was also not that uncommon to see code patches printed in magazines or snail-mail letters.
This was my experience as well. In fact, source code control tools weren't that high on the list of success factors. Communication and distribution were more important.
"Pull requests" were often just a tarball of diffs against a specific version, sent via email, and discussed on usenet. The code owner had to deal with the merge issues if the tarball wasn't built against "trunk".
As other commenters mentioned, you used Google Code, Sourceforge, and before that you'd email a patch to an email list, specific bug tracker for the project, or to the maintainer. Probably the biggest changes that Github added was the social aspect, and much improved UI compared to most previous tools. It made it much easier to search, browse code in the browser, and add requests to merge features or bug fixes.
Some projects would use older version control systems like cvs.
Others would manage development through email lists. Everyone was good at using the diff & patch commands. Mail clients like mutt were great at searching and sorting email. Releases would go up to FTP servers.
In larger projects, there might have been multiple trees maintained. For example, get your patch into Andrew or Alan's tree before Linus would take it.
In addition to the repository hosts already mentioned, there were also some specialized services for open source for a particular type or class of use.
A good example was CurseForge.com. They provided free SVN, Git, and Mercurial hosting for add-ons for several popular games, along with per add-on issue tracking and discussion.
Add-on authors could host at other, general purpose, hosting sites, but there was an advantage to using CurseForge. Curse.com had an application called the Curse Client for end users. The Curse Client was an add-on manager. It integrated with CurseForge, allowing you to handle searching for, downloading, installing, and updating add-ons from CurseForge right in the Curse Client GUI.
Curse and CurseForge are still around, and support a variety of games. I'm not sure what the deal is with repository hosting there now. I saw some documentation that suggested you are supposed to use an external repository and provide a link to it as part of your CurseForge project settings, but I also see a lot of projects whose repository is on curseforge.com.
I was one of the original contributors to Gentoo in the late 90s (back then it was called Enoch). We had a private FTP site we stored source code and packages at, and we all downloaded regular snapshots of the system. I would archive milestones to CD-R out of a sense of duty+fear.
It sounds primitive, but at the time source control was something only wealthy corporations had.
Many people commenting here say that github did not bring anything new to the game. While that is partially correct we know that bringing only new things does not matter. What matters is slick,seamless polishing of existing ideas and execution. There are many examples of just reinventing the wheel and making it more beatiful and usable.
To your original question: sourceforge was huge, google code, cvs, bazillion of local "downloads.com" etc
I think it's incredibly naive to underestimate how much value GitHub provided by shifting the focus from users to developers and putting contribution front and center.
SourceForge was primarily a way to distribute software. While most software would be under some form of open source license you'd often also find plenty of projects that either weren't really open source or hosted their source code elsewhere. And when the source was on SF, the web interface for browsing it was unintuitive and unhelpful.
The most intuitive use of SF for non-maintainers was downloading releases and leaving comments. There was a separate space for filing issues but it was pretty much just another forum. And let's not forget that contributing code also meant you had to have experience with using SVN (or CVS, I think?) because learning that at the time felt even more daunting than git does now.
Before THAT you were mostly confined to sending patches to newsgroups or mailing lists as far as I recall. I open sourced a single project on SF and beyond that never really got into open source until GitHub made it painless and straightforward -- I doubt I'm the only one.
Sourceforge got desperate for money and they started modifying installation packages to contain crapware, an example is FileZilla. I try to stay away from sourceforge since then.
And one they have stated here on HN that the new owners are ending. Judging by the comments everytime they are mentioned, they need to do a lot more aggressive PR.
How is that a productive attitude in life towards anything? The people who did the deed are long gone, but the people who want to restore and advance SourceForge are SOL?
Because there is competition that have never done anything bad like SF, that offers better products. Would you buy your groceries at Al Capone's, while there's a grandpa's groceries just right next door that offers better, cheaper, and more versatile stuff?
It's not recent at all, it's just something that happened since GitHub first launched, but they had that issue for years. And the recent development is having new owners who stopped that bullshit.
GitHub didn't invent anything. They only made a better UI.
SourceForge was more oriented toward software users. It handles the distribution of binaries. Imagine a time when 90% of software sites would redirect you to sourceforge to download them. Distribution was first. The repo and the issue tracker were in a secondary tab.
GitHub is oriented toward developers. It shows you the repo as the main page. You can't distribute binary releases (well, it was added recently).
GitHub took over by attracting developers right at the start of the project. They need a repo, here it is. UI is nice, site works. The new projects eventually become well known and carry the reputation.
SourceForge went downhill slowly with their shady practices. Ads, confusing pages and software repackaged with adware.