Update file mission.md

Below is one example of how the cadence items in [cadence flow](#cadence-flow) fit together to illustrate how we will accomplish our longer term goals by successfully completing our shorter term goals.

1. One part of our [mission](/handbook/company/mission) is everyone can [contribute to GitLab, the application](/handbook/company/mission/#contribute-to-gitlab-application). By making innovation more accessible, we increase **user contributions to the product**, which creates results for a larger audience, which, in turn, allows more users to contribute to our product. This virtuous cycle drives a high rate of innovation for our product and allows more people to innovate and contribute.

1. By making innovation more accessible, we increase **user contributions to the product**, which creates results for a larger audience, which, in turn, allows more users to contribute to our product. This virtuous cycle drives a high rate of innovation for our product and allows more people to innovate and contribute.

1. One component necessary to achieve our [AllOps vision](/handbook/company/vision/) is improving [GitLab ServiceDesk](https://docs.gitlab.com/ee/user/project/service_desk/), which helps connect external parties to the software development process, allowing more people to contribute. ServiceDesk is needed to provide a complete **Value Stream Delivery overview**, which should help more people manage the flow of innovation from [idea to customers](https://about.gitlab.com/solutions/value-stream-management/#:~:text=new%20innovation%20from-,idea%20to%20customers,-.), which should lead to more teams and companies relying on GitLab as their AllOps solution.

1. One pillar of our [three year strategy](https://internal.gitlab.com/handbook/company/three-year-strategy/) is [Customer Results](/handbook/values/#results), which includes **Proving Value** with items like [Value Stream Analytics](https://about.gitlab.com/solutions/value-stream-management/) to help a broader user base [like managers and executives](https://about.gitlab.com/direction/plan/value_stream_management/#who-are-we-focusing-on) deliver value and innovation. Proving value to a broader user base moves us closer to providing a complete Value Stream Delivery overview, creating progress towards our AllOps vision.

---

title: "GitLab Mission"

description: "We at GitLab believe that all digital products should be open to contributions; from legal documents to movie scripts, and from websites to chip designs."

description: "Our mission for the AI era"

canonical_path: "/company/mission/"

---

## Mission

It is GitLab's mission to **enable everyone to contribute to and co-create the software that powers our world**.

Unlock every team to ship trusted software at the speed of imagination.

### The world we’re building for

**Software will be built by machines, directed by people.**

AI is becoming the substrate on which future software gets built. Agents plan, code, review, deploy, and repair. The work humans still own — and will keep owning — is the judgment that matters most: architecture, deep understanding of the customer problem, and the tradeoffs that require taste.

**The demand for software multiplies in the agentic era.**

There are three ways you can contribute and co-create:

Software has been the force multiplier behind nearly every business transformation of the modern era. The constraint was always the cost and time of producing it. That constraint is collapsing. When software can be built in minutes instead of weeks, every business builds more of it, not less. There will be more builders than ever, and we serve an increasing number of them.

1. [Everyone can contribute with GitLab](/handbook/company/mission/#contribute-with-gitlab)

1. [Everyone can contribute to and co-create with GitLab, the application](/handbook/company/mission/#contribute-to-gitlab-application)

1. [Everyone can contribute to GitLab, the company](/handbook/company/mission/#contribute-to-gitlab-company)

**The consequential work belongs to engineers.**

Engineering has always been about more than writing code. Great engineers are problem solvers and builders who care about system design, distributed systems, reasoning through failures, safely integrating new capability into critical systems, and making decisions under ambiguity. These are exactly the skills the agentic era needs more of, especially as the volume of software increases. The supply of deep technical problems is multiplying, and the engineers who can solve them will be among the scarcest and most valuable talent in the market. Their roles are changing, their importance isn't.

### Everyone can contribute with GitLab{#contribute-with-gitlab}

This is the world we’re building GitLab for.

To ensure that **everyone can contribute with GitLab** we allow anyone to create a proposal, at any time, without setup, and with confidence. Let's analyze that sentence a bit.

### The drag we’re eliminating

- Anyone: Every person in the world should be able to afford great DevSecOps software. GitLab.com has free private repos and CI runners and GitLab CE is [free as in speech and as in beer](https://www.howtogeek.com/31717/what-do-the-phrases-free-speech-vs.-free-beer-really-mean/). But open source is more than a license, that is why we are [a good steward of GitLab CE](/handbook/company/stewardship/) and keep both GitLab CE and EE open to inspection, modifications, enhancements, and suggestions.

- Create: It is a [single application](/handbook/product/categories/gitlab-the-product/single-application/) based on [convention over configuration](/handbook/product/product-principles/#convention-over-configuration).

- Proposal: With Git, if you can read it, you can fork it to create a proposal.

- At any time: You can work concurrently with other people, without having to wait for permission or approval from others.

- Without setup: You can make something without installing or configuring for hours with our web IDE and Auto DevSecOps.

- With confidence: Reduce the risk of a flawed proposal with review apps, CI/CD, code quality, security scans, performance testing, and monitoring.

For too long, shipping software has meant choosing between two bad options:

### Everyone can contribute to and co-create with GitLab, the application{#contribute-to-gitlab-application}

Move fast, and break things. Move safely, and ship nothing.

We actively welcome contributors to **enable everyone to contribute to and co-create with GitLab, the application**. When **everyone can contribute and co-create**, users become contributors and we greatly

increase the rate of innovation to benefit customers and users. There is also an open dialogue between GitLab and our customers, partners, and the community so that we can also better identify what they need. That way we can not only build a solution for them, but bring that solution to the world.

Either way, the result is drag — the friction between an idea and the moment it reaches a customer. Drag shows up as handoffs between tools, gates between teams, security as an afterthought, accumulating tech debt and experience debt, compliance as a tax, and weeks lost to coordination that should have taken minutes.

We think that it is logical that our collaboration tools are a collaborative

work themselves. More than [3,000 people from the wider community](https://about.gitlab.com/community/contribute/) have contributed to GitLab to make that a reality.

At machine rate, drag becomes catastrophic. When agents open thousands of merge requests, trigger pipelines around the clock, and push commits faster than any human team ever did, the friction that was tolerable in the human era becomes the bottleneck that defines the agentic one.

We do this by having quality code, tests, documentation, popular frameworks,

and offering a comprehensive [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit)

and a dedicated [GitLab Design System](https://design.gitlab.com/).

We use GitLab at GitLab Inc., we [dogfood](/handbook/product/product-processes/dogfooding-for-r-d/)

it and make it a tool we continue to love. We celebrate contributions by

recognizing a Most Valuable Person (MVP) every month.

We allow everyone to anticipate, propose, discuss, and contribute features by having everything on

a public issue tracker. We ship a new version every month so contributions

and feedback are visible fast. To contribute to open source software, people

must be empowered to learn programming.

That is why we sponsor initiatives such as Rails Girls.

There are a few significant, but often overlooked, nuances of the **enabling everyone to contribute to GitLab, the application** mantra:

Our job is to free everyone from the drag, so every team can ship software with both speed and control.

- While collaboration is a core value of GitLab, over collaborating tends to involve team members unnecessarily, leading to consensus-based decision making, and ultimately slowing the pace of improvement in the GitLab application. Consider [doing it yourself](/handbook/values/#collaboration), creating a merge request, and facilitating a discussion on the solution.

- For valuable features in line with our product philosophy, that do not yet exist within the application, don't worry about UX having a world class design before shipping. While we must be good stewards of maintaining a quality product, we also believe in rapid iteration to add polish and depth after an [MVC](/handbook/product/product-principles/#the-minimal-valuable-change-mvc) is created.

- Prefer creating merge requests ahead of issues in order to suggest a tangible change to facilitate collaboration, driving conversation to the recommended implementation.

- Contributors should feel free to create what they need in GitLab. If quality engineering requires charting features, for example, which would normally be implemented out of another team, they should feel empowered to prioritize their own time to focus on this aspect of the application.

- GitLab maintainers, developers, and Product Managers should be viewed as coaches for contributions, independent of source. While there are contributions that may not get merged as-is (such as copy/paste of EE code into the CE code base or features that aren't aligned with product philosophy), the goal is to coach contributors to contribute in ways that are cohesive to the rest of the application.

### What we believe

A group discussion reiterating the importance of everyone being able to contribute:

Five beliefs guide everything we build:

{{< youtube "l374J98iOmk?t=675" >}}

**Quality is in the eye of the user.** No matter how automated, fast or capable AI becomes, how humans perceive the quality of a tool, determines its success. Pixels without purpose are pointless, great experiences are created when we define success from the user's perspective.

### Everyone can contribute to GitLab, the company{#contribute-to-gitlab-company}

**Trust is built in, not bolted on.** Security, compliance, and governance are properties of the platform itself, not features added at the end. Strong platforms remove the drag that lives in the seams between tools and teams and are the only way speed and control stop being a trade-off.

To **enable everyone to contribute to GitLab, the company** we have open business processes.

This allows all team members to suggest improvements to our handbook. We hire remotely so our team members can be judged on results, not presence in an office. We engage on social media platforms and in our blog post comments. And we strive to take decisions guided by [our values](/handbook/values/).

**Context is the moat.** Models commoditize. What doesn’t is the connected understanding of how a team plans, codes, reviews, secures, deploys, and operates software, accumulated over years.

#### Everyone can contribute to about.gitlab.com

**Humans direct, machines build, both are first-class.** Every enterprise will live across a spectrum of human-owned, agent-assisted, and agent-autonomous work. Agents are participants on the platform and need to be accounted for by AI First design thinking, not by adapting human tool patterns.

We welcome all contributors in the [www-gitlab-com project](https://gitlab.com/gitlab-com/www-gitlab-com) so that **everyone can contribute to about.gitlab.com**. GitLab uses about.gitlab.com to share our expertise with the world and believe we can build even greater levels of trust with contributions from our team and community. We strive to provide a great experience for our existing and new community members by reviewing changes and integrating the contributions into our regularly planned updates.

**Software gets built everywhere.** Cloud and model choice belong to the customer. We’re the constant across them, enabling freedom and adaptability in an industry where the constant is change - in models, patterns, participants, processes and purpose. We are there for it

## Cadence and Alignment

### What we’re building

Our Mission is on a 30 year [cadence](/handbook/company/cadence/#30-years).

Platforms that weren't built for machine scale are starting to break under it. Winning the agentic engineering era means making the right structural investments to ensure security, performance at scale, reliability, and quality of user experience. We're making five architectural bets to be the Intelligent Orchestration platform for the agentic engineering era. Each one is built to deliver without disruption to the customers who depend on GitLab today. 

### Purpose

**Machine-scale infrastructure.** Agents open merge requests in parallel, trigger pipelines around the clock, and push commits at a rate no human team ever did. Git itself wasn't designed for that load, and bolting AI onto platforms not built for agents is the biggest mistake of this era. We're doing a generational rebuild of the underlying infrastructure to handle agent-rate work as the default. Git itself is being reengineered for machine scale. The monolith is giving way to modern, API-first, composable services. And agent-specific APIs are being built so agents can act as first-class users of the platform, not as bolted-on consumers of human-shaped interfaces.

[Our purpose](/handbook/company/purpose/) is to help people **increase their lifetime earnings** through training, access to opportunities, and the DevSecOps platform.

**Orchestration across the full lifecycle.** A single agent that writes code or opens a merge request produces activity. Enterprises don't need agent activity. They need running software that moves the business forward. Orchestration is the layer that gets you there. It coordinates agents across the lifecycle, assigning work, managing state, passing context, resolving conflicts, enforcing policy, and keeping a human in the loop when it matters. CI/CD is one of the components getting reimagined here. The pipeline was designed to take human-rate commits and ship them safely; in the agentic era our orchestration service becomes the runtime that coordinates agents, validates the work and enforces guardrails, and drives change all the way to production at machine rate.

Our mission is the way we realize [our purpose](/handbook/company/purpose/). By **enabling everyone to contribute to and co-create the software that powers our world**, we increase access for people to be creators. With more contributors and more creators, we increase both the volume and velocity of innovation. More innovation drives economic progress that [benefits consumers, businesses, and the economy as a whole](https://www.ecb.europa.eu/ecb-and-you/explainers/tell-me-more/html/growth.en.html). As a result, innovation both directly and indirectly increases the total volume of available opportunities and average value of each individual opportunity.

**Context as the moat** Enterprise AI bills are climbing as fast as adoption. What doesn't commoditize is the context the model gets to work with: a data model that connects planning, code, review, security, deployment, and operations across every project and repository, accumulated over years of a team's work. We're investing in that connected data model as a first-class, API-accessible service, getting richer with every human and agent action. Context is what lets agents spend fewer tokens and deliver better results. 

Access to a broader set of more valuable opportunities ultimately **increases people's lifetime earnings**.

**Governance in the core.** Governance is what lets enterprises move fast in the agentic era. Like a race car, it doesn't matter how fast you can go if you can't maintain control. As agents take on more of the work, enterprises need a platform that can enforce who's allowed to do what, prove what happened and why, and keep sensitive code and data where it belongs. We're building identity, audit, policy, and deployment flexibility as core platform services that every agent, pipeline, and merge request runs through by default, rather than a separate product layered on top.  

[Our purpose](/handbook/company/purpose/) is on the same 30 year cadence as our mission. [Our purpose](/handbook/company/purpose/) informs our mission, which directly or indirectly informs the rest of the items in [our cadence](/handbook/company/cadence/). As a result, progress for the items on our [cadence page](/handbook/company/cadence/) creates progress for both our mission and [our purpose](/handbook/company/purpose/).

**One platform, three modes.** Trillions of lines of code run the world's businesses today. Rewriting most of it is too risky and too expensive to justify. The cloud era taught us enterprises run hybrid, and operating across that mix has been painful, expensive, and never fully solved. The agentic era will be the same. Every enterprise will live across a spectrum of human-owned, agent-assisted, and agent-autonomous work. We're building one platform, one data model, one governance system that operates across all three modes, and delivering it cloud and model neutral.

### Vision

### The way we work

Our mission is the inspiration for [our vision](/handbook/company/vision/). Our vision is on a 10 year cadence.

A culture of excellence is how we make the strategy real. Speed with Quality, Ownership Mindset, and Customer Outcomes are our operating principles. Move quickly. Own outcomes. Deliver real value to customers.

### Values

**A flexible business model** The way software gets built is changing, and our business model is evolving with it. We're keeping what works: the predictability of subscriptions for what customers have today. We've already added consumption pricing for the work agents do, with other major players following over the past few months. Next, we're introducing more flexibility to mix both as the way of work evolves.

Our mission guides our path, and [our values](/handbook/values/) are the principles we live along this path.

### From Act 1 to Act 2

Our original mission was “everyone can contribute.” It was a claim about access — the people closest to the work should be able to shape the software they depend on.

Act 2 carries that DNA forward. “Everyone” is still at the heart of what we do. What changes is the scope: from contributing code to shipping entire systems, autonomously, securely, at the speed of imagination.

Everyone could contribute. Now everyone can ship.

**GitLab’s mission** Unlock every team to ship trusted software at the speed of imagination.

## Customer acceptance

1. Making derogatory statements or threats toward anyone in our community.

1. Encouraging violence or discrimination against legally protected groups.

This policy is in alignment with our mission, contributor and employee code-of-conduct and company values. Here are some links that may give you some background at how we arrived at this customer acceptance policy:

- Our mission is to "enable everyone to contribute to and co-create the software that powers our world." This mission is in alignment with our open source roots and the [MIT license](https://en.wikipedia.org/wiki/MIT_License) our open source software is subject to. The MIT License is a free software license that allows users the freedom to run the program as they wish, for any purpose.

- GitLab has a [contributor code of conduct](https://about.gitlab.com/community/contribute/code-of-conduct/) for *how* to contribute to GitLab, but there are no restrictions on *who* can contribute to GitLab. We desire that everyone can contribute, as long as they abide by the code of conduct.

- GitLab has a set of [CREDIT values](/handbook/values/#credit) for how GitLab team members strive to conduct themselves. We don't expect all companies to share these values in the same way we do. As an open company, "everyone can contribute" is our default, and [transparency](/handbook/values/#transparency) is our check and balance. Transparency means our handbook, issues, merge requests and product roadmap are online for everyone to see and contribute to.

- Related topic: At GitLab, we want to avoid an environment where people feel alienated for their religious or political opinions. Therefore, we encourage GitLab team members to refrain from taking positions on specific [religious or political issues](/handbook/values/#religion-and-politics-at-work) in public company forums (such as on the GitLab Contribute stage or Slack channels) because it is easy to alienate people that may have a minority opinion. It is acceptable to bring up these topics in social contexts such as coffee chats and real-life meetups with other coworkers, but always be aware of cultural sensitivities, exercise your best judgment, and make sure you stay within the boundaries of our [Code of Business Conduct & Ethics](https://ir.gitlab.com/governance/governance-documents/default.aspx). We always encourage [discussion and iteration](/handbook/values/#challenger-mindset) on any company policy, including this one.

This policy is in alignment with our mission, contributor and employee code-of-conduct and company values. 

## Mitigating Concerns

## Everyone can contribute

At GitLab our goal is that [everyone can contribute](/handbook/company/mission/#contribute-to-gitlab-application). This applies to GitLab team members and the wider community through community contributions. We welcome contributions to any and all features, but recognize that first time contributors may prefer to start with smaller features. To support this we maintain a list of `quick wins` that may be more suitable for first time contributors, and contributors new to the domains in Software Supply Chain Security.

At GitLab our goal is that everyone can contribute. This applies to GitLab team members and the wider community through community contributions. We welcome contributions to any and all features, but recognize that first time contributors may prefer to start with smaller features. To support this we maintain a list of `quick wins` that may be more suitable for first time contributors, and contributors new to the domains in Software Supply Chain Security.

If the contributor needs an EE license, we can point towards the [Contributing to the GitLab Enterprise Edition (EE)](/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributing-to-the-gitlab-enterprise-edition-ee) section on the Community contributors workflows page.

## Everyone can contribute

At GitLab our goal is that [everyone can contribute](/handbook/company/mission/#contribute-to-gitlab-application). This applies to GitLab team members and the wider community through community contributions. We welcome contributions to any and all features, but recognize that first time contributors may prefer to start with smaller features. To support this we maintain a list of `quick wins` that may be more suitable for first time contributors, and contributors new to the domains in Software Supply Chain Security.

At GitLab our goal is that everyone can contribute. This applies to GitLab team members and the wider community through community contributions. We welcome contributions to any and all features, but recognize that first time contributors may prefer to start with smaller features. To support this we maintain a list of `quick wins` that may be more suitable for first time contributors, and contributors new to the domains in Software Supply Chain Security.

If the contributor needs an EE license, we can point towards the [Contributing to the GitLab Enterprise Edition (EE)](/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributing-to-the-gitlab-enterprise-edition-ee) section on the Community contributors workflows page.