Recently, GitLab was publicly discussing an internal decision about hiring locations for some specific roles with responsibility for technical support for GitLab.com (GitLab’s SaaS service).
This discussion was sparked by GitLab’s growing SaaS customer-base because many customers have requested more limited administrator access to servers hosting customer-specific data. There was no specific security incident that caused this discussion, and no customer data has been compromised. Following GitLab's value of transparency, the team was working through the issue in a public forum. We realize this process may have confused or even offended some people.
Hiring as an all-remote company
GitLab is an all-remote company. We hire team members internationally, and we must create policies that align with security and legal regulations. This puts us in a unique position. Most companies simply open a job in an existing office location (for example, in San Francisco, London, Beijing, or any other city) and, by default, you will hire a resident of those cities for those roles. They would never have to write a policy that defines residency requirements for specific roles.
We wrote this proposal to clarify that instead of a few cities, we could hire for these few specific roles anywhere in the world except for China and Russia. In addition, we would continue to hire for all other GitLab roles in China and Russia, too. We continue our commitment to our team members and customers located in China and Russia, and we will continue to hire internationally for roles at GitLab.
GitLab has hundreds of roles, and this internal decision would only affect a few specific job roles for future hires that require administrator access to servers hosting sensitive customer-specific GitLab.com data to do their jobs.
This policy proposal has not been implemented yet, as discussions are continuing internally.
Why was this discussion public?
GitLab values transparency, and we run our business operations according to this value. We believe this transparency builds trust with our customers and team, encourages contribution and collaboration, and improves our efficiency and velocity. This means that we often discuss and iterate on processes and company policies in the open. As we experienced with our hiring policy discussion, transparency is often hard. Sometimes transparency exposes differences of opinions inside GitLab itself, not to mention outside of GitLab. As a position is formed, the process exposes differing opinions within GitLab itself as well as those within the community. When people then add to the argument with helpful (and sometimes hurtful) comments, it can seem chaotic. We don’t have it all figured out yet, but we think the upside of transparency is worth the struggle to enable and continue the highest level of transparency in our business.
These discussions are internal business discussions. At other companies, these discussions would likely happen behind closed doors among key stakeholders. It is highly unlikely that they would be posted on a public forum for all to read. But at GitLab, we try to conduct business operations in the open to the extent that we are able.
What prompted this discussion about hiring?
This particular discussion arose because the majority of GitLab.com’s SaaS customers come from the United States, where GitLab.com’s data resides, and, as our customer base is growing rapidly, we have seen more requests from customers to meet their individual security policies and requirements for tighter controls over who can access their sensitive data. Remember - customers are putting their source code (their intellectual property) into GitLab.com, and they require it to be safe. GitLab and its customers are continuing to mitigate cyber-security threats, and this was just one discussion among many discussions on how GitLab can put additional safeguards in place to meet customer security requirements.
Was GitLab really considering not hiring any Chinese or Russian nationals?
No. GitLab currently has employees in China and Russia and continues to hire in China, Russia and across 60+ countries and regions worldwide for the vast majority of roles. This discussion was always only about opening specific new roles at GitLab in China and Russia, in which administrator access to servers hosting customer-specific GitLab.com data (SaaS) is required.
GitLab does not discriminate against any nationality/citizenship in its hiring processes. This proposed policy was about residency requirements for these specific roles, because of the nature of the job responsibilities for these roles, and not nationality.
Today, there are no current GitLab employees in those specific roles that reside in China or Russia, so no current employees would be affected. This was only a discussion about whether to open new specific roles in these regions.
Also, GitLab continues to do business in China and Russia and currently has active customers in both China and Russia. GitLab’s business is limited by local laws as well as US laws and restrictions, as GitLab is a US-based company and must comply with US laws.
Why does residency matter to GitLab.com customers?
Residency matters for security reasons. Many customers who host sensitive company data in SaaS services (such as source code, and other sensitive intellectual property) prefer or require to have their data – and access to that data – reside in specific regions for legal and security purposes.
The majority of GitLab.com’s SaaS customers come from the United States, where GitLab.com’s data resides, and we have seen more requests from customers to have tighter controls over who can access that data.
In the future GitLab Inc. (or companies in which GitLab Inc. has an ownership stake) might run GitLab.com-type SaaS services for other parts of the world. For example, you might imagine separate GitLab SaaS instances with data residency in Europe, China or Russia which would have similar residency requirements to address the data access needs of customers in those regions.
Would this policy affect GitLab self-managed (on-premises) products or support?
No. This policy, if implemented, would only affect GitLab.com, GitLab’s SaaS service. This policy would NOT impact GitLab self-managed (on-premises) products or support. Self-managed products include any of the GitLab products that customers run on their own infrastructure and manage themselves.
How would a policy like this affect GitLab’s open source code or contributions to GitLab’s code?
Anyone of any nationality and residing in any region of the world can use GitLab’s open source products and open source code. We also welcome contributions from anyone of any nationality and residing in any region of the world.
Commitment to our values
GitLab strives to be inclusive in its hiring process. Along with transparency, diversity is one of our core values. We have valued team members that are based in China and Russia, and we will continue to hire in China and Russia. We also have hundreds of customers in China and Russia and will continue to do business with customers located in those countries. Once a decision has been made about this policy, we will update our public company handbook accordingly.
