>> Sourceforge looks like a sales page, listing features and downloads.
>> Gitub has the contents of the source right there at the top
This is a non issue (as far as I see it). Everyone that is interested in a project is not necessarily interested in submitting pull requests and contribute to code every time, all the time, right from the start. They might just want to integrate the project into their workflow to begin with. This is just as valid an assumption to make.
While we are comparing projects, let us compare VLC player (a really huge beast) with something more comparable. For argument's sake let's take adobe brackets that is actually hosted on github. The proportion of people wanting to download the binary and use it would be much higher than the percentage of people interested in contributing code back to brackets. So I think that people looking for Adobe Brackets would appreciate a link to the downloads page (similar to Sourceforge) rather than the pull request view... https://github.com/adobe/brackets/downloads
> This is a non issue (as far as I see it). Everyone that is interested in a project is not necessarily interested in submitting pull requests and contribute to code every time, all the time, right from the start. They might just want to integrate the project into their workflow to begin with. This is just as valid an assumption to make.
That's the point. GitHub is for the people who are as interested in the code as they are in the software itself.
If the majority of a project's end users are only interested in grabbing the binary, then the project should have a separate page somewhere else. I'd guess the majority of the projects on GitHub aren't at that level, though.
>> GitHub is for the people who are as interested in the code as they are in the software itself.
I'd argue that it is the same for SF as well. Like I mentioned with the Adobe brackets example, based on the nature of the project, a download might be a first choice to test the waters. SF is largely Java/C++/etc., centric (as opposed to RoR or javascript projects) so the installer is the first place to go, to test the tool in the first place. See another reply that echoes this sentiment... https://news.ycombinator.com/item?id=4908007
>> If the majority of a project's end users are only interested in grabbing the binary, [...snip...] I'd guess the majority of the projects on GitHub aren't at that level, though.
Have you seen this recent thread? https://news.ycombinator.com/item?id=4907830
You'll find binary uploads are a very much a relevant and needed option to many others even within the github 'ecosystem'.
I think you may have hit the nail on the head with the cultural difference between "Java/C++/etc.", where downloading some sort of artifact is a more common use case than reading code, and "RoR or javascript", where it is the opposite. There is no good or bad here, but if you care more about code than artifact, Github is the better option.
I wasn't arguing if one was good or bad over the other either. If we are looking at alternatives, all alternatives should be discussed, and I took it upon myself to bring sourceforge into the discussion.
>> may have hit the nail on the head with the cultural difference between "Java/C++/etc.", where downloading some sort of artifact is a more common use case than reading code, and "RoR or javascript", where it is the opposite.
I think it took a few back and forth replies before I realised that this could be the main point ;-)
On the whole, reading source online for gaining knowledge is possible on all the repositories, but I noticed that there is definitely a bias/inertia favouring github on most discussions(). Hence my overall thread.
() perhaps due to the fact that this is HN, where the audience/many discussions revolve around internet based startups, that in turn focusses on using RoR/javascript heavily.
>> Gitub has the contents of the source right there at the top
This is a non issue (as far as I see it). Everyone that is interested in a project is not necessarily interested in submitting pull requests and contribute to code every time, all the time, right from the start. They might just want to integrate the project into their workflow to begin with. This is just as valid an assumption to make.
While we are comparing projects, let us compare VLC player (a really huge beast) with something more comparable. For argument's sake let's take adobe brackets that is actually hosted on github. The proportion of people wanting to download the binary and use it would be much higher than the percentage of people interested in contributing code back to brackets. So I think that people looking for Adobe Brackets would appreciate a link to the downloads page (similar to Sourceforge) rather than the pull request view... https://github.com/adobe/brackets/downloads