Github turns five
github.com
github.com
As an afterword, I guess the big question is: What comes after this? What will make Github irrelevant?
A stable github?
Edit - this was somewhat flippant, and they do a great job, but when it breaks it can stop me from doing what I need to do next.
I can't tell you how many times in my svn past where I couldn't get any work done simply as a result of the repo sever going down or having some other issue affecting its reachability.
At least with git I may not be able to pull commits from origin, but I can still commit locally which is typically enough to keep me productive during outage periods.
However, when it's down, I can't push my changes for others to review, or review pull requests. I can't update and pull in the latest changes, or checkout branches to help someone with a bug. If it's an integral part of your workflow, it can be quite a pain when it's down.
"I can't tell you how many times in my svn past where I couldn't get any work done simply as a result of the repo sever going down or having some other issue affecting its reachability."
I had the opposite experience, although an SVN outage would have been worse, I'm used to them being far rarer.
You can do all of these things if your colleague has that branch checked out - it does require remembering some pretty poorly-named CLI flags though!
It is another benefit of git, and one of the reasons I first moved to it (often did work on a robotic system, pulling an pushing new branches was a really nice way of moving code back and forth without committing to a central repo).
Git is great, and github is brilliant. I just wish it was more stable, because I would say that is a real issue at the moment.
If it weren't for Github I probably would never have open sourced the amount of work that I have done since its inception nor contributed to the amount of projects I've committed too.
I love GitHub as much as the next guy, but 99% of Internet users neither know what git is, nor have any need of it. There are a little more than a million users. (EDIT: well no, there are now 3 million.[2])
By contrast, Google is used by over a billion people every month.[1]
[1]: http://www.statista.com/topics/1001/google/chart/899/unique-...
I keep hearing this on places like HN, yet when I've been applying to software jobs in the real world lately, there's been barely a mention of it.
Your theory doesn't hold when comparing github with infrastructure everybody uses but few people know about, just because its used by many people that write programs that are used by many other users doesn't mean it's an infrastructure like an Internet backbone.
Right, that's why I wrote "has been delayed a bit", not "has been delayed indefinitely." If you run a distributed OSS project, where your main point of contact with your collaborators is through Github--and your workflow relies on using Github's collaboration features (its wiki and issue tracking, its pull requests, etc.) then Github going down can greatly impede (though not halt) that workflow. (In fact, I might say that if your workflow doesn't rely on the collaboration features, you're not really "using" Github--you're just using git, and syncing with Github, like any project which has a Subversion repo with a Github mirror.)
A more major problem with Github going down, though, would be needing to pull an update from a third-party library to fix a bug, when that library's canonical repo is stored on Github. (A problem with any centralzied repo host, really.) If you have any git:// URL dependencies in your Gemfile, or you use Bower at all, you might have a problem deploying your updates...
While it's true that everything can be done in the browser, "saving = committing" there so I prefer to use the terminal and emacs.
In the best case, you can simply reproduce it. Then say so in a comment to the issue. However more probable, you have to ask the reporter for more details or try different versions and environments.
Still, it is an incredible achievement and I hope that github will be around for a very long time to come.
For a laugh:
I'd say GitHub mainly succeeded because it put code first and overall focused on a great experience for developers to contribute and collaborate. SourceForge, in contrast, was heavily influenced by consumers wanting to download the latest version of FileZilla or some Linux games.
And Google Code, for the brief time it was the main event, took things too far the other direction from SF. It was just too terse and the design too raw, as was customary for Google back then. It actually had the basis for a lot of the critical functionality, but lacked the kind of design flair GitHub has shown. I don't think it was ever seen as a potential profit center, so always seemed starved of the resources to compete with GitHub.
Indeed. Except that it's your words, not mine.
I wrote: "Github mainly succeeded because of the various shortcomings in Gits command line interface."
The message, which apparently needs to be spelled out is that using a repo through a command line is a hard thing to do for many developers nowadays who think the command line is something for people with long beards. By putting a friendly face - and a web based face no less - on a really nice open source distributed repository tool github did exactly that which you need to do to gain mass adoption:
Make something people need easy to use and do it in a way they can afford. Then iterate like crazy to dig out a defensible moat around the basic core.
Github blew the doors of the competition including some corporate heavyweights by capitalizing on Git and the trend of collaboration in software development. If they had had to develop git from scratch, if git would have come with a web based front end or if an established competitor (say sourceforge) would have adopted git earlier or (when git was still just for open source nerds and SVN, mercurial or some other repo system used more for corporate) they would have had a much harder time of it.
History happened the way it did for a reason and git being very powerful but somewhat harder to use gave github an opening that they used to create a spectacular success.
Opportunities arise all the time, how you make use of them is what matters and without git as it was there would be no github today.
But why would I rephrase what the git guys said so eloquently on their first homepage:
"git repository hosting no longer a pain in the ass"
And:
"GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease. "
http://web.archive.org/web/20080514210148/http://github.com/
> "Github mainly succeeded because of the various shortcomings in Gits command line interface."
The success of github has nothing to do with shortcomings in git's CLI. As you say, for some people, the command line is for beards. So for them any CLI is a non-starter; nothing to do with shortcomings with git's CLI. The power available to a command line user of git is one of the reasons github is such a good thing.
http://www.codinghorror.com/blog/2007/04/when-in-doubt-make-...
Switching to github was probably the best organizational decision we made.
From a business standpoint, I've also found that github's severs are fast and reliable, and the turnaround for tech support questions is fast and accurate.
I'm very impressed with github.
PS: Would be awesome to see who has the oldest github account on here. I joined April 20 2008.
Doesn't show join date, but user IDs are auto-incrementing.
I was a rubyist at the time :-)
A monk once asked, does JavaScript have a Buddha-nature or not?
Wycats said, "nil".
The monk said, "Above to all the Haskells, below to all the crawling Javas, all have Buddha-nature. Why is it that JavaScript has not?"
Wycats said, "Because it has the nature of karmic delusions."
(http://blog.bigbinary.com/2008/06/23/why-the-id-of-nil-is-4-...)
https://api.github.com/users/pius
Those were the good old days. Hanging out in #merb, just starting to get my feet wet with contributing to open source. Really great memories.
That's five to ten people, all writing code that interacts with each other's, all without any access to the SVN server. You can imagine the copy-pasta that went on. The amount of "oh fuck, I just rebuilt-all without Dave's changes". The amount of "Bags not merging this shit."
Then we'd get back to work after a weekend and have to merge all our independent branches. That could take a day or two on its own. Sometimes, sitting with five people's laptops in front of you and using the human brain's visual diff was more efficient than trying to do it properly.
---
Now, with git, we push and pull wherever the hell we like as needed. Everyone's laptop is equivalent to the server. When we get back, everyone merges their stuff into staging, all the cross-dependencies get magically resolved, we test it, and merge that into master. It takes about fifteen minutes.
(Actually, I don't work there any more, but the conclusion works better in the present tense.)
And Git handles branching and merging better than Subversion.
If you're not frequently using local branches, your stash, `git add --patch`, git bisect or git rebase then you're really missing out.
Everyone's git workflow is different which makes it even harder to get up to speed since you read about 10 ways to accomplish the same task.
You might not use ALL the features of git but once you master a subset of them you'll find that your workflow is unlike anything you could have done with Subversion.
Sure, you have to learn the (absurdly simple) model that git uses behind the scenes, but after you do that, who really cares about the standard CLI interface? That interface sucks in the same way a dashboard might suck on an all-terrian vehicle. Sure it looks like shit, all the knobs are in the wrong place and don't turn in consistent ways, and that analog clock seems really out of place in a car... but who really cares? It doesn't impede actual use.
Those "internal details of its implementation" are in fact what git actually is. "Learning git" without learning that stuff is not in fact learning git.
It's one thing to learn the internal implementation details when you are a power user who really cares about a particular tool and wants to master it: it's another thing to require everyone to gain low-level familiarity.
The whole point of a computer - indeed, the whole point of computing, if you look at it through a lambda-calculus lens - is to provide abstractions over lower-level details, thereby allowing human brains to spend less time worrying about those details and more time manipulating higher-level abstract concepts.
In failing to offer a high-level interface, git wastes human brainpower which could otherwise be spent solving actual problems.
You don't need to know what an AST or a symbol table or an intermediate representation are to use gcc; you don't need to understand static single-assignment form, linker relocation entries, or ELF segments. You can use the tool without any knowledge of its internal mechanisms. This is not true of Git, and that is why I hope it can be improved or replaced with something that has more respect for human brain power.
Nothing felt intuitive. The interface for vim might in fact be unintuitive and that might make learning it take longer.
But once you learn it, the un-intuitiveness is no longer a barrier.
I don't argue that learning git is difficult no matter what your background is. But that's the nature of a tool that's almost 100% un-opinionated on how you do something.
I don't disagree with your comment but I think that's inevitable for this type of tool.
How is it inevitable to have inconsistant flags for showing contextual help?
How is it in the nature of such a tool to have command names that are inconsistant (for example 'push' to not be the opposite of 'pull')?
I think in the end these things are relatively small oversights by Torvalds at the beginning, that have become rather difficult to fix now, after git has become such a standard tool - but it makes live really hard for every beginner. I mean imagine a GUI application where the help menu is sometimes accessed through F1, sometimes it's shift-F3. Imagine Edit->Copy would do something completely different than what people are used to form other similar programs. Even worse, in a GUI tool it's no big deal to fix those problems in version 2, but a CLI automatically becomes an API for other higher level tools such as GitHub and changing it would break it afterwards - so it's really important to get that interface right from the start.
For me the hurdle was not the API. That's what documentation is for. It makes learning it inefficient to always check the docs but that's about all.
It does less than a local SVN server, there is no server.
Git is peer-to-peer, which is a huge advantage. Because it is decentralized you can access your whole repo and its history while off-line. That and easy branching are the main selling points of Git though over time you discover more and more ways in which Git is subtly superior.
If I could start over again on my main repo I'd do it in Git but I already have all my files dating back a long time in an svn repository so the cost of transiting is huge. (it is a very large repository). But anything new is stored in Git. Maybe one day I'll work up the courage to do a proper transition.
Add to that a dizzying array of competing distros and hardware so slow it usually took hours to do a kernel compile. It was a frustrating time for computing in general and deciding to try using linux was a fairly daring venture certain to result in hours upon hours of frustration.
User groups had install parties so users would have a positive experience with Linux and not give up.
I've tried to revisit GitHub many times, but I just don't get it - it's not as good as Mercurial or TFS, and I have no desire to 'follow' anyone or watch a project. I'm just too damn busy building apps and projects to pay any attention to anything I'm not actively working on.
I'm still waiting for the 'ah ha' moment on why so many people are talking up GitHub, but it hasn't happened yet.
I'm sure mercurial is nice, and given its users passion for it I might recommend it to people starting version control for the first time (I'm in academia, version control is surprisingly rare), BUT... I'd use the term "very sharp edges" and not "rough edges." My impression is that they're meant to be there.
I'm as excited about GitHub as ever.
To be completely fair to Twitter, it's been less than a year since Github raised their first round of funding ($100MM). Twitter has raised $1.6 billion over the last seven years.
It's a lot easier not to sell out when your investors aren't pressuring you to pull a profit yet. (Also remember that almost all of Github's funding comes from a single investor).
I like Github, but it's a bit premature to say that they've "never sold out".
It's just amazing so easily be able to fix some software, to make some commitments into project you do love!
But, 6 million repositories for 3.5 million users? Really? How many bots do you have? I'm not sure, that general user has 1.7 repository. I thought the number is higher, at least 3 or something. How many repositories do you have with forks?
BTW, I live in SF and I REALLY want one of those octo-nyan-cat stickers for my laptop. Just sayin...
I've been on the verge wanting to learn Git and GitHub for a long time, but that was what pushed me over the edge.
What other power-tools are on the horizon? What's next?