About Us

GitLab Inc.

GitLab Inc. is a company based on the GitLab open-source project. GitLab is an application to code, test, and deploy code together. It provides Git repository management with fine grained access controls, code reviews, issue tracking, activity feeds, wikis, and continuous integration.

GitLab Inc. has 4 product offerings:

  1. GitLab Community Edition (CE) - free, self hosted application, support from Community
  2. GitLab Enterprise Edition (EE) - paid, self hosted application, comes with additional features and support
  3. GitLab.com - free SaaS for public and private repositories, support can be purchased
  4. GitHost.io - a private single-tenant GitLab instance run by us

GitLab Inc. also offers:

  1. Git and GitLab Training
  2. Consulting
  3. Custom Development work

GitLab is a community project, over 1000 people worldwide have contributed to GitLab! GitLab Inc. is an active participant in this community, trying to serve its needs and lead by example. For more information see Our stewardship of GitLab CE further down this page.

A brief history of GitLab

2011: Start of GitLab

In 2011 Dmitriy was unsatisfied with the options for git repository management. So together with Valery, he started to build GitLab as a solution for this. This commit was the very start of GitLab.

2012: GitLab.com

Sid saw GitLab for the first time and thought it was natural that a collaboration tool for programmers was an open source so you could contribute to it. Being a Ruby programmer he checked out the source code and was impressed with the code quality of GitLab after more than 300 contributions in the first year. He asked Hacker News if they were interested in using GitLab.com and hundreds of people signed up for the beta. In November 2012, Dmitriy made the first version of GitLab CI.

2013: "I want to work on GitLab full time"

Large organizations running GitLab asked Sid to add features that they needed. At the same time Dmitriy tweeted out to the world that he wanted to work on GitLab full time. Sid and Dmitriy teamed up and introduced GitLab Enterprise Edition with the features asked for by larger organizations.

2014: GitLab was incorporated

In 2014 GitLab was officially incorporated as a limited liability corporation. GitLab released a new version every month on the 22nd, just as every year before and after. The first release of the year at January 22nd: GitLab 6.5. At the end of 2014, December 2014, GitLab 7.6 was released.

2015: Y Combinator

In the very start of 2015, almost the entire GitLab team flew over to Silicon Valley to participate in Y Combinator. We graduated in March of 2015 and had 9 people on our team.

2016: Growth

In 2016 the number of people that contributed to GitLab grew to more than 1000. More than 100,000 organizations and millions of users are using GitLab. Our team grew with 100 people to more than 140. In September we announce our master plan and raising $20m in our B round of financing.

Vision

At GitLab we have one vision. Everyone can contribute to all digital content. For more information see the our strategy.

Our Tanuki logo symbolizes this with a smart animal that works in a group to achieve a common goal. Please see our press page to download the logo.

Values

Please see the values section in our handbook.

Our stewardship of GitLab CE

Business model

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 use Enterprise Edition. We recognize that we need to balance the need to generate income and with the needs of the open source project.

Promises

We promise that:

  1. We won't remove features from CE in order to make the same feature exclusive in EE (features might be removed from CE due to changes in the application)
  2. We won't introduce features into CE with a delay, if a feature is planned to land in both it will be released simultaneously in both
  3. We will always release all tests that we have for a feature that is in CE
  4. CE will have all the features that are essential to running a large 'forge' with public and private repositories
  5. CE will not contain any artificial limits (repositories, users, size, performance, etc.)
  6. All major features in our scope will be available in GitLab CE too
  7. The majority of new features made by GitLab Inc. will be available in both CE and EE
  8. CE will be available for download without leaving an email address

What features are EE only

If the wider community contributes a new feature they get to choose if it goes into CE or EE by sending the merge request to the repository they prefer (most go to CE). If the wider community contributes a feature already in EE to CE we use the process linked in Contributing an EE only feature to CE . When GitLab Inc. makes a new features we ask ourselves, is this feature more relevant for organizations that have more than 100 potential users? If the answer is yes the feature is likely to be exclusive to EE.

There are no features that are only useful to larger organizations, so for every EE features there will be smaller organizations that also need it. We're not saying that there are no small organizations that need the EE feature, just that we think that larger organizations are more likely to need it.

It is hard to get CE vs. EE right, and if we put something in EE that should be in CE we won't hesitate to open-source it.

We always make sure that CE can do all major features in our scope and there are companies using CE with more than 10,000 users.

If people ask us why a certain feature is EE only we might reply with a link to this section of the handbook. We do not mean to imply you don't need the feature. It implies we think the feature will be more relevant for larger organizations. Feel free to make the argument for the opposite, we're listening.

What features are EE Premium

See the definition of EE Premium features in our product handbook.

Why release simultaneously in both

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 propietary 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 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 in case when in hindsight we realize we made a mistake applying our criteria. An example is when we learned that a branded homepage was an essential feature. Another example is when we brought GitLab Pages to the Community Edition.

How the GitLab Inc. benefits CE

Apart from making new features GitLab Inc. does a lot of work that benefits both CE and EE:

  1. Responsible disclosure process and security fixes
  2. Release management including a monthly release of both CE and EE
  3. Packaging GitLab in our Omnibus packages
  4. Running a packages server
  5. Dependency upgrades (Rails, gems, etc.)
  6. Performance improvements

Contributing an EE only feature to CE

When someone contributes a feature to CE that is already in EE we have a hard decision to make. We hope that people focus on contributing features that are neither in CE nor EE. This way both editions benefit from a new feature and GitLab Inc. don't have to make a hard decision. The features we plan to build for EE are shared on our direction page and we welcome people to contribute features to CE that are planned for future EE releases, if you pick one from the upcoming release please ask in the issue if someone is already working on it. When someone does contribute a feature to CE that is already in EE we weigh a couple of factors in that decision:

  1. What is the quality of the submitted code?
  2. Is it a complete replacement of the EE functionality?
  3. Does it meet the criteria of the definition of done?
  4. Is it more relevant for organizations that have more than 100 potential users?
  5. Is the person or organizating submitting this using GitLab with more or less than 100 potential users?
  6. Did the person or organization submitting this contribute to GitLab before?
  7. Is it something that many of our existing customers choose GitLab Enterprise Edition for?
  8. Is it relevant for running a large open source forge?
  9. Is it an original work or based on the EE code?
  10. Is there an actively maintained fork that incorporates this?
  11. How many organizations are using this code in production?
  12. How frequently has this functionality been requested for CE and by whom?

We'll weight all factors and you can judge our stewardship of CE based on the outcome. So far (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.

Handbook

If you're interested, most of our internal procedures can be found in publicly viewable handbooks.

Donations

Some people contact us because they would like to donate to GitLab. If you have time to give please help spread the word about GitLab by mentioning us and/or contribute by creating and reviewing issues and merge requests. If you would like to give money please donate to Rails Girls Summer of Code in our name.

Location

GitLab is an open source project with more than 1500 people contributing from all over the world. GitLab Inc. has people in more than 35 countries. We're proud to be remote only. You can taste a bit of the GitLab team culture by visiting our culture page.