The recent Inc. article [1] about GitHub isn't really deep but the end has some insights:

a shift is taking place: "Now we are finding that it's not just about the code; it's about, 'Hey, I want to work on this with you.' That's really eye-opening to us and gets everyone here superexcited. Working with someone else is just an awesome part of being alive. Creating art, creating tools, creating documents, doing homework, anything--it's not limited to programming. I don't see why musicians wouldn't want to work this way, for example."

Take that, and now consider how much a forward-thinking city could do with its data as GitHub adds features like this. I don't think it's about being just an IDE/app hosting service ... it's (eventually) about collaboration/control/revisioning beyond purely software projects.

[1] http://www.inc.com/magazine/201303/will-bourne/2-reasons-to-...

This reminds me of trying to determine the scope of your company.

I remember reading somewhere (probably here) that part of the reason the railroads failed to adapt to cars was because they thought of themselves as railroad companies instead of transportation companies. Maybe github is thinking of themselves as a collaborative work company rather than a collaborative coding company and trying to adapt to that.

I know you're just trying to make a metaphorical comparison with railroads, but the story isn't that simple.

In the U.S., intercity railroads found they could make more money by focusing on freight and leaving passengers to poor Amtrak. If Warren Buffet's acquisition of BNSF is any indication, the private railroads are quite profitable.

The decline of intracity passenger rail in the U.S. has many causes (massive public investment in the Interstate highway system for one). Still, it's worth remembering that auto companies played an active role in acquiring and disassembling streetcar lines: http://en.wikipedia.org/wiki/General_Motors_streetcar_conspi...

And your comment reminded of something similar with Coke. At some point they decided that they weren't competing with other soda manufacturers but for "share of stomach" and started going in that direction by going on an acquisition spree.

Github doesn't have any central direction at all (people are more or less allowed to work on whatever they like), and this is a side-effect: the boring stuff doesn't get worked on, and the fun stuff (like, say, rendering 3d models, or a CLI in the header) gets lots of attention.

I think Github is probably vulnerable to a team that stays focused on the bread-and-butter tools that are actually important to developers.

Can this be a vision that is totally disruptive, not now but but 5 (or 10) years in the future?

It looks like GitHub is looking at allowing collaborations between knowledge domains. Within their blog post, it said "People are already using GitHub to store everything from Chicago zipcodes to community radio stations to historic hurricane paths, and we can't wait to see what the community will begin to collaborate on next."

So I am guessing that GitHub is putting a few small services that folks could use with the collaborations. Mapping services is one of them, another could be public transport information services. I think it all depends on what kind of data are being held in GitHub.

Now, if this collaboration idea is spun off to someone like to DropBox where there are truck loads of data in there, we could see some interesting things.

Reminds me of a TED talk[1] were he ends up discussion the use of git or similar tools in the government.

[1] http://www.ted.com/talks/clay_shirky_how_the_internet_will_o...

I imagine their long term vision would be to allow better collaboration for all types of data-based projects (whether code, or geo data, or books).

In the short term, any small project like this that makes GitHub a little cooler is fair game.

I second the call for supporting books. There are already quite a few books being published on GitHub and it seems like an almost natural way to collaboratively write a book that could forever kept up to date. Not sure if anything has been done specifically to support writing a book on GitHub.

I'm a grad student who writes lots of papers in LaTeX with collaborators. We use git most of the time, but git works most painlessly when you tweak it to ignore whitespace and to use word diffs. For example, let's say that my collaborator says "oh, I pushed a new diff" and now I'm curious what he added. Running:

    git pull && git log -p -w --color-words

lets me see exactly which words he added/removed/changed ignoring the fact that he changed all my tabs to spaces in that commit.

Also, if I have a conflict, it's also nicer to use a specialized tool to merge than relying on git's linewise merges.

I imagine github could incorporate some of these tools too.

> I imagine github could incorporate some of these tools too.

GitHub allows you to ignore whitespace in diffs by appending _?w=1_ to the URL [1]. They should make this more obvious with a button in the diff interface.

[1] https://github.com/blog/967-github-secrets

Thanks for the tip. I'm working on a short non-technical book so I'm hoping to do it in Markdown following the format of The Little MongoDb Book. That book is hosted on GitHub with the Markdown text output to PDF, mobi and ePub. Seems like the simplest way to get to a pretty nice looking book in the major formats.

https://github.com/karlseguin/the-little-mongodb-book

I wouldn't overthink it, it may have just been for fun, like something that came out of a hackathon or that an intern wanted to do.

Or because of profit ala "powered by mapbox"

Github is becoming, in addition to a place to share code/data, the commandline program between "cat data |" and someone else's eyes.

cat gps_data.txt | github --pretty-maps > the world

I think that's what their move is. Having raised $100 million, they are in a spot where they can aim big.

I think its really expanding its collaborative focus as it moves from purely coding to "Projects with code". Code itself is (or should be) inherently readable. A great deal of data that code deals with, like GIS data, isn't.