A quick guide to how to access opensource: who needs it, why and how

At the last internal conference of Contour developers, I gave a talk. In my presentation there was a slide on which the famous Russian IT companies were listed, divided into two columns. There was one major difference between the companies in the right and left columns.

I asked the audience to answer the question, with which companies do you associate yourself more? In what, in your opinion, do cool engineers work, is it interesting to develop there and interesting to go to work, employees of these companies can teach others something, share experience?
At the conference, colleagues almost unanimously voted for companies from the right column.

Their difference consisted in the fact that they actively disseminate their technologies and knowledge - they share open source and understandable manuals with the professional community, speak at conferences. They are consciously invested in the development of their opensource projects. Technologies and descriptions of many of them are in the public domain on specially created sites tech.yandex.ru , opensource.mail.ru , techno.2gis.ru/opensource , and are known to many developers outside of companies.

If you suddenly decide to do charity work (almost) and do something similar in your company, I hope my text will help answer the questions: do you need it, how many resources are needed and what will you get in the end. We released the following site: tech.skbkontur.ru .

I have long had an idea to make such a site for Contour. Many of our teams managed to acquire their own open source projects, but did not widely distribute them for several reasons: it would not bring direct profit, but it would add problems and take time. It needed motivation, an understanding of whether it should be done at all.

For ourselves, we clearly defined three “why”, wrote it down in the Google Desktop and added some details to the file - this is how a peculiar procedure appeared. It can be useful to those who have a desire to put their project in the opensource, but there is no action plan.

What for:

1. Common good: sharing knowledge and skills with the external developer community; we can take, modify and use any alien opensource-code for free - let anyone be able to take the code of our open program.
2. Personal interest: it is possible that someone will like our open-source project and come to work in the team that created it.
3. Image of a technology company: to talk about internal tasks, about how developers are moving forward the technologies themselves and the industry.

Punched cones and the following rules

The project (read its details on Habré ), which we first laid out in the opensource, was the largest and most qualitative of those that we had. We thoroughly approached his preparation for independent living: we wrote documentation, cleaned out specific contour pieces and checked for compliance with all the points of our regulations. But he had a rather narrow audience and a specific use, although there was nothing to reproach us with as a performance.

The first thing that we quickly learned: opensource-project, even if it appeared as a side commercial, exists under the same conditions as the main one. You need to make sure that it will be useful to someone, it needs to be tested, licensed and write supporting documentation. After the release add marketing and pr-events, support, popularization, speaking at conferences and several articles on adaptation and application features. Then respond to bug reports and pull requests. But do not forget that this is a opensource, not a commercial product. It means that they will have to deal with them in parallel with the main activity and it will often be necessary to allocate time according to the residual principle or to the detriment of personal time (you can still convince the manager and colleagues of the importance of the venture - we managed, but it didn’t become much easier) :).

Second: without quality implementation, the project is doomed. We formulated a set of rules and before publishing the project we run it for compliance. We advise you to start with the same.

• Security. The information security department should be aware of what we are posting; we remove from the project all pieces of code that reveal the features of the company's commercial services.
• Quality. Publishing a bad code will only harm the image of the company and the authors. We bring several experienced developers to the code review project to find and fix bugs. At the same time, we adhere to generally accepted world opensource standards (english language, readme.txt, code style, changelog.txt, etc.), their observance reduces the entry threshold for new members of the community, thus expanding the audience.
• Scalability. Ideally, the project should be modular and easily scaleable. That is, it should be easily expanded. The easier it is to expand the product, the lower the entry threshold for new community members.
• Testing. Before laying out, we check the code for performance, in this case we use autotests and rely on open testing tools that include integration with the repository (for example, GitHub & Travis CI).
• Licensing. Laying out the code should be legal, the license is agreed with the legal department. Here it is important to remember that the code is usually published under one of the common opensource licenses (MIT, GPL, BSD, etc.). We usually use MIT, but if inside the project there are pieces of code licensed under the GPL, then the whole project also has to be licensed under the GPL.

• Documentation. If the product is too large to describe in one README text, we accompany the product with documentation that answers the questions:

  
  
  1. how to start using (quickstart)
  2. how to compile and install (building & installing)
  3. how to run
  4. how to test your testing
  5. how to configure
  6. what are the examples of use (examples)
  
  

Third. One open source project will give the company nothing. Even if you did it very cool, laid out, spoke at a conference, wrote on Habré and prepared to wait for feedback ... this does not mean that the stream of sufferers will take everything in its path to download your code and use it in its service.

Now there are ten open source projects on our site. All of them are related products that appeared during the work on Kontur’s commercial services, or products from open sources that were processed for their needs. And this is the whole essence of opensource'a - a product or service can never be considered complete; what we get at a certain stage is the result of collective work, additions of children from different companies, cities and even countries.

It must be admitted that in the opensource we are still among the catch-up: not so many projects, they are just beginning to spread. But for us it was important to begin to lay out the development, not to deviate from our plans. If, after reading this text, you decide that your company has something to share in the opensource-space and it is not a pity to spend your time and energy on it, it means that I wrote this article for good reason.