My first open-source contribution was in 1998, when a ragtag bunch of web hackers and I published the first version of one of the first web application toolkits. In 2000, after I’d left the original project, a few other hackers and I “forked” that codebase to make it work on an open-source database, meaning we took the code, copied it to a different repository, and took it down a different path than that envisioned by its maintainers.
That has always been the beauty of open-source: if you don’t like the direction of the software, you can always fork it. The dirty little secret of open-source at the time was that this was much more an abstract threat than a common occurrence. Forking was almost always a bad word, a huge undertaking, and it happened very rarely. One central reason for this was that forking was almost always a one-way street: once you forked, it became very difficult to share improvements between forks.
So, in theory, thanks to open-source licenses, forking was always possible. In practice, it was a huge undertaking, one with deep consequences, and usually a sign of something gone awry.
Then in 2008 came Github. Github made hosting source code super easy. Github made forking other people’s code super easy, too. And thanks to the underlying Git system, Github made merging just as easy as forking. Within a few weeks, more than 6200 projects on Github had been forked at least once.
Forking became the optimistic way to contribute to a project: fork it, modify it for your own use, and suggest the change back to the original author. If the original author accepts your change, great, you can forget about your fork and go back to using the original code. If the author rejects your change, you can keep using your forked version, occasionally merging in upstream changes from the original author.
So forking became a good thing, a sign of interest in your project. People wore “Fork Me” t-shirts. And it was all done for years with little attention paid to the specifics of the licenses underlying it all. It was just assumed that, if you made a Github project public, you allowed open-source style forking.
In many ways, Github made real what open-source licenses mostly theorized. Standing on the shoulders of giants, contributing just a little tweak very easily, taking a different direction when you need to, etc. All the beauty of a vast open repository of code you can pick from and contribute to exists in Github.
And somehow, this amazing sharing ecosystem is based on purely selfish incentives. I need to host my code. I don’t like paying for things unless I need to, so I’ll make it public, because Github makes me pay for private repositories. I sometimes need to change other people’s code, and there’s a button for that. If someone changes my code I’d like to benefit from it, and there’s a button for that, too.
Like the Back-to-the-Future deLorean that runs on garbage, Github produces sharing behavior by consuming selfish acts.
I’d like to see many other Githubs. And I know startups are pitching Github-like projects to VCs daily. But it’s not just about a place to host and remix stuff. The magic of Github is that it generated a sharing ecosystem out of selfish incentives. Not sharing and selfishness side by side. Not questionable sharing of private content for the sake of virality. Sharing as a true side-effect of selfish behavior.
That’s not easy. And if it can be done in fields other than source code… I really like what that could do to benefit human knowledge and progress.
Benlog 