A Brief History of Open Source

In the early days of computing, collaboration was open and knowledge was freely shared among academic groups in various universities. These groups worked together in an effort to build networks and share computer bug fixes to further the progress of computing systems.

However, as the industry started to expand rapidly in the 1980s and software began to be distributed on physical disks that made copying software easier than ever before, the open source community came under attack by companies that relied on closed source licensing models. 1981 was a particularly important year, marking the end of the Diamond v. Diehr U.S. Supreme Court case, where the P.T.O. was ordered to grant the first patent on computer software.

Although September 17, 1991 marked the first release of Linux, by many accounts the slow creep of closed software models continued throughout the 90s. However, on October 31, 1998 it became clear to the public that even Microsoft wasn’t sure about how their approach would stack up against open source. The “Halloween memo” as it was called showed that, despite their claims to the contrary, Microsoft saw open source as having “benefits that are not replicable with our current licensing model” and “present[ing] a long-term developer mindshare threat.”

By 2005 the advent of distributed version control software like Git, where developers could share entire libraries and develop collaboratively, had caused open source software to expand exponentially in use and popularity. Code hosting and sharing services, such as GitHub, took this one step further, and arguably became the catalyst that caused proponents of closed source software to fully embrace open source models.

Today, open source has become an industry standard. If you’re a software company not contributing to and building off of open source software, you’re behind the curve. In fact, a majority of companies (upwards of 78% by some accounts) are actively encouraging developers to engage in and contribute to open source projects. And these aren’t just newer software companies, companies like IBM and Microsoft are frequently engaging the community to talk about their commitment to open source. Really, who would have guessed in 1998 that, of the over 330,000 organizations with employees contributing to open source projects on GitHub, Microsoft would be the largest.

Why Open Source?

So why do people care so much about open source software? Outside of arguments around politics and community, there are some clear pragmatic reasons that open source is useful. Here are just four:

Linus’s Law: Given enough eyeballs, all bugs are shallow. Open source projects can leverage the power of the crowd to find and fix bugs before they become critical vulnerabilities. Proof of Code: Closed source software relies on trust in a centralized party. If that party decides to act maliciously, whether that means building its software to cheat at chess or drain your bank account, you may not find out before it’s too late. Although ownership of GitHub repositories is still centralized, transparency brings with it accountability. Enforcing code quality and development best practices: While large centralized organizations can still stumble into bureaucracy and survive, open source projects cannot. That’s why the vast majority of open source projects by necessity follow an asynchronous, and distributed workflow model and use tools like Git to organize and review code and accelerate development time. These workflows also provide a natural way to review the progress made on a given project and ensure that it’s meeting its stated milestones. Standing on the shoulders of giants: Need to add some charts to your next website? There’s an open source JavaScript library for that. As the software world continues to embrace micro-service architectures, the ability to grab the pieces you need and quickly hack together a minimum viable product is invaluable.

Funding for Open Source

Despite the resurgence of open source, there is a significant lack of funding and participation for even the largest open source organizations like Mozilla and Apache. And while Kickstarter, Patreon, and other crowdfunding platforms have made it easy for smaller centralized teams to sell anything from gadgets to documentaries without that kind of overhead, getting support for open source software projects can be a bit more challenging.

Even putting aside the problem of raising funds, there’s still the problem of how those funds are distributed. In the current model when open source projects raise significant amounts of funding, that funding tends to go towards a small group of paid employees rather than to the total pool of project contributors. As mentioned above, many open source projects don’t have the funding to pay for the work, but for larger groups with funding, the problem may instead be how to distribute rewards to contributors in a meritocratic fashion. GitHub repositories aren’t companies, contributors aren’t employees, and getting the bank account or PayPal information of in some cases 10,000+ contributors is simply not feasible.

So what we need is a way to pay pseudo-anonymous GitHub users for work they’ve actually completed that:

a) is accessible to projects regardless of how much funding they have; and

b) doesn’t require the creation of a messy bureaucracy likely to include a Google spreadsheet of sensitive financial information with Equifax levels of security.

To us, this sounds like a job for smart contracts.

Introducing GitToken

GitToken is an open source project aimed at improving the way open source projects are managed, and how contributors are rewarded. GitToken leverages GitHub and the Ethereum blockchain to allow any GitHub organization to:

Incentivize open source collaboration and reward contributions by issuing ERC20 tokens that represent the work that is submitted to the project. Monitor its projects and view tangible performance metrics for repositories. Offer instant liquidity to contributors through auction and token exchange markets.

Tokenized distributions give any project the opportunity to raise funding with no overhead and for contributors to be collectively rewarded in direct proportion to the work they’ve done. A useful corollary to the fact that rewards are proportional to the funds raised is that it incentivizes developers to work on projects that the community values (as far as donations can be a proxy for total community support) and thus more efficiently allocates open source development effort.

How It Works

In the GitToken model, contributions are mapped to GitHub web hook events (e.g. pushing committed code, merging branches, forking repositories, and reviewing code). GitToken provides a Docker container to deploy a server for configuring and listening to GitHub web hook events, and also provides a registry service and hosting for organizations that do not want to host and configure a private service.

By allowing each organization to separately configure their GitToken instance we allow them to incentivize Git workflows that best fit the style of the core team. Our hope is that as GitToken evolves we can use the data collected to build a model that ensures you’re incentivized for using one of a select set of best practices — practices that promote teamwork, in addition to modular and auditable code.

Contributors receive tokens through interacting with any organization that has configured a GitToken server and has set up a GitHub web hook. When a contributor creates a new event, their GitHub login username is provided in the web hook request and each username is mapped to an Ethereum address in the GitToken contract.

After verifying their GitHub identity by authenticating into GitHub using their OAuth token credentials, contributors authenticate themselves with the token contract either through the GitToken terminal or the web application. If a contributor has not yet verified their identity with the contract, their contribution rewards will be held by the contract until their identity has been verified.

Because all tokens accrued by repository contributors using GitToken are ERC20 tokens, they can be exchanged over-the-counter (OTC) with private parties using Ethereum contracts, and hence contributors can choose to recognize the value of their tokens in ETH as they so choose.

Getting Started with GitToken

While a lot of work has been put into GitToken so far, we still have a long way to go. As a starting point, we’re aiming for an alpha release in early January.

While we originally wanted to allow organizations to get started by installing a GitToken CLI ( npm i -g git-token@alpha or yarn global add git-token@alpha ) we’ve decided to start with a simple web interface, which will be available at alpha.gittoken.io.

To register you’ll need a GitHub organization and personal access token, which you can get by going to Settings > Developer Settings > Personal Access Tokens.

**Please note however that the services might be offline while we are developing! Your patience is awesome and respected**

Example GitToken CLI Registration Workflow via git token register

Getting Involved

GitToken is itself entirely open source and intends to use its own mechanism for funding development once we’ve tested sufficiently on our private network and Ropsten.

So, if you’d like to get involved (and rewarded), feel free to submit an issue or a pull request on our GitHub repositories, connect with us via Gitter, or just reach out to us directly.

Over the coming weeks we’ll be writing our documentation preparing for our alpha launch so that GitHub can start testing it out and earning sweet reward points in their own organizations.