Improving github?
I've written several articles (*) lately that are, if not exactly critical of github, certainly question some of the community dynamics that have sprung up around it. I'm not the only one:
http://www.cubiclemuses.com/cm/articles/2009/04/28/a-community-of-rockstars/
However, I think the Github guys have actually done really great work, and done some cool stuff. And I think - and hope - that they're here to stay, so instead of focusing on what's not quite right about it, I thought I'd toss out some ideas on how it could be fixed. Some of them may not be great, but hey, that's what you get for free - go ahead and throw out your own ideas too.
- When you clone a project, it's techncially a "fork", but it's not necessarily a fork in the real open source sense of "ok, I think I'm better able to develop this code, so I'm going my own way", ala xemacs or x.org, or the bsd's splitting apart. It might be nice if github gave people the means to indicate what sort of fork they're creating - if it's just a place to play with and publish some code, or if they think their code should be the one others reference.
- Perhaps it should be optional to copy the wiki and issues tabs on your new fork. If you're not really aiming to supplant the main project, do you really need those? You might need the issue tracker.
- It might be an interesting experiment to let people vote on which one is the main project. Forkers could also indicate which one they want to keep working with as the main branch and maintainer.
- Perhaps github could add some visual encouragement for people to send their patches on to the main branch of a given project.
Anyway, just a few ideas off the top of my head.
(*) * http://journal.dedasys.com/2009/01/10/developer-project-or-project-developer-s * http://journal.dedasys.com/2009/01/21/more-github * http://journal.dedasys.com/2009/01/22/github-part-iii * http://journal.dedasys.com/2009/04/29/will-the-real-exception_notification-please-stand-up
Trackbacks
Use the following link to trackback from your own site:
http://journal.dedasys.com/trackbacks?article_id=2150
-
When github was uncovered, I was a bit concerned with the idea that it seemed to foment the idea of forking software all over the place, instead of branching, with results that are, in my opinion, quite upsetting in the way some software is handle...
about 2 hours later:
"Perhaps it should be optional to copy the wiki and issues tabs on your new fork."
It's already possible to turn these off for your fork, though you have to do it as a separate step (so it's not as discoverable as it could be).
"Forkers could also indicate which one they want to keep working with as the main branch and maintainer."
Presumably the repository you fork from is the one you plan on pushing/pulling to the most (although this may change over time). It's be great to have a view of the "family tree" of forks (not the same as the "Network" of commits).
about 9 hours later:
"Presumably" - if, however, people make it explicit that they just want to try a few things out and push them back, that would help reinforce the integrity of a project.
about 12 hours later:
I'd live to see that "vote for main project" and "mark by intention" as well; hopefully there would be a way to teach that to the search engines (via rel-canonical?) as well.
Example: Google for svn2git. The first hit is jcoglan-sv2git, the original tree. Which was forked quite some time ago to nirvdrum-svn2git which is now the most recent and more or less official one. When I first tried it, I went with the original and cursed about the bugs. Only later I discovered the latter (and fixed it up, so now you've got a temporary mss-svn2git waiting to be pulled as well, unfortunately not markable as temporary).
Maybe GitHub could learn the main fork in such cases as well: If a tree hasn't seen any changes in a few months, then go looking for a more active fork.
Actually, I think I prefer the Gitorious way of managing projects: You've got projects first and then people forking those and not people first who are forking from each other and you have a hard time tracking the best fork.
about 13 hours later:
Heh, I just noticed that it was your blog where I (double-)commented on the same topic recently (at http://journal.dedasys.com/2009/04/29/will-the-real-exception_notification-please-stand-up and also talking about the advantages of Gitorious).
about 18 hours later:
I think the problem is that the Linus and github model relies on having one central integrator who works to merge the branches that are out there into a release. In the Linux world, this is Linus and he barely writes his own code anymore -- most of the commits attributable to him are merges. (Visit http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=committer&s=Linus+Torvalds and you'll see what I mean.)
In other projects, there isn't one person who manages integration, there's a primary developer who prefers to code and he can't keep up with all of the patches out there. It would help him to manage the ecosystem if could have several other developers helping him merge things into the same repository. So if github were to implement the concept of a project, where several developers had access to the primary repositories, this would greatly help developers to keep control of their projects.
Also, many people fork these projects to create their own half-baked patches (i.e. they stop developing it furhter when it "works for me"). Project leads need to be able to cultivate the developers to fully-bake their half-baked features, and I don't know of a software solution for that. (Though github's tools for exploring the network of forks certainly can help developers to do this.)
1 day later:
Good comments. Ken, the point about 'half baked' code is important. Github puts all forks on an even footing, more or less, but with a "real project", there are gatekeepers who attempt to include good code, and suggest ways to improve code that isn't quite there yet, in order to make it suitable for inclusion.