In Github's case, most of the projects there are libraries and the users are developers. The people who like Github probably expect the first thing they see when they show up to a project to be the code. And I'd wager that for many developers, checking out the repo is quicker and more convenient than downloading a tarball.
Github's UI admittedly doesn't make for a great experience for someone browsing around looking for software to download. A project that is trying to appeal to regular users should set up a wiki page, or even better, use Github Pages to build a site.
Though, I really hate it when I follow a link to a Rails app on Github that left the default "Welcome to Rails" readme.
When looking out for libraries I need to have answers to the following questions:
1. Is the library stable/complete?
2. Is the API stable?
3. If not, how frequently/how much does it change?
With a decent project page, I can have these questions answered either directly or by looking at the available downloads history (even if they are source-only downloads) and version numbers. With github projects I frequently can't answer any of those questions.
Libraries are products, just like any other piece of software.
I'm not saying that github isn't good for developer collaboration. I'm saying it's no good for developer-user relations. It has the necessary features, but it doesn't encourage its use by the very nature of its interface.
Number of followers/watchers is usually a good indication of how well-liked a project is. And as with any other open-source software, without sniffing in the code a little bit you never know what you're getting, regardless of how good the docs are or how sleek the project hosting pages are.
I like how most bigger projects are doing it nowadays: a separate page/mini-website, often using GitHub pages, that is user-centric and usually has a direct download link, and then GitHub for fellow developers.
Comments
In Github's case, most of the projects there are libraries and the users are developers. The people who like Github probably expect the first thing they see when they show up to a project to be the code. And I'd wager that for many developers, checking out the repo is quicker and more convenient than downloading a tarball.
Github's UI admittedly doesn't make for a great experience for someone browsing around looking for software to download. A project that is trying to appeal to regular users should set up a wiki page, or even better, use Github Pages to build a site.
Though, I really hate it when I follow a link to a Rails app on Github that left the default "Welcome to Rails" readme.
When looking out for libraries I need to have answers to the following questions:
1. Is the library stable/complete? 2. Is the API stable? 3. If not, how frequently/how much does it change?
With a decent project page, I can have these questions answered either directly or by looking at the available downloads history (even if they are source-only downloads) and version numbers. With github projects I frequently can't answer any of those questions.
Libraries are products, just like any other piece of software.
I'm not saying that github isn't good for developer collaboration. I'm saying it's no good for developer-user relations. It has the necessary features, but it doesn't encourage its use by the very nature of its interface.
1. Look at the README. 2&3. Semver.
Number of followers/watchers is usually a good indication of how well-liked a project is. And as with any other open-source software, without sniffing in the code a little bit you never know what you're getting, regardless of how good the docs are or how sleek the project hosting pages are.
I like how most bigger projects are doing it nowadays: a separate page/mini-website, often using GitHub pages, that is user-centric and usually has a direct download link, and then GitHub for fellow developers.