
Ask HN: How did open source work before GitHub? - pvsukale3
How would you publish maintain projects? How would issues be resolved? It will be nice if mention the era in the answer .
like 80&#x27;s 90&#x27;s 2000&#x27;s
======
user5994461
It's very simple: "Just use sourceforge".
[https://sourceforge.net/](https://sourceforge.net/)

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.

~~~
city41
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...)

~~~
danieldk
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.

~~~
mcphage
Absolutely. SourceForge tried to act as gatekeepers of what was worth hosting.
GitHub got out of your way. Much better approach.

~~~
ZephyrP
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.

It _was_ free and 'gatekeeperless' however.

~~~
mcphage
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?

------
pjc50
Kids these days :)

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.

~~~
luckydude
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.

~~~
cyphar
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.

------
db48x
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.

------
kem
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.

------
blacksqr
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.

~~~
Isamu
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.

------
catwell
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.

------
geraldcombs
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.

------
hprotagonist
It's worth noting that kernel development is still git + emailing patches
around. It's too big for github/gitlab.

~~~
algesten
What are you talking about?!

[https://github.com/torvalds/linux](https://github.com/torvalds/linux)

Linus just don't agree with GitHub's pull-requests, so he doesn't accept such
that way.

~~~
cyphar
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.

Also, that is just a mirror. The real hosting is on
[https://git.kernel.org/](https://git.kernel.org/).

~~~
algesten
Ok. I read it as "too big" size wise. Of course I know it's a mirror.

------
coreyp_1
Just sort by year:
[https://en.wikipedia.org/wiki/Comparison_of_source_code_host...](https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities)

Before then, code was often on people's private websites, or FTP servers, with
communication over BBS, email, and IRC.

------
ing33k
Others have pointed at sourceforge , google code . There was also Freshmeat (
renamed to Freecode )

[https://en.wikipedia.org/wiki/Freecode](https://en.wikipedia.org/wiki/Freecode)

------
falcolas
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.

~~~
tyingq
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".

------
roadbeats
See suckless.org for a good example.

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.

------
yladiz
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.

------
brianmurphy
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.

------
tzs
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.

------
herval
SourceForge. Before that, webpages in a "ring". Before that, Usenet/BBS
forums.

SourceForge, specifically, is basically the same as GitHub

------
oceanghost
Hi,

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.

------
protomyth
OpenBSD with anoncvs started in the 90's with showing a live cvs to the world.
That was a nice change from release dumps.

------
skyzyx
I managed SimplePie using a self-hosted SVN repository for the first 5 years
of its life. Contributions exploded AFTER moving to GitHub.

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.

------
NoCanDo
Sourceforge or SVNs. Github didn't revolutionize the open source landscape.
They just gave everybody an easier-to-use GUI.

------
jedisct1
Sunsite.

And new releases were announced on Freshmeat.

------
chrisgoman
Self-hosted Trac (without the "k"). It was usually trac.domain.com

------
payne92
zipped source tarballs w/ anonymous FTP downloads.

Then you emailed diff patches to maintainers and prayed.

------
mdekkers
sourceforge

------
holydude
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

~~~
pluma
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.

~~~
k__
So true.

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.

------
whatnotests
Before GitHub you had Google Code.

Before that was SourceForge.

~~~
srinathrajaram
Can confirm sourceforge was huge

~~~
zhte415
Another vote for Sourceforge; even today it contains a lot of stuff.

~~~
cocoa19
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.

~~~
mdekkers
_Sourceforge got desperate for money and they started modifying installation
packages to contain crapware_

That is only a relatively recent development.

~~~
protomyth
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.

~~~
dragandj
They can do whatever they want, many people won't touch them for the rest of
their lives, I'm among them.

~~~
protomyth
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?

~~~
dragandj
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?

~~~
protomyth
SourceForge isn't owned by the same people anymore, so your example is rather
bogus.

