Comment by Groxx | Hacker News Reader

Comment by Groxx | Hacker News Reader

>- GitHub's success is not just about openness, but also a prestige economy that rewards valuable content producers with credit and attention

I don't think I can agree with that. GitHub's success, IMO, seems to be based almost entirely on its openness. It has turned contributing to open source software into a drop-dead easy task, which would never be found nor contributed to if they weren't open. And they keep making it easier. I've fixed a number of things with machines which don't have Git installed, simply because they have their on-site editor.

Imagine if GitHub were behind a paywall. Do you think it would still be the success it is today? And, I may be weird, but I very rarely look at the names associated with commit histories. The code should speak for itself.

The rest of it sounds about right, scientific publishing as a whole is massively backwards compared to GitHub, if you're looking at it from an "Open" perspective. But I think that a lot of that is that the researchers tend to be insular compared to the implementers (businesses guarding their IP aside - they're not really GitHub's target audience anyway). GitHub isn't used exclusively for comp-sci researchers to post their findings with code, it's more for people doing things with ideas others have contributed to.

There are experiments on GitHub, absolutely. I have a few myself. But the main thing that GitHub has done is to make final products easy to find, modify, and contribute to. I have significant doubts that it would fit a research workflow smoothly, without becoming something else entirely.

John Resig started a project to generate resumes from the contributions at github. Regularly I see posts at HN/reddit/etc sites of users saying: "I build this and that, check it out!".

Personally, a motivation (of a lot more motivations) is indeed prestige. Now I can show off my nice work.

Sure, openness started it all: Linus shared his VCS, which in turn sparked Github, which in turn initiated thousands of developers to share their code. But openness really isn't the sole driver for people to share their code any more; more incentives, of which prestige is an important one, drive the popularity of github.

>"I build this and that, check it out!"

But people do that with other open source sites as well. Does GitHub provide this feature better than SourceForge or others? You still need to go to the user's page, they don't advertise it anywhere else. Do people go to GitHub to see information about person X, or project Y? And for the posts on social sites, are they more often about the creator or what they created?

> And for the posts on social sites, are they more often about the creator or what they created?

You hit the nail right on the head. Github is about sharing code. The code is the creation. Github's unique selling point is the webinterface to show the code: It's the best designed interface in the industry to show code in a browser.

> Does GitHub provide this feature better than SourceForge or others?

Various software is available to show code in the browser, but none works as well and is polished as well as Github. The creation (code) therefore can be best shared on Github. As such, others willing to check out the creation are, from the moment they arive at github, mostly busy this exactly that: check out the creation (code). Every time I visit repo's visualizing the code in html on other places then github, I get agitated by the annoying interface. Example: some interfaces require you to click on a file, after which the postback returns a site containing a list of revisions, and new buttons to 'view' a revision. This causes me to wait for a postback, and click, twice per file I want to view. Github instead instantly shows the last revision.

All these small tweaks account for much better usability on Github compared to other sites.

I guess for scientists, there must be the same approach as Github approaches programmers. For programmers, it's about code, and for scientists, it's about data and the conclusions derived from it. Instead of showing code, show a paper with the possibility to drill down on data. The data being shared can then be treated the same as code being in a source repo, so the usual git stuff (branching, merging, pulling, pushing) can be applied on the paper+data.

Reply on news.ycombinator.com