GitHub is making me lazy but I like it(blog.hipchat.com)
blog.hipchat.com
GitHub is making me lazy but I like it
http://blog.hipchat.com/2010/10/15/github-is-making-me-lazy-but-i-like-it/
28 comments
You core complaint seems to be that maintainers don't maintain their software. This is sadly true in many cases, but I would argue that GitHub has actually improved the situation.
First, by making it trivial to get patches to the maintainer. Prior to GitHub, if you wrote a patch for a project, you would have to track down the appropriate channel to submit the patch, then jump through any hoops required. Whether it be mail directly to the maintainer, a patch on a bugtracker (probably also requiring signup), mail to a mailing list (again probably requiring signup), patch having to be in a particular format, etc.
The second problem is what to do if the maintainer doesn't respond? Sometimes you might end up forking the project and hosting it in yet another random web page. Sometimes you might just end up dumping the patch onto the net, in the vain hope that someone else would find it if they had the same problem. I have done both, a number of times. With GitHub, the patches are clearly there as forks.
At least with GitHub, the barrier to writing a patch and getting it in the face of the maintainer is almost zero. This is an improvement. If they don't respond, at least it's obvious to users from the proliferation of forks, and if they're lucky they can find the particular fork that fixes their issue.
Solving the human problem of maintenance is a big challenge. If GitHub solves that as well, I'll be amazed.
First, by making it trivial to get patches to the maintainer. Prior to GitHub, if you wrote a patch for a project, you would have to track down the appropriate channel to submit the patch, then jump through any hoops required. Whether it be mail directly to the maintainer, a patch on a bugtracker (probably also requiring signup), mail to a mailing list (again probably requiring signup), patch having to be in a particular format, etc.
The second problem is what to do if the maintainer doesn't respond? Sometimes you might end up forking the project and hosting it in yet another random web page. Sometimes you might just end up dumping the patch onto the net, in the vain hope that someone else would find it if they had the same problem. I have done both, a number of times. With GitHub, the patches are clearly there as forks.
At least with GitHub, the barrier to writing a patch and getting it in the face of the maintainer is almost zero. This is an improvement. If they don't respond, at least it's obvious to users from the proliferation of forks, and if they're lucky they can find the particular fork that fixes their issue.
Solving the human problem of maintenance is a big challenge. If GitHub solves that as well, I'll be amazed.
Its pretty much identical reasons to why CPAN also became such a success. CPAN's infrastructure and tools is what made the telling difference and Github seems to be heading on a similar tract.
I do worry about GitHub on some levels. I'm an avid user and I love it --- but there's the part of me that's really worried about it being the only real option for hosting. Would the community leave GitHub if their policies changed and it was less of an awesome place to work with your code, or would we feel trapped because it's still what everyone uses?
Sometimes I worry that a significant portion of "git enthusiasts" have no idea what distributed VC means.
Can you explain and elaborate on what they don't get what distributed VC means?
That comment is in response to the parent comment's worry of "being trapped". By definition, Distributed Version Control solves the "being trapped problem" by being distributed.
Well sure, git's standardized, you can always take your repo and go home, I think the parent was more concerned about history relating to bugs, comments, documentation, discussion, etc.
You're definitely not alone in feeling that way. I'm sure someone will try to create some sort of 'Diaspora for GitHub' project at some point.
How easy is it to get information out of GitHub? Not just the repositories -- cloning a git repo is easy -- but the issues, wiki pages, and so on. If that's made as easy as possible, then escaping from GitHub-gone-wild shouldn't be too hard.
That in itself should provide an incentive for GitHub to avoid alienating its users. It's like bringing an umbrella so it won't rain, in a world where such things actually worked.
That in itself should provide an incentive for GitHub to avoid alienating its users. It's like bringing an umbrella so it won't rain, in a world where such things actually worked.
The wiki pages are just another Git repo; you can just clone it and get a full copy. Pages simply turn into files containing Markdown markup (teehee).
Not sure about the issues or other things, though.
Not sure about the issues or other things, though.
Issues are accessible via the API: http://develop.github.com/p/issues.html
So that's how the Cappuccino guys made their slick issue tracker GUI:
http://githubissues.heroku.com/
http://githubissues.heroku.com/
A git-based wiki? My respect for the GitHub guys continues to grow.
The code behind the Git-based wiki is also open source so you can view and edit your wiki locally via a nice web interface, and build your own tools using the API: http://github.com/github/gollum
Well, I'm not much concerned about the technical difficulties, as they're few. I'm also not envisioning any time in the future when I quit using GitHub. It's a fantastic piece of software written by people I respect. However, I've learned to be skeptical and cautious when there's one thing that everyone is using (Google, Facebook). I LOVE YOU GITHUB DON'T PUNISH ME!!! :-)
Did I say overlords? I meant protectors.
We base our entire business around making GitHub an awesome place to work with code. Our users, our revenue, our reputation is all centered around this. There's really no future in which we would move away from that.
In terms of exporting your data: we have a fully featured api (http://develop.github.com) in addition to features like our Wikis which preserve all history and content in a git repository you can clone down. We'll always try and make this better, but you should be able to export any data you wish right now.
In terms of exporting your data: we have a fully featured api (http://develop.github.com) in addition to features like our Wikis which preserve all history and content in a git repository you can clone down. We'll always try and make this better, but you should be able to export any data you wish right now.
Absolutely! I really didn't mean the post to be anything remotely disparaging of GitHub. More of a skepticism of any central place with as much steam as GH has. The original article on this post just emphasizes this -- the guy is hesitant to contribute to projects that aren't on GitHub. When a majority of people feel that way, we're somewhat at the mercy of our benevolent dictators.
Note: I'm a paying and satisfied customer of GitHub!
Note: I'm a paying and satisfied customer of GitHub!
I hate sourceforge with a passion because the experience is so bad. In many ways, GitHub's success is sourceforge's failure. If GitHub starts to suck (doesnt look like it will any time soon) then we'll all shift to the NBT in networked source control.
If only GitHub could solve OSS politics too. :) This 6 year old ticket asking for better logging support in Twisted is just scary: http://twistedmatrix.com/trac/ticket/638
There's a ~3 year old bug in WebKit[1]. It just doesn't happen because rewriting the rich editing handling code doesn't sound fun or sexy.
https://bugs.webkit.org/show_bug.cgi?id=15256
https://bugs.webkit.org/show_bug.cgi?id=15256
As I mentioned in my comment, I think it actually makes the politics worse. There's not a lot of pressure to merge code back into a single master and there's no good place for the network of forks to come together and communicate on how to collaborate.
I actually wasn't involved in much open source in the past but I've been contributing something nearly every day for the past couple of months because of GitHub.
Another great contribution from GitHub is the way it's founders help push better standards for coding: TomDoc, Semanic Versioning, etc.
Another great contribution from GitHub is the way it's founders help push better standards for coding: TomDoc, Semanic Versioning, etc.
Have you seen 'Calendar About Nothing'? It's a fun way to keep your contribution streak going.
Link: http://calendaraboutnothing.com
Link: http://calendaraboutnothing.com
It's called progress, mate.
There's a real need and advantage to having a canonical, master repository - something users can trust that's been properly vetted, tested and debugged. There's a lot of value in a single place for discussion with public, searchable archives so that users can learn the project history, why decisions were made and, if necessary, ask new questions. There's nothing worse than having to use Google to search blogs for outdated documentation and discussions split across little more than tweets.
GitHub encourages forking but it doesn't necessarily encourage merging. Successful open source projects which a large, invested user base require a bit more structure, stability and developer support than GitHub encourages. It may be a great place to start a project, but at some point, I can see projects graduating to their own infrastructure and a real, organized community.