Open source (almost) total

This time I would like to offer for reading a [free] translation of an article by Tom Preston-Werner, one of the co-founders of GitHub, in which he discusses what benefits the company can derive from opening its projects, which projects should not be opened and what is the only correct one License. I also want to note that the opinion of the translator does not always coincide with the opinion of the author of the original. Link to the original, as always, under the text of the translation.

When Chris and I started working on GitHub at the end of 2007, we divided the work into two parts. Chris worked on a Rail application, and I worked on Grit, the first Git adapter for Ruby in history. After six months of development, Grit became complete enough to service GitHub during our public launch of the site and we faced an interesting question:

Should we open the source of Grit or leave it proprietary?


If left proprietary, this would create an obstacle for competing Git hosting, giving us an advantage. Open source means that thousands of people around the world could use it to develop interesting tools, creating an even more vibrant Git ecosystem.

After a little argument, we decided to open the Grit source. I don’t remember all the details of the discussion, but this decision, made almost four years ago, led to the fact that I consider one of our main values: to open the sources of (almost) everything.

Why open source (almost) everything cool?

If you do everything right, then open source is a great advertisement for you and your company. At GitHub, we like to publicly discuss libraries and systems that we have developed and which are still closed, but doomed to become open. This approach has several advantages. This allows you to determine what exactly to open and how much attention should be paid to this. Recently, to everyone’s delight, we opened the sources of Hubot, our chat bot. In a couple of days, he scored 500 followers on GitHub and 409 votes on Hacker News. This is expressed in the endorsement of GitHub and even more fans than ever before.

If your code is so popular that it attracts third-party contributors, then you will create a reinforcing effectwhich helps to do more work cheaper. More users means more usage scenarios are being researched, which means more reliable code. Our resque project has been enhanced by 115 different developers outside the company, and hundreds more offering third-party plugins that extend the functionality of resque. Each error correction that you accept in the project is a time saved and a consumer annoyance that was avoided.

Smart people like to communicate with other smart people. Smart developers love working with smart code. When you post useful code, you attract talent. Every time a talented developer looks at the open source code of your project, you win. I had a lot of great conversations at technical conferences about my open source code. Some of these meetings led to ideas that resulted in better solutions to problems with my projects. In an industry with so many creative and productive developers, the right look at your code can play an important role.

If you hire developers, then the best technical interview is one that you do not need to conduct, because the developer has already proved himself in one of your open projects. Once the technical skills have been presented in this way, all that remains is to make sure that the corporate culture is consistent and convince this person to work for you. If they are passionate about the open source code they wrote, and you belong to those companies that care about the quality of the code (and you obviously care), it should be easy! We hired Vicent Martí after we saw his vibrant work on libgit2, a project that we initiated to extract Git functionality to a separate C library. No technical interview was required, Vicent has already demonstrated his skills using open source.

Once you have hired all these cool people with their input, targeting open source is an amazingly effective way to preserve these talents.. Let's see cool developers can choose a job right now. The same developers know the value of open source development and will want to collect a portfolio of projects that they could boast of with friends or potential future employers. Paradox! To make developers happy, you must help them become more attractive to other employers. But there is nothing to worry about, as these are the developers who you want to work for you. So relax and let them work on open source projects, or they will go somewhere where they are allowed.

When I start a new project, I assume that it will ultimately be open (even if this is unlikely). Such an installation effortlessly leads to modularity. If you think about how other people outside your company can use your code, you are less likely to use proprietary components or tightly coupled interfaces. This, in turn, leads to cleaner and more maintainable code. Even the internal code must pretend to be open.

Have you ever developed a wonderful library or tool at one place of work, and then quit to join another company just to rewrite this code or become unhappy because of its absence? I yes, and that sucks. Code publishing dramatically reduces duplication of effort. Less duplication means more work on more important things.

Finally, this is correct . It is now almost impossible to do anything without directly executing a large amount of open source code. If you use the Internet, then you use open source. This code represents the millions of man-hours that have been spent for the common good. We all enjoy this benefit, and I believe that we are all morally obligated to repay this community. If the software is the ocean, then open source is the tide that makes the ships aground.

Okay, but what should I not open?

It's simple. Do not open anything that is the foundation of the business.

Here are some examples of what we do not tear off, and why:

• The main Rails application (it's easier to sell when it's closed)
• Sinatra-based task management application (specially tightly linked to github.com)

Here are examples of what we discovered, and why:

• Grit (general-purpose adapter for Git, useful for developing many tools)
• Ernie (general purpose RPC server for BERT)
• Resque (general-purpose queues)
• Jekyll (general purpose static site generator)
• Gollum (general wiki)
• Charlock_Holmes (general character encoding determinant)
• Albino (general purpose syntax highlighting)
• Linguist (general purpose file type identifier).

Please note that everything that we keep closed has a specific business value that could be violated if it gets to our competitors. All that we have discovered are general-purpose tools that can be used by different people and companies to develop different things.

What is the Only True License?

I prefer MIT and almost everything that we open on GitHub is distributed under this license.

I love this license for several reasons:

• She is short. Anyone can read it and understand exactly what it means without having to spend a ton of money on consultations with high-octane lawyers.
• It provides enough protection to make sure you don't sue me if something goes wrong when you use my code.
• Everyone understands its legal consequences. Strange licenses such as WTFPL and the Beer license claim to be the “freest license” but do not achieve this goal at all. These tricky licenses are too vague and unenforceable to be applicable to some companies. The GPL, on the other hand, is too restrictive and dogmatic to be suitable in many cases. I want my code to be useful to everyone. To everyone. This is what the Open must mean, and this is what the Free must mean.

How can i start?

Easy, just slide this switch on your GitHub repository from “closed” to “public” and tell the world about your project using your blog, twitter or Hacker News and for a beer in a local pub. Then sit back, relax and enjoy the fact that you are part of something bigger.

PS From myself I want to invite readers to participate in the survey to identify the fate of readers' open projects.