GitLab Inc. is a for profit company that balances the need to improve GitLab Community Edition (CE) with the need to add features to GitLab Enterprise Edition (EE) exclusively in order to generate income. We have an open core business model and generate almost all our revenue with subscriptions to paid tiers. We recognize that we need to balance the need to generate income and with the needs of the open source project.
We have tried different business models, and many didn’t work. As a company, we realized we needed recurring revenue to continue our mission, and we introduced Enterprise Edition. Initially, everyone was worried innovation would stop on the Community Edition, but within six months, the Enterprise Edition was under the MIT license, and the community saw we were building both products, which helped us to build trust.
Our customers became confused, so after six months the arrangement stopped, and response was positive about the shift. We strive to keep improving both editions and to keep the promises below.
We promise that:
If the wider community contributes a new feature they get to choose if is open source or source-available (propietary and paid) by sending labeling merge request with the tier they prefer. If the wider community contributes a feature that is currently source-available we use the process linked in Contributing an EE-only feature to CE.
When GitLab Inc. makes a new feature we ask ourselves who is the likely type buyer to determine what tier the feature goes into. If the likely buyer is an individual contributor the feature will be open source, otherwise it will be source-available.
There aren't any features that are only useful to managers, directors, and executives. So for every source-available feature there will be an individual contributor that might need it. We're not saying that there aren't any individual contributors that need the feature, just that we think that other buyers are relatively more likely to need it. The more of GitLab that you use the more likely it is that you benefit from a higher tier. Even a single person using GitLab might be best off using our highest tier.
It is hard to get the tier right, and if we put something in a tier that is too high we won't hesitate to open-source it or move it to a lower tier. We listen to our community in order to find what we feel is the right balance, and we iterate and make changes based on their feedback. At the same time, the premium product needs to hold value, and we believe we proide that.
All stages of the DevOps lifecycle are available in GitLab CE. There are companies using GitLab unpaid with more than 10,000 users.
If people ask us why a certain feature is paid we might reply with a link to this section of the handbook. We do not mean to imply you don't need the feature. Feel free to make the argument for moving it to another tier, we're listening.
Sometimes people suggest having features in EE for a limited time. An example of a limited time release strategy is the Business Source License that keeps features proprietary for 3 years.
At GitLab we want to give everyone access to most of the features (and all the essential ones) at the date they are announced. We want to give people the option to both run and contribute to an open source edition that is maintained and that includes the most recent security fixes.
From time to time we do open source a feature that used to be EE only. We do this when we realize that we've made a mistake applying our criteria, for example when we learned that a branded homepage was an essential feature or when we brought GitLab Pages to the Community Edition.
Our plan is to become the most popular tool for people’s own git hosting service; we’ve managed that so far. Secondarily, we want to get to be the one with the most revenue. Thirdly, we want to become the most popular tool for hosting private repos. Once we’ve reached that, we want to be the most popular tool for hosting public repos. And, lastly, we want to be the number one tool for people to host not just code but books, tech papers, visual models, movies, etc. More info on this is on our strategy page
GitLab Inc. has an open core business model that includes source-available code and selling subscriptions. This benfits the the open source part of GitLab in the following ways:
We never move existing features already in CE, into EE. This applies regardless of whether the feature was created by GitLab Inc. or community contributors. On occasion, the reverse does happen where we open source a previously source-available feature.
When someone contributes an existing EE feature to CE, we have a hard decision to make. We encourage contributors to focus on new features not already existing in CE and EE, so that both CE and EE editions of GitLab benefit from the feature, and we can avoid any difficult decisions.
When someone contributes an existing EE feature to CE, we weigh a number of factors to decide in accepting it, including:
We'll weigh all factors and you can judge our stewardship of CE based on the outcome. As of July 22, 2016, we had only two cases: One had low code quality and the other one copied the EE code down to the last space. If you find these or other examples please link them here so people can get an idea of the outcome.
In case we're not sure, we'll consult with the core team to reach a conclusion.
When someone contributes a not yet existing feature on the EE issue tracker, and it has met the contribution acceptance criteria, we will accept it in whatever edition (CE or EE) they contribute to, provided that GitLab Inc. has not already started on working on the feature. (The contribution should not contain any already existing EE features in it.) We encourage contributors to @-mention the relevant product manager earlier in the development process (in the issue or merge request) to ensure GitLab team members are not already working on the feature in order to avoid conflicts.