Geekly Articles each Day
📜 ⬆️ ⬇️

GitLab on open source project management policy

Some are skeptical about GitLab - they say that you will 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.



We recently documented our open source support policy and our dedication to this development method. In short, 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 complexity of managing an open source project


Matthias StĂĽrmer from Opensource.com 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 non-profit community-based organizations, 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 of a particular commercial organization that controls the direction of the project’s development and finances most of the main developers. Examples of communities of this type are Wordpress and Automattic; Hadoop and Cloudera; Elasticsearch and Elastic.


Whenever the company-curator develops an open source project, the question arises - which development model will it choose? The company must balance between the needs of the business, the support of the development and the project to stay afloat. Moreover, the company must make a profit from the project, because the project itself and its community are funded precisely by its money. However, unlike closed source software, open source projects can be forked and continue their development outside the curator's 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' was born in the late 90s , it was used to emphasize the fact that the source code could be viewed and even modified. Also, using this term, we managed to get rid of comparisons with beer (“free as in beer”), which hinted at the low 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 a de facto standard, an indicator of quality and a guarantee that the project will not be monopolized by the curator (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”) were no longer valid. The open source movement is based on a collaboration that requires mutual trust. When commercial companies that support open source projects neglect these principles, mutual trust is lost, and without it, the whole concept of open source stops working.


Any company that makes a code open in pursuit of competitive advantages must take into account ethical issues that will arise immediately. Open source is not just a type of license, but also a set of ethical obligations. Our company assumed these obligations by formulating the 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 policy as long as we did not have an absolute understanding of all the conditions and context of our project and company. Now, after a few years, we better understand the situation and the corresponding requirements.


First of all, you need to think in the interests of the project, while not forgetting about 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 it. Companies with open source projects are often criticized for the following points:



All of 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, it is impossible to focus attention solely on the needs of the project, forgetting about commercial issues. In the end, commercial success is a necessary condition for the existence of a project.


For example, our experienced sales team shared its troubles with us: “Why should software be free for absolutely all users? Why don't users who work with teams from more than 10,000 developers pay us a penny? ”After all, when selling intellectual property, you can set a limit for free use. Salespeople ask: “Why not set a limit on the number of users in the free version? While you have less 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, this decision is justified, but in the context of open source it loses any meaning.


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


We are not the only company facing such problems. A year ago, Adam Jacob from Chef said : “We are trying to understand what functionality to include in various service packages and how to find a balance between our desire to run a successful business and our sincere belief that open source is the future of infrastructure This was a year ago, since Chef has progressed noticeably as managers of its project.


Nathen Harvey, now VP of Community Development, Chef, said in an interview on this topic : “At the intersection of open source and commercial interests, issues of authority, authenticity and culture are raised.” Which 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 gives his main principle on this issue: “transparency is most important” - we completely agree with him on this.


What is our policy?


Our views on open source are not just fixed in our policy - they can be traced in every aspect of our work. We believe that you can not get a competitive advantage by closing on the outside world. On the contrary, we strive to keep 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 (whether open source or not). In truth, the history of managing source code and working with the community is full of deliberate obfuscation and stories of broken trust. We do not want to repeat these mistakes and believe that in order for GitLab to become a place for safe and open collaborative 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 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 of our obligations.


We encourage you to familiarize yourself with our policies. Now that it is published, you can demand that we carry it out.


Please read the GitLab CE Management Principles .


Translation from English is made by translational artel "Nadmozg and partners", http://nadmosq.ru , the main translator is sgnl_05


')

Source: https://habr.com/ru/post/313632/

More articles:


All Articles