Having worked at sf.net for a few years as github was gaining ascendancy, I would say that we thought about this a lot. And while a lot of the things that he says are true, they're symptoms of why sf.net lost, not the real reason.
The real reason why sf.net lost was much more fundamental than that. Really it was so fundamental that it was a business problem rather than a technology problem. As a company, management just wasn't that interested in competing, and therefore we didn't have the institutional ability to focus on competing with some of the things github did.
I am proud to say that it looks like sf.net finally has a fork button, though, and it also looks (from the outside) like there's some focus on delivering developer oriented features now on sf.net, so that's a positive thing.
The engineering and ops team that's over there is awesome and has great open source pedigrees, and has always been super interested in working on things that would make open source development better and easier, but really has been hampered from doing that for years by more basic business issues. I think things might finally be turning around for them, though.
Here's another take on this - programmers hate ads and SourceForge is riddled with them. GitHub isn't.
Also, if I want to setup a repo and put it on GitHub, it's stupidly, ridiculously easy. SF isn't hard, but it isn't as easy.
Open source software is about PROGRAMMERS collaborating. GitHub makes that incredibly easy and straightforward. Want to join a project? Fork the code and tweak til your hearts content. Your code shows up in the network and other people can find/clone/fork/hack til their hearts are content. Want to contribute to a SF project? Um... contact the dev and hope the project isn't dead?
SF is designed to be a kind of Download.com for FOSS. For that it's fine, but GitHub is designed for developers to share code.
Also, GitHub is great because it also does private code hosting, so if I'm working on my own stuff or FOSS stuff, I can use GitHub for both. That is incredibly convenient.
I think that's an understatement. Sourceforge is so bad that for years (well before Github) I have dreaded downloading anything from it or needing to use its navigation in any way.
Also, a fair bit of malware has been hosted there over the years and the site offers no useful search or way of finding what you're looking for.
The initial idea was a good one, but the founder cashed out long ago.
E.g., wget support was broken for a very long time. So, you had to either a. algorithmically compose a URL or b. navigate to the real download link using the browser, collating all of them together and then wget -i blah.
You know as much as I hate these terms, I think nothing captures the undeniable yet intangible difference between SourceForge and GitHub as Web 1.0 vs Web 2.0.
For the younger members here I think it's hard to imagine just how freaking cool SourceForge was when it first came out. The idea of free, featureful project hosting was amazing. Back in the 90s, even if you had free hosting, there wasn't the selection of easy-to-install FOSS web software that we take for granted today. It's sort of like how cool Slashdot was in a world of Usenet and BBSes. Amazon, Ebay, Yahoo. It's easy to forget how impressive Web 1.0 was for its time.
GitHub by contast came out of the Web 2.0 era where we had solid CSS, solid JS/AJAX, solid web frameworks, and a lot of hard-earned knowledge of UX design, and perhaps more importantly the browser technology to support it. I think the article makes a good distinction between code hosting and project hosting, and no doubt that makes GitHub's job easier, but it's not the whole story. GitHub is the result of a holistic vision that goes from the metal up to the UI and design bits. In the early days of the web putting together a team to do something like that was well-nigh impossible. With the ubiquity of the web today, the new generation of web folks can much more easily pick up both the technical and design skills to create the kind of amazing UX experience that sets GitHub apart from SourceForge.
Sourceforge seems unable to evolve because its business model is stuck in Web 1.0: bring as many visitors as you can and throw as many intrusive ads as possible in front of them before they can get what they wanted in the first place and leave.
As far as the terms themselves, O'Reilly was talking about a change in focus from software to data... http://twit.tv/floss73
From that angle, then: SourceForge is a great place to download installers, while GitHub is a great place to get the nitty-gritty details about making a bit of software.
I would only argue one point in this: Github is not a developer's paradise. It's good. In fact, it's really good. But it has one huge weakness, something which all DVCS repositories seem to have followed: they charge per repository.
This is a terrible pricing model. It should, if anything, be based on per-GB of storage regardless of repositories. Otherwise it gets hideously expensive for people to, say, have many small repositories.
It just doesn't make sense that, say, the Linux kernel, and a 500 line personal Ruby project are equal units as far as Github is concerned.
Bitbucket charges by "private users". You can host as many open source projects as you want--many forks of the Linux kernel, for example--for free. However, if you want a private repository, you can only give read/write access to 5 people with the free account. https://bitbucket.org/plans
That's why I use it for all my projects--I have a Plan 9 kernel fork, an Inferno OS fork, and a bunch of smaller projects for a total of 13 repos, on the free plan.
Even though I prefer mercurial to git, Bitbucket could get a lot of converts if they started supporting git. Bitbucket is not the serious competition that I'd like to see Github get. For developers that prefer Hg to Git, Bitbucket has to compete with Google Code, Codeplex, and others...
fwiw, github doesn't really care about disk space for free plans as long as it's not being abused.
i was hosting the source code for my android rom on bitbucket because i would have had to pay for a big github account (over 1gb of code in 166 repos). i emailed github's support team and they said it wouldn't be a problem, so i moved everything to github.
For Git projects, the per-repo pricing of Github is insane. They don't even have a public pricing plan for the number of repos I'd need for my personal (and private) coding.
100% Agree. I have 5 different GitHub accounts to cover all of my repositories, and I'm constantly having to shuffle active projects in and out of GitHub. I've emailed them asking for different pricing, and "they don't support that".
It's the only thing that has me looking for alternatives.
I think this is intended as a "tax" on closed source software. While it's annoying, I pay the extra $10 per month to get a few extras and don't worry about it.
The major downside is that the policy leads people to use git incorrectly by not using submodules where they are appropriate.
GitHub wants to encourage people to make their repositories public, it's their "social" feature, so I can see why they do it, but as an end-user I agree with you that per-Gb or per-user, with as many private repos as you want, would be a better model.
My company using Github for hosting many small repositories (typical web agency model) but they can be surprisingly accommodating when it comes to hard limits to plans, and it’s still fairly cheap compared to administering our own solution.
I like Github a lot, and SourceForge has definitely dropped the ball, but is anyone else tired of linkbait article titles? SourceForge has a ton of projects still. They didn't "lose" anymore than Github "won". Competition is trip not a destination. Nothing is for sure, and there's no reason why SourceForge can't improve their service and take back more of the market.
Us in the tech world need to stop thinking that something needs to "win" and "lose". It has fueled way to many (idiotic) religious wars about editors, compilers, and other technologies. Solve problems. Make the world a better place. And quit trying to find "losers".
That may be true, but I suspect that many, if not most, new projects aren't created on SourceForge anymore.
Most statistics are lies, of course, but Github currently has 2M repositories (including forks), as compared to Sourceforge's 300K projects. Seeing as how SF is over ten years old and Github was launched in 2008, that says to me that Github's where the real action is now.
Sourceforge was always hard for me to use, the standard template (code, forums, issues, mailing lists, wikis) were hard to set up (my experience) and use.
GitHub's UI really made impact on me, and the short name, the agenda from the people (I've seen couple of videos from the founders talking about not github, but GIT itself).
I still get very lost using git (p4 user at work, so svn feels closer) but with enough help from github I can see it done.
Visiting SourceForge feels like going to RapidShare, with all sorts of ads vying for your attention. Each project has numerous sections which may or may not have been filled out by the owner. Heaven forbid that they used the mailing list feature.
Or the mailing list archive software they use, which must be the worst of a bunch of very bad ones. It seems incredible that there is no halfway decent way to view mailing list archives (mailman's html pages don't count).
Sourceforge looks like one of those shady download sites that's either going to load up your computer with spyware, or one that will have the audacity to charge for "download access" for open-source software.
The design has gone from merely bad to worryingly ugly. The info screen shown in the example is the pinnacle of bad design, where it's all spaced out, no consideration for the content given at all, in an offensively generic style that fits in too well with every content spam site I've ever seen.
The sooner they just shut the site down, the better in my opinion. I actively despise it because of how every change they make seems to make it even less useful, more ugly, or more obnoxious to use.
This is illustrative of a fundamental misunderstanding among a lot of programmers about what 'front-end' means. 'Front-end' doesn't mean the colour scheme of the website. It means the features which are exposed to users, the mechanism in which those features are exposed and, broadly speaking, the way the entire thing is USED.
Programmers have a tendency to exaggerate the importance of what they do so that the 'back end' is bigger and more important than it actually is.
My mind got snagged on that, too, and it wouldn't let go. The rest of his arguments are not wrong, but I think they fit under that umbrella. That is, it's because GitHub's front-end is nicer, and it's front-end is nicer because SourceForge is oriented around projects and GitHub is oriented around code. The change in focus enables a better presentation.
It's not that Github's CSS is better, or their graphics are better, but that their design is better, and design encompasses everything, top to bottom. Most things on Github feel effortless, and even the tricky things are far from frustrating. This is evidence that they care, and that care shows in that the graphics and CSS are very well done.
Good design doesn't start with appearance, it ends with it.
In Startups Open Sourced, Tom Preston-Warner is interviewed and says to design every detail of every page of a project before touching any code. While graphic design and technical design are very intertwined, I think in Github's case the graphic design came first, or was at least equally weighted. I don't know how SourceForge came to be, but I wouldn't be surprised to find out the backend was designed before the front end design.
IIRC, the general wisdom during SourceForge's heyday was to design the backend before the frontend. I recall reading a zen programmer story about someone writing a finance package, who was mocked by the "wise" programmer for designing and writing the UI first, before having any finance-related code.
This is true to a fault: for a while many people asked to be able to change the code font, or at least for it to respect browser defaults. They resisted because that went against what the designer thought was best - which I think is a case of form trumping function.
I agree, it's not the only reason (being able to fork anyone's code, fix the bug, re-release and ask them to pull is a godsend), but I always dreaded visiting SourceForge.
I don't have a repo on GitHub and while it may certainly be better than SF (and probably is, judging by the comments here), I have to take issue with the overall quality of this article.
First of all, when I started reading the article, I genuinely expected that it would be a good analysis of why GitHub surpassed Sourceforge, but instead it read like a GitHub fanboy's rant about how much cooler GitHub is. Some of the things said about SF are simply not true, for example, one of his main points - that if you host your project on SF, your project page is your website and that's it, the only other way to have a website is to host it elsewhere. That's simply not true. SF does provide web hosting, and your domain name is not some convoluted URL, it's "yourprojectname.sourceforge.net".
The author of the article states that GitHub is a "code host". But what does that mean, is SF also not a "code host"? Does it not hold your code in a repo? Except that besides doing that, it also offers a plethora of other services. They might not be the best there are, but hey, they're here, and if you don't want to use them, don't. Want to have a forum hosted by SF? Ok, you can do that. Want to have it somewhere else? No problem, host it elsewhere. Nobody's forcing you.
It seems that the author is somehow trying to turn the fact that GitHub doesn't have these features into an advantage for GitHub.
The thing is, this could have really been a good article. There are a number of reasons why devs move away from SourceForge. Unfortunately, the article makes no mention of them. SF's frequent downtime is one of those reasons. The general slowness and unresponsiveness of the site is another. There are good reasons why people are leaving SourceForge. Just not those that the author of this article mentions.
I can say personally that the only reason I use GitHub and would never consider SourceForge is because of the D in DVCS. SourceForge always wanted to be your world: You have to give your repo over to them and let them manage it on their servers. By doing that you are now locked in to their world.
With git I don't care if GitHub goes down for a month or accidentally loses all my code or kicks me out and starts to charge for hosting. It's because they are hosting a copy of my repo and are not the sole keeper. I always have my repo with my precious source code history and it's impossible for them to take it away.
I suspect a lot of hackers are like myself and don't like giving up control where they don't have to.
That and GitHub just doesn't feel as hostile as SourceForge.
SF.net lost because the site is incredibly slow, it's usability is somewhere between "whatever" and "bend over", they keep moving things around for no apparent benefit and for quite a while the site assumed visitors weren't potential contributors.
I started hosting code there using CVS in 2000 and it has certainly improved since then, but I recently pushed a branch to GitHub and there's just no comparison.
It's absolutely astonishing to me that nobody ever mentions how Github handles viewing code. I always thought it's painfully obvious why Github won. They make viewing code easy. Duh. They have that nice little animation of code sliding in which lets me think that I'm not waiting forever, and I can actually navigate and explore other people's code.
I may overestime myself a little here, but I'm pretty sure that's the main/only reason Github succeeded. Not some new pricing scheme.
The first battle SourceForge lost was against Google Code hosting. Google offered a nicer interface and had some features SourceForge hasn't, the most important one, subversion.
SourceForge, like other sites managed by VA Linux/SF/Geeknet, has a terrible record of user friendliness. How many Slashcode-based sites are still running?
The key is that GitHub understands open source. People who write open source aren't magical. We still need food and that means a j-o-b. You can have your public open source code and your private proprietary code right next to each other, in the same place. How brilliant is that?
Sourceforge was definitely created in an era when open source was much more project oriented (think, Samba, gnome, python, etc.) and back then it didn't make as much sense to have open source + closed source code side by side. But things have fundamentally shifted with regards to how open source software is created and sf.net definitely hasn't made the shift as smoothly as it should have.
One key point that I think this article missed is the activation energy required to create a new project. On SourceForge, at least when I last used it, it was a very involved, explicit process, where you created a new project and went through several screens of populating license, status, etc., and then you finally had a place where you could stick code.
Whereas github lets you get a repo up and running with just about a single click and a 'git push', and then add on features and information as you grow. So it became the place to stick all of your one-off, throwaway, or experimental code, which got developers in the habit of using it, and it also had the room to grow if once of those things grew into a "real" project.
"Using a SourceForge page as your project’s homepage is fine in the early days. But once you get big enough, it’s just not enough. The URL is long and doesn’t seem permanent; the landing page is modular and boring, and it doesn’t really convey that much information about your project. It looks like every other SourceForge project page."
It seems to me the author doesn't know sf.net too well. sf.net does still quite well for hosting web pages. I don't know pidgin but I wouldn't be too surprised if the homepage is hosted at sf.net and if pidgin.im simply is an alternative address for pidgin.sf.net. They (sf.net) are notorious for their downtimes though.
When I created a SF project some years ago, it required approval from some mysterious and unknown administrator. That process took a week, and during that time I didn't have access to the resources I needed (version control, mailing list, issue tracker, etc.) to get my project off the ground.
Things may have changed since, but I wouldn't know because I never came back.
Yeah, we got rid of that process at least 3 years ago when I was still there. There's some after the fact attempt to not allow spam projects, but you can get started right away now (thankfully, that was a super slow process).
And mailing lists. The day that GitHub allows me to create and manage mailing lists for my projects is the day I can finally tell sourceforge to burn in hell.
The real reason why sf.net lost was much more fundamental than that. Really it was so fundamental that it was a business problem rather than a technology problem. As a company, management just wasn't that interested in competing, and therefore we didn't have the institutional ability to focus on competing with some of the things github did.
I am proud to say that it looks like sf.net finally has a fork button, though, and it also looks (from the outside) like there's some focus on delivering developer oriented features now on sf.net, so that's a positive thing.
The engineering and ops team that's over there is awesome and has great open source pedigrees, and has always been super interested in working on things that would make open source development better and easier, but really has been hampered from doing that for years by more basic business issues. I think things might finally be turning around for them, though.