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.

(*)
* https://journal.dedasys.com/2009/01/10/developer-project-or-project-developer-s
* https://journal.dedasys.com/2009/01/21/more-github
* https://journal.dedasys.com/2009/01/22/github-part-iii
* https://journal.dedasys.com/2009/04/29/will-the-real-exception_notification-please-stand-up

Leave a comment