The GitHub Revolution: Why We're All in Open Source Now

GitHub was intended to be an open software collaboration platform, but it’s become a platform for much, much more than code. It’s now being used by artists, builders, home owners, everyone in between, entire companies ... and cities.

"Anyone can now change the data when new bike paths are built, when roads are under construction, and new buildings are erected,” the city of Chicago recently announced. People are managing home-renovation projects on GitHub. One law firm also just announced a couple days ago that it’s posting legal documents for early-stage startup funding on GitHub. Someone even published all of the laws in Germany on GitHub last year. (Perhaps not so surprisingly, he has about 17 open “pull” requests for changes.) And of course, GitHub is still used by programmers and developers flying AR Drones with Node.js or building websites with jQuery.

As people who were once just users become producers, they’re re-shaping the culture of open source. GitHub, I believe, is doing to open source what the internet did to the publishing industry: It’s creating a culture gap between the previous, big-project generation of open source and a newer, more amateurized generation of open source today.

The Revolution Will Not Be Centralized

When most people hear "open" source, they think democratic, distributed, egalitarian: everyone building things together for everyone else to use.

But that hasn’t actually been the case. Most open source software has been created and maintained by a privileged and protected class of people -- professional developers -- who interacted with other developers that were a lot like them (though were just different enough to have a good argument with).

Before GitHub, I spent a lot of my time thinking and talking about how to best manage open source projects because the coordination cost of an open source project was significant. So significant, in fact, that when a project did well and grew a big enough community, it made more sense for the project to grow rather than fracture into smaller projects. But the bigger and more complex a software project got, the harder it became to contribute. So an assortment of members -- or “committers” -- were tasked with managing and producing the project. This often led to rifts between those producing and those consuming a project.

GitHub closed this rift by making open source much more decentralized. It became less about the project and more about the individuals.

The workflow for using GitHub is very personal. A person (I’m github.com/mikeal) has an account, and everything they publish exists one level below them. If someone else wants to fix something, they "fork" it, which puts a copy of it under them.

This workflow is very empowering: It encourages individuals to fix things and own those fixes just as much as they own the projects they start. It also gives all users an identity in the new open source culture; GitHub is actually the number-one identity provider for peer-based production over the internet in more than just code.

I've been contributing to open source projects for over 10 years, but what’s different now is that I'm not a “member” of these projects -- I'm just a “user,” and contributing a little is a part of being a user. Little interactions between me and the project maintainers happen several times a week on all kinds of little projects I use.

And it happens even more often in the other direction: People I've never heard from send me little bits of code on all the little projects I've published.

Decentralization as Democracy

The first versions of GitHub did one thing very well: They made it much easier to publish -- than to not publish -- your code. This was enough for many notable projects, including Ruby on Rails, to move to GitHub almost immediately.

But what happened next was even more interesting: People started publishing just about everything on GitHub.... Pushing code became almost as routine as tweeting. By reducing barriers to entry and making it easier to coordinate and contribute to open source, GitHub broadened the peer production to casual users.

Today a vast landscape of simple and understandable software is accessible to a creative class of people who did not have the depth of technical knowledge necessary to participate in the large open source projects of the past.

This blurring of relationships between producers, contributors, and consumers naturally values smaller and more easily understood projects -- and has led to a long tail of contributions. In the entire month of September 2012, for example, half of all active GitHub users who pushed a “changeset” pushed fewer than five changesets, with 22 percent (about 44,000 people) pushing only a single changeset that month.

This amateurization of open source software has some obvious benefits.

One of the longtime problems with open source software has been fit and finish. Bad documentation, website design, and usability in general have been poor -- especially when compared to many proprietary counterparts.

But now, with low barriers to contribution, less-technical users see these areas as easy places they can improve the very software they rely on. (This means little things like cryptic error messages get more humane and tiny one-line CSS changes make websites render correctly in ancient browsers and mobile phones.)

In the new open source, people want to use technology without having to become an expert in it. Ease of use is valued more than ever.

Engineers love a challenge and the more chances they have to solve it, the more clever their solutions can become. That was okay when the consumers of those solutions were highly technically minded people like them who rejoiced in clever ways to solve old problems.

But amateurs like solutions they can take for granted: Once a problem is solved, they will rarely go back or re-examine it. And because amateurs will only build on top of the most understandable solutions, it forces developers to create simple solutions that make hard problems easy to understand.

Node.js, where I’m actively involved, defines enough simple patterns that people can write small libraries independently and publish at will. Everyone invested in the ecosystem can use that value without any coordination. This is the polar opposite of the big vertical stacks that come with lots of tools and features (such as integrated plugin systems like ember, Dojo, and YUI) that are required for success in proprietary environments (think Cocoa and writing for iOS).

But in open environments, like Node.js on GitHub, we see much smaller API footprints that can easily leverage the rest of the value in the ecosystem without coordination (for example callback APIs in jQuery or node's standard callback pattern). The less coordination between developers and libraries the more we can create value.

- - -

GitHub has empowered a new generation of people to collaborate, create, produce. Many developers will lament the loss of former cultural norms -- like the place of committers or the old fight about which license to use -- but the future is already in the hands of a new generation that has moved on.

This isn’t just a tool: We’re witnessing the birth of a new culture.

Editor: Sonal Chokshi @smc90