This section captures the most frequently asked questions from potential customers during initial conversations. Use it to prepare for discovery calls and ensure consistent messaging.
#### Program Basics
**Q: What exactly does Co-Create involve?**
A: GitLab sends one engineer to your site for one week to pair-program with your team on a contribution to GitLab. Before that, we run a virtual workshop to set up the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) and walk through the architecture. Afterward, the Contributor Success team provides ongoing mentorship as your merge requests move through review.
**Q: Is this a consulting engagement? Do we pay for it?**
A: No. Contributions are open source, not paid work. GitLab provides the engineer and support at no additional cost as part of our commitment to open source collaboration. This is not a professional services engagement.
**Q: How is this different from filing a feature request?**
A: Feature requests enter product prioritization with uncertain timelines. Co-Create lets your team build what you need now, with GitLab engineers guiding you. GitLab maintains the contribution long-term — your team never has to do upkeep when new releases ship.
**Q: What's the catch? Why does GitLab do this?**
A: GitLab is an open-core company — community contributions are part of how we build the product. Your contributions accelerate our roadmap with features validated by real-world use cases. We also build deeper relationships with customers who understand the platform at an engineering level. It's a genuine partnership, not a one-sided arrangement.
#### Scope & Issue Selection
**Q: Can we work on whatever we want?**
A: Contributions need to align with GitLab's product direction. We maintain a [curated list of pre-approved issues](https://cocreate.gitlab.com/?label=co-create), but if you have something specific in mind, we work with the relevant Product Manager to assess fit. That approval happens before we commit to an on-site, so there are no surprises.
**Q: What if the thing we care about isn't on the curated list?**
A: That's common. Bring the issue or idea to the discovery call and we'll assess alignment with the relevant Product Manager. If the specific issue doesn't work, we'll help find something related that still delivers value for your team.
**Q: What kinds of contributions are realistic in one week?**
A: Typical engagements result in at least one merge request. Past examples range from UI improvements (Thales simplified the empty project page in a few hours) to more complex feature work (Scania advanced Conan package registry support over multiple iterations). We scope appropriately during planning so the week is productive.
**Q: What if we want to fix a bug we've been dealing with rather than build a new feature?**
A: Bug fixes are a great fit for Co-Create. Customers who experience an issue firsthand are often the best people to solve it. We still need Product Manager alignment, but PMs are typically very receptive to customer-driven bug fixes.
#### Team & Time Commitment
**Q: How many engineers do we need to dedicate?**
A: We recommend 4-8 engineers for the on-site week, though successful engagements have run with smaller groups. You'll also need 2-3 hours beforehand for the GDK setup workshop. The key is that participating engineers have dedicated time during the on-site week — this shouldn't compete with their regular sprint work.
**Q: Do our engineers need Ruby or Go experience?**
A: No. GitLab engineers pair-program with your team and teach as you go. Prior experience with any programming language is sufficient. Several past participants at Thales, Scania, and other organizations had no Ruby background and contributed successfully.
**Q: How do we justify pulling engineers off their regular work for a week?**
A: A few angles that resonate with engineering leadership:
1.[Research from Harvard Business School](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3091831) shows contributing firms capture up to 2x more productive value from open source software they use
1. GitLab maintains everything you contribute — zero ongoing maintenance burden, which offsets significant internal engineering time
1. Skills transfer is immediate and practical: one Scania engineer used Ruby knowledge gained through Co-Create to troubleshoot an internal upgrade issue weeks later
1. Direct contribution is faster than the traditional feature request process
1. Engineers gain deep platform knowledge that improves how your entire organization uses GitLab
**Q: What's the total timeline from first conversation to on-site?**
A: Typically 6-8 weeks end-to-end: 2-4 weeks for qualification and planning (including PM approval and legal), 1-2 weeks for the enablement workshop, then the on-site week. The main variable is how quickly legal and scheduling come together on your side.
#### Legal & IP
**Q: Our legal team has concerns about contributing to open source.**
A: Very common, especially in regulated industries. We have a standard [Corporate Contributor Agreement](https://about.gitlab.com/community/contribute/dco-cla/) used across the tech industry, plus a [license compatibility guide](/handbook/marketing/developer-relations/programs/cocreate/license-compatibility-guide/). We can arrange a call with our legal experts to walk your counsel through the specifics. Organizations in financial services, defense, and automotive have all completed this process.
**Q: Who owns the code we contribute?**
A: Contributors retain rights in their contributions. Details are covered in the [DCO/CLA FAQ](https://about.gitlab.com/community/contribute/dco-cla/#do-i-retain-rights-in-my-contributions) and the Corporate Contributor Agreement.
**Q: What about our internal IP? Could contributing expose proprietary information?**
A: Contributions are scoped to GitLab's codebase — you're improving GitLab, not sharing your internal systems. The issues worked on are defined and agreed upon before the engagement starts. Your engineers work on GitLab code within the GDK environment, not on your production instance.
#### Technical Environment
**Q: What if our environment has network restrictions or we can't run GDK locally?**
A: We work through this during the enablement workshop before the on-site week. We will work with you to find a solution that works best for your team.
**Q: What technical setup is required on our side?**
A: Participating engineers need a development machine that can run GDK (Linux, macOS, or Windows with WSL2). We walk through the full setup during the enablement workshop 1-2 weeks before the on-site. If there are corporate restrictions on local installations, we explore alternatives like GitLab Workspaces or containerized GDK setups.
#### After the On-Site
**Q: What happens after the week is over?**
A: Merge requests go through GitLab's standard review process. The Contributor Success team provides ongoing support through that cycle. Many customers continue contributing independently afterward. We also connect your team to the [GitLab Community Discord](https://discord.gg/gitlab) for broader community support.
**Q: Who maintains what we build?**
A: GitLab does. That's one of the core benefits — your contribution ships in a GitLab release and GitLab's engineering team handles all future maintenance. Your team is free from upkeep when release changes occur.
**Q: Can we come back and do more?**
A: Absolutely. Returning customers often expand to new teams or feature areas. Scania started with smaller changes and progressed to major package registry work over time. We also explore hackathon-style formats for larger organizations that want to scale participation across multiple teams.
**Q: How quickly will our contribution appear in a GitLab release?**
A: Once a merge request is approved and merged, it ships in the next GitLab release. GitLab releases monthly, so the turnaround is relatively fast. Some contributions have gone from on-site week to production in under two months.
#### Publicizing Participation
**Q: Can we publicize our participation?**
A: Yes, we encourage it. We can support joint blog posts, conference presentations, and case studies. Many customers use Co-Create participation as part of their open source program office initiatives. We'll work with you on any approval process needed on your side.
**Q: Do you have examples of other companies that have done this?**
A: Yes. Published examples include:
1.**Thales**: Improved GitLab's empty project UI, simplifying SSH/HTTPS configuration for 30 million users
1.**Scania**: Advanced Conan package registry support, recognized as GitLab MVPs in the 17.8 release
1.**Kitware**: Added OAuth2 device authorization grant flow for high-performance computing use cases
We can share more details and the [Co-Create blog post](https://about.gitlab.com/blog/2025/01/30/the-co-create-program-how-customers-are-collaborating-to-build-gitlab/) during or after the discovery call.
