Ask HN: How did open source work before GitHub?
How would you publish maintain projects? How would issues be resolved? It will be nice if mention the era in the answer .
like 80's 90's 2000's
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.
For those interested in more information I did an AMA here: https://www.reddit.com/r/sysadmin/comments/4n3e1s/the_state_...
And Ars coverage here: https://arstechnica.com/information-technology/2016/06/under...
On GitHub, you could just create a project and get going.
It was free and 'gatekeeperless' however.
After that all companies I worked with used Git. I never really understood was SVN added to the game...
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.
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.
(It must be a lot of work for the AFS maintainers to keep everything up to date.)
And Berlios!
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.
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.)
Here’s the anoncvs paper: https://www.openbsd.org/papers/anoncvs-paper.pdf OpenBSD’s latest release song was actually about this topic: https://www.openbsd.org/lyrics.html#61
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.
typo: it’s "Linus".
There's a story of an AT&T source tape being left on a street corner by an anonymous donor in the early days of (I think) BSD.
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.
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.
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.
I remember writing some extensions to usenet software and emailing the author. That opened up a whole world I never knew existed.
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.
https://github.com/torvalds/linux
Linus just don't agree with GitHub's pull-requests, so he doesn't accept such that way.
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.
Also, that is just a mirror. The real hosting is on https://git.kernel.org/.
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.
Before then, code was often on people's private websites, or FTP servers, with communication over BBS, email, and IRC.
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.
"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".
Personally, I used to put them under my personal website, seperating each to a subdomain. If you'd like to see source code, you'd download it.
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.
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.
SourceForge, specifically, is basically the same as GitHub
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.
The AWS SDK for PHP started life as a project called Tarzan on Google Code.
GitHub made code feel more accessible. It made contributions easier. It improved the visibility inside the project.
And new releases were announced on Freshmeat.
Then you emailed diff patches to maintainers and prayed.
To your original question: sourceforge was huge, google code, cvs, bazillion of local "downloads.com" etc
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.
Coming from times when I had to download my PHP libs from SF and trying to get some fixes landed, everything's much different and better now.
I get everything via a simple npm install and landing PRs has never been easier.
Before that was SourceForge.
That is only a relatively recent development.
3 points by loganabbott 367 days ago
(Something I think of re-creating now and again, but maybe with distributions containing packages people don't need such a thing any more?)