View the source (almost) total
This time I would like to offer to read the [free] translation of the article by Tom Preston-Werner, one of the co-founders of GitHub, in which he discusses what benefits a company can derive from the opening of its projects, which projects should not be opened and what is the Only Right 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 was working on a Rail application, and I was working on Grit, the first ever Git Ruby adapter. After six months of development, Grit was complete enough to serve GitHub during our public launch of the site and we faced an interesting question:
Should we open the Grit source or leave it proprietary?
')
Leaving proprietary would be an obstacle for competing Git hosts, giving us an edge. Open source meant that thousands of people around the world could use it to develop interesting tools, creating an even brighter Git ecosystem.
After a bit of a dispute, we decided to open the Grit source. I do not remember all the details of the discussion, but this decision, made almost four years ago, led to what I consider one of our main values: to open the source for (almost) everything.
If you do everything right, then open source is a great advertisement for you and your company. At GitHub, we like to publicly discuss the libraries and systems that we have developed that 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 source of Hubot, our chat bot. In a couple of days, he scored 500 GitHub subscribers and 409 votes on Hacker News. This is expressed in the approval 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 effect that helps you do more work cheaper. More users means that more usage scenarios are being explored, which means more reliable code. Our resque project has been improved by 115 different developers outside the company, and hundreds more, offering third-party plug-ins that extend the resque functionality. Each correction of a mistake that you take into a project is saved time and consumer annoyance that has been avoided.
Smart people love to communicate with other smart people. Smart developers love working with smart code. When you publish a useful code, you attract talents . Every time a talented developer looks into the open source code of your project, you win. I had a lot of great conversations at technical conferences about my open source. 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, the best technical interview is one that you do not need to do, because the developer has already shown himself in one of your open source projects. As soon as technical skills were presented in such a way, all that remains is to make sure that they are in line with the corporate culture and convince this person to work for you. If they are passionate about the open source they have written, and you treat those companies that care about the quality of the code (and you obviously care), it should be easy! We hired Vicent MartĂ, after seeing his vivid work on libgit2 , a project we initiated to bring Git functionality to a separate C library. No technical interview was required, Vicent had already demonstrated his skills with open source.
After you've 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 place to work right now. These same developers know the value of open source development and will want to put together a portfolio of projects that they could boast to friends or potential future employers. Paradox! To make developers happy, you need to help them become more attractive to other employers. But there is nothing to worry about, as these are the developers that you want to work for you. So relax and let them work on open source projects, or they will go somewhere where they will be allowed.
When I start a new project, I assume that it will eventually be open (even if this is unlikely). Such an installation effortlessly leads to modularity. If you think about how other people, outside of your company, may use your code, there is less chance that you will use proprietary components or tightly coupled interfaces. This, in turn, leads to cleaner and more supported code. Even the internal code must pretend to be open.
Have you ever developed a great 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 it sucks. Publishing the code dramatically reduces duplication of effort . Less duplication means more work on more important things.
Finally, this is correct . Now it is almost impossible to do something without directly running a large amount of open source. If you use the Internet, then you use open source. This code personifies the millions of man hours 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 an ocean, then open source is tide stripping ships.
It's simple. Do not open anything that is the basis of business.
Here are some examples of what we do not tear, and why:
Here are examples of what we discovered, and why:
Please note that everything that we keep closed has a specific business value that can 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.
I prefer MIT and almost everything we open on GitHub is distributed under this license.
I love this license for several reasons:
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 a beer in a local pub. Then sit back, relax, and enjoy being part of something bigger.
PS From myself I want to invite readers to participate in the survey, to identify the fate of open projects of readers.
When Chris and I started working on GitHub at the end of 2007, we divided the work into two parts. Chris was working on a Rail application, and I was working on Grit, the first ever Git Ruby adapter. After six months of development, Grit was complete enough to serve GitHub during our public launch of the site and we faced an interesting question:
Should we open the Grit source or leave it proprietary?
')
Leaving proprietary would be an obstacle for competing Git hosts, giving us an edge. Open source meant that thousands of people around the world could use it to develop interesting tools, creating an even brighter Git ecosystem.
After a bit of a dispute, we decided to open the Grit source. I do not remember all the details of the discussion, but this decision, made almost four years ago, led to what I consider one of our main values: to open the source for (almost) everything.
Why open source (almost) just 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 the libraries and systems that we have developed that 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 source of Hubot, our chat bot. In a couple of days, he scored 500 GitHub subscribers and 409 votes on Hacker News. This is expressed in the approval 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 effect that helps you do more work cheaper. More users means that more usage scenarios are being explored, which means more reliable code. Our resque project has been improved by 115 different developers outside the company, and hundreds more, offering third-party plug-ins that extend the resque functionality. Each correction of a mistake that you take into a project is saved time and consumer annoyance that has been avoided.
Smart people love to communicate with other smart people. Smart developers love working with smart code. When you publish a useful code, you attract talents . Every time a talented developer looks into the open source code of your project, you win. I had a lot of great conversations at technical conferences about my open source. 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, the best technical interview is one that you do not need to do, because the developer has already shown himself in one of your open source projects. As soon as technical skills were presented in such a way, all that remains is to make sure that they are in line with the corporate culture and convince this person to work for you. If they are passionate about the open source they have written, and you treat those companies that care about the quality of the code (and you obviously care), it should be easy! We hired Vicent MartĂ, after seeing his vivid work on libgit2 , a project we initiated to bring Git functionality to a separate C library. No technical interview was required, Vicent had already demonstrated his skills with open source.
After you've 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 place to work right now. These same developers know the value of open source development and will want to put together a portfolio of projects that they could boast to friends or potential future employers. Paradox! To make developers happy, you need to help them become more attractive to other employers. But there is nothing to worry about, as these are the developers that you want to work for you. So relax and let them work on open source projects, or they will go somewhere where they will be allowed.
When I start a new project, I assume that it will eventually be open (even if this is unlikely). Such an installation effortlessly leads to modularity. If you think about how other people, outside of your company, may use your code, there is less chance that you will use proprietary components or tightly coupled interfaces. This, in turn, leads to cleaner and more supported code. Even the internal code must pretend to be open.
Have you ever developed a great 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 it sucks. Publishing the code dramatically reduces duplication of effort . Less duplication means more work on more important things.
Finally, this is correct . Now it is almost impossible to do something without directly running a large amount of open source. If you use the Internet, then you use open source. This code personifies the millions of man hours 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 an ocean, then open source is tide stripping ships.
Ok, but what should I not open?
It's simple. Do not open anything that is the basis of business.
Here are some examples of what we do not tear, and why:
- Main Rails application (easier to sell when it is closed)
- Sinatra task management application (specifically tied to github.com)
Here are examples of what we discovered, and why:
- Grit (Git general purpose adapter, useful for developing a variety of tools)
- Ernie (general purpose RPC server for BERT)
- Resque (general purpose queues)
- Jekyll (static general site generator)
- Gollum (general purpose wiki)
- Charlock_Holmes (generic character encoding determinant)
- Albino (general purpose syntax highlighting)
- Linguist (determiner of general-purpose file types).
Please note that everything that we keep closed has a specific business value that can 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 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 what exactly it means without having to spend a lot of money on consultations with high-octane lawyers.
- It provides enough protection to ensure that you do not sue me if something goes wrong when you use my code.
- Everyone understands its legal implications. Strange licenses, such as the WTFPL and Beer license (Beer license) claim to be the “freest license” but do not achieve this goal at all. These tricky licenses are too vague and impracticable to be applicable for some companies. On the other hand, the GPL is too restrictive and dogmatic to be suitable in many cases. I want my code to be useful to everyone. Everybody. That's what the Open should mean, and that's what Free should 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 a beer in a local pub. Then sit back, relax, and enjoy being part of something bigger.
PS From myself I want to invite readers to participate in the survey, to identify the fate of open projects of readers.
Source: https://habr.com/ru/post/276723/
All Articles