

GitHub is making me lazy but I like it - powdahound
http://blog.hipchat.com/2010/10/15/github-is-making-me-lazy-but-i-like-it/

======
jaaron
So, I'm not a huge GitHub fan for open source projects. Why? Because while
it's a great site and tool (don't get me wrong, I can understand the
attraction), GitHub can be a pain in the ass for end users. How so? I don't
know how many times I've found some code I wanted to use only to find a dozen
or more forks, none of which have been merged back together and a handful of
which have patches I'm interested in. It's way, way too easy in GitHub for the
community to get _lost_ in the forks. There's no clear mechanism for
communication (mailing list, forums, etc.) and not enough pressure to merge
code back into a common repository. Sure it democratizes contributions, but it
also makes a mess.

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.

~~~
alecthomas
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.

------
draegtun
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.

------
alexmchale
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?

~~~
pjscott
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.

~~~
koenigdavidmj
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.

~~~
Titanous
Issues are accessible via the API: <http://develop.github.com/p/issues.html>

~~~
pjscott
So _that's_ how the Cappuccino guys made their slick issue tracker GUI:

<http://githubissues.heroku.com/>

------
powdahound
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>

~~~
pyre
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>

------
benbjohnson
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.

~~~
powdahound
Have you seen 'Calendar About Nothing'? It's a fun way to keep your
contribution streak going.

Link: <http://calendaraboutnothing.com>

------
cloudhead
It's called progress, mate.

