October 26, 2016 at 11:55

GitLab on open source project management policies

Original author: Sytse Sijbrandij
  • Transfer

Some are skeptical about GitLab - they say you’ll stop supporting the free Community Edition (CE), and what will we do? Do not stop. We publish for you a translation of an article on this topic.



Recently, we have fixed our policy regarding support for open source software (open source) and our dedication to this development method. Briefly, our policy can be described as follows: you need to make decisions in the interests of the project, while not forgetting about the business that this project supports. In this article, I want to share with you thoughts about some of the rules in our policy.



The challenges of managing an open source project


Matthias Stürmer from Opensource.com has identified four types of open source communities :


  1. Projects with a single curator (single-vendor projects)
  2. Development communities
  3. User communities
  4. Interaction centers (open source competence centers)

The last three types are characterized by distributed development processes. In some cases, development is coordinated by community-based nonprofits, but in any case, this type of community does not have any single source of funding. Examples of such communities are Apache, Rails, and Linux.


On the contrary, the first type, “projects with a single curator,” is characterized by financial support for a specific commercial organization, which controls the direction of the development of the project and finances most of the main developers. Examples of communities of this type are Wordpress and Automattic; Hadoop and Cloudera; Elasticsearch and Elastic.


Whenever a curator company is involved in developing an open source project, the question arises - which development model will it choose? The company must balance between the needs of the business, development support and keeping the project afloat. Moreover, the company should make a profit from the project, because the project itself and its community are financed precisely with its money. However, unlike software with closed source code, open source projects can be forked and continue their development outside the curated company.


For us, open source is a set of ethical obligations, not just a license


Open source appeared as a result of the Free Software movement. When the term 'open source' originated in the late 90s , it emphasized the fact that the source code could be viewed and even modified. Also, using this term, we were able to get rid of comparisons with beer (“free as in beer”), which hinted at the poor quality of the product. At the same time, the introduction of the term open source laid the foundation for the financing of such projects by commercial organizations. Since 1998, open source has become the de facto standard, a measure of quality and a guarantee that the project will not be monopolized by a vendor lock-in.


However, the introduction of the term 'open source' had the opposite effect - the activist roots of the Free Software movement (“free as in freedom”) have lost their force. The open source movement is based on collaboration, which requires mutual trust. When commercial companies supporting open source projects neglect these principles, mutual trust is lost, and without it the whole concept of open source ceases to work.


Any company that makes code open in the pursuit of competitive advantage should consider ethical issues that immediately arise. Open source is not just a type of license, but also a set of ethical obligations. Our company has undertaken these obligations by formulating a policy of a good open source project manager.


What does it mean to be a good manager of an open source project?


I did not want to create a manager’s policy until we had an absolute understanding of all the conditions and context of our project and company. Now, after several years, we better understand the situation and its corresponding requirements.


First of all, you need to think in the interests of the project, while not forgetting the realities of the business that this project supports. When creating our policy, we took into account the experience of other communities and projects that had problems with this. Companies with open source projects often criticize on the following points:


  • Transparent decision-making process in the direction of the project.
  • Company participation in open communication channels.
  • Caring for the interests of the company to the detriment of the interests of the project.

All these points must be taken into account if we want to achieve full support for the project, code, community and users.


On the other hand, one cannot focus solely on the needs of the project, forgetting about commercial issues. After all, commercial success is a prerequisite for the existence of a project.


For example, our experienced sales team shared with us their troubles: “Why should the software be free for absolutely all users? Why don't users who work with teams of more than 10,000 developers pay us a dime? ” Indeed, when selling intellectual property, you can set a limit on free use. Sales people ask: “Why not set a limit on the number of users in the free version? As long as you have fewer than 1000 developers, you can use Community Edition, but for a larger team you will have to buy an enterprise edition. ” From an economic point of view, such a decision is justified, but in the context of open source it loses all meaning.


Open source is not a shareware model where we can block access to the product after 30 days. The product is completely free. Forever and ever.


We are not the only company faced with such problems. A year ago, Adam Jacob of Chef said : “We are trying to understand what functionality needs to be included in various service packages, and how to find a balance between our desire to conduct a successful business and our sincere belief that open source is the future of infrastructure . ” That was a year ago, since Chef has made significant progress as managers of its project.


Chef, Nathen Harvey, now VP of Community Development, said in an interview on this subject : “At the intersection of open source and commercial interests, issues of authority, authenticity and culture are raised.” What will be more important - commercial interests or project development? This is a very important question, the answer to which should be considered in any open source project with a single curator. Neyten cites his main principle on this issue: “transparency is most important” - we completely agree with him.


What is our policy?


Our views on open source are not just enshrined in our policy - they are traced in every aspect of our work. We believe that you cannot gain a competitive advantage by closing yourself from the outside world. On the contrary, we strive to maintain the level of communication and collaboration with the user community as high as possible.



This level of transparency is unprecedented for closed source software, rare for open source projects with a single curator and atypical even among other repository management platforms (it does not matter whether open source or not). In truth, the history of source code management and community work is full of intentional obfuscation and stories of broken trust. We don’t want to repeat these mistakes and believe that in order for GitLab to become a place for safe and open joint development, it itself must be an open source platform.


In our policy, we pay attention to all those things that we promised not to do. We have clearly outlined the difference between GitLab CE (Community Edition) and EE (Enterprise Edition), and we take into account the requirements of the community by clearly indicating all our obligations.


We encourage you to read our policies. Now that it is published, you can demand that we complete it.


Please read the GitLab CE Management Principles .


The translation from English was made by the translation team "Brain and Partners", http://nadmosq.ru , the main translator is sgnl_05

Tags:

Also popular now: