2 ms·

I don't know whether "mature" is the right word. Different. Yes. Older. Yes. Github and SF represent two wholly different development paradigms: SF (mostly) r

by pilif 17y ago

I don't know whether "mature" is the right word. Different. Yes. Older. Yes. Github and SF represent two wholly different development paradigms: SF (mostly) represents the central way for doing development where a central repository contains the officially blessed code and additions are done by sending patches to maintainers when then go ahead and igno^H apply them. github is based on forking and moving patches around in a more fluid manner. Due to how the traditional systems (CVS, SVN) work, finding contributors on SF would actually be very hard because the traditional systems don't discern between author and commiter: If I send a patch to awesome-project to a maintainer, they would commit it in their name and it would be impossible to automatically determine my initial ownership. If I fork awesome-project on github, create a patch and make them pull (or cherry-pick or whatever) from my repository, git will track them as commiter and myself as author. This is probably another reason why, on the original article, ruby projects seem to have so many more contributors: Some of the older non-ruby projects on github are mirrors of the projects main SVN repository, thus losing all author information on patches coming from external contributors. One must be careful to really be comparing apples to apples here, but still, in light of these inherent limitations, the article was very interesting.

davidw 17y ago
I meant 'mature' in the sense of having been around for many more years than github. By the way, though, git does not change the human nature of projects: there is still usually one official one. Git 'forks' are just a more efficient means of doing patch management (you point out some of the benefits), rather than (hopefully), different, competing versions of the same codebase. I say 'hopefully' because in most cases it's nicer for everyone involved if the code in question has one more or less authoritative source, rather than forcing the user to figure out which one of the 788 rails forks is the 'real' one. Project forks are occasionally necessary, but they are also costly, which is why they should be rare, and only for situations where it is impossible to collaborate. In some ways it's a pity that git/github use the 'fork' terminology: while it's technically a fork, in most cases it does not represent a genuine attempt to create a competing code and user base.
- pilif 17y ago
  yeah. of course. but if I send a pull-request or even just a patch created by "git format-patch" and that patch gets applied, then I am credited as author and the person who put it into the official repository is credited as commiter. In SVN or CVS, you would do this by some comment in the commit message or the changelog but it's entirely optional and often such contributions are only visible in some mailinglist or bugtracker. This skews any analysis of contributor frequency in the traditional style of managing projects.

by pilif 17y ago

davidw 17y ago

I meant 'mature' in the sense of having been around for many more years than github. By the way, though, git does not change the human nature of projects: there is still usually one official one. Git 'forks' are just a more efficient means of doing patch management (you point out some of the benefits), rather than (hopefully), different, competing versions of the same codebase. I say 'hopefully' because in most cases it's nicer for everyone involved if the code in question has one more or less authoritative source, rather than forcing the user to figure out which one of the 788 rails forks is the 'real' one. Project forks are occasionally necessary, but they are also costly, which is why they should be rare, and only for situations where it is impossible to collaborate. In some ways it's a pity that git/github use the 'fork' terminology: while it's technically a fork, in most cases it does not represent a genuine attempt to create a competing code and user base.

pilif 17y ago
yeah. of course. but if I send a pull-request or even just a patch created by "git format-patch" and that patch gets applied, then I am credited as author and the person who put it into the official repository is credited as commiter. In SVN or CVS, you would do this by some comment in the commit message or the changelog but it's entirely optional and often such contributions are only visible in some mailinglist or bugtracker. This skews any analysis of contributor frequency in the traditional style of managing projects.