Co-Create Program

Overview

The Co-Create Program transforms enterprise customers into active GitLab contributors by providing the necessary support to develop new features, enhance existing ones, or fix bugs. Through workshops, pair programming, and ongoing guidance, customers work directly with GitLab engineers to contribute meaningful improvements that benefit the entire GitLab community.

What We Offer

1. Technical Enablement Workshop: Interactive session to help customers set up GitLab Development Kit (GDK) and understand GitLab’s architecture
2. On-Site Engineering Support: One GitLab engineer co-located for one week to kick off co-creation through pair programming, with the goal of completing at least one merge request
3. Legal Support: Assistance with Corporate Contributor Agreements and open source policies
4. Ongoing Mentorship: Dedicated support from the Contributor Success team for long-term contribution success

Program goals

1. Product Development Acceleration: Community contributions deliver customer-validated features at speed and scale beyond internal development alone
2. Customer Retention & Expansion: Deep technical engagement opens relationships with new personas within customer organizations, revealing additional use cases and growth opportunities while increasing retention through their investment in the platform
3. Competitive Differentiation: Nurtures enterprise advocates who boost GitLab’s share of voice in competitive evaluations, demonstrating our unique collaborative model versus traditional vendor relationships
4. Marketing Amplification: Generates authentic and referenceable customer testimonials and success stories for customer advocacy campaigns

Program Health Metrics

Program success is tracked through multiple metrics across the customer journey. See Co-Create Success Metrics for detailed tracking methodology and current performance.

Target Audience and Criteria

Eligibility requirements

1. Premium or Ultimate tier customers (CSM-led accounts)

Ideal Customer Profile

Organizational Characteristics

1. Premium or Ultimate tier customers (CSM-led accounts required)
2. Engineering teams with capacity to dedicate time to contributions
3. Organizations with open source experience or OSPO (preferred but not required)
4. Companies seeking specific platform enhancements aligned with GitLab roadmap

Engineering Team Attributes

1. Curiosity-driven engineers eager to learn and develop technical skills
2. Passion for open source and collaborative development
3. Willingness to learn Ruby, Go, or Vue.js (prior experience not required)
4. Commitment to pair programming and code review processes

Application Process

Customers can apply through our Co-Create landing page. Applications are evaluated based on:

1. Alignment of contribution goals with GitLab product direction
2. Customer team readiness and availability
3. Current GitLab usage and engagement level
4. Potential for long-term contribution relationship

Structure and Components

Program Benefits

For customers:

1. Zero Maintenance Burden: GitLab maintains all contributions, freeing teams from ongoing upkeep
2. Accelerated Feature Delivery: Direct contribution is faster than traditional feature requests
3. Enhanced Platform Knowledge: Deep understanding of GitLab architecture improves internal usage
4. Community Recognition: Contributors acknowledged in release notes and community

For GitLab:

1. Product Development Acceleration: Customer-validated features beyond internal capacity
2. Customer Retention: Deep technical engagement and increased platform investment
3. Competitive Differentiation: Unique collaborative model versus traditional vendors
4. Marketing Amplification: Authentic customer testimonials and success stories

Phase 1: Qualification & Planning (2-4 weeks)

Activities

1. Application review and customer qualification
2. Initial discovery call with account team and customer stakeholders
3. Identification of contribution opportunities
4. Product Manager alignment on contribution scope
5. Legal documentation review and execution

Deliverables

1. Signed Corporate Contributor Agreement
2. Defined contribution scope and objectives
3. Scheduled technical enablement workshop and on-site week dates
4. Assigned GitLab engineer

Phase 2: Technical Enablement (1-2 weeks before on-site)

Activities

1. GDK setup workshop (virtual)
2. GitLab architecture overview relevant to contribution area
3. Introduction to contribution workflow and testing frameworks
4. Environment validation and troubleshooting

Deliverables

1. Functional GDK installations for participating engineers
2. Access to GitLab development resources and documentation
3. Slack channel for ongoing communication

Phase 3: On-Site Collaboration (1 week)

Activities

1. Daily pair programming sessions with GitLab engineer
2. Code development, testing, and documentation
3. Real-time code review and feedback
4. Merge request submission

Deliverables

1. Complete merge request(s) submitted with tests and documentation

Phase 4: Follow-Up & Long-Term Success (ongoing)

Activities

1. Merge request reviews and iterations
2. Ongoing mentorship from Developer Relations Engineering team - details
3. Connection to broader GitLab community

Deliverables

1. Merged contributions
2. Customer testimonial and success story
3. Case study development (optional)
4. Recognition in release notes

Roles & Responsibilities

Co-Create Program Manager

1. End-to-end program coordination and execution
2. Customer communication and expectation management
3. Progress tracking and reporting
4. Continuous program improvement
5. Issue resolution and escalation management

DRI: Wesley De Vrient @wdevrient-ext

Account Team (AE/SA/CSM/As)

1. Identify potential Co-Create candidates within customer base
2. Introduce program and facilitate initial conversations
3. Support legal documentation process
4. Maintain customer relationship throughout engagement
5. Identify opportunities for expanded Co-Create participation (additional teams, follow-on contributions)
6. Identify business expansion opportunities (additional use cases, feature adoption, seat growth)

Contributor Success

1. Conduct technical enablement workshops (GDK setup, architecture overview)
2. Ongoing mentorship for contributors
3. Connect contributors to GitLab Community Discord and relevant community channels
4. Develop Co-Create-specific enablement materials (workshop guides, GDK setup documentation)

Technical Lead: Raimund Hook @stingrayza

GitLab Engineering

1. Refine the Engineering effort and align on contribution scope with Product
2. Identify appropriate engineers for on-site assignments
3. Provide deep technical expertise during on-site week
4. Conduct code reviews and provide feedback
5. Ensure contributions meet quality standards
6. Knowledge transfer and mentorship
7. Maintain curated issue lists for Co-Create program

Coordinator: Shekhar Patnaik @shekharpatnaik

Product Management

1. Validate contribution alignment with product roadmap
2. Provide strategic context for contributions
3. Curate suitable issues for Co-Create program
4. Collaborate with Engineering to approve final contribution scope

Resources & Support

For Account Teams

1. Co-Create Landing Page
2. Application Form
3. Customer Success Stories
4. Co-Create Pitch Deck
5. Customer-Facing Doc
6. Program Training Recording (Internal only)
7. Internal Training Deck (Internal only)
8. Slack: #cocreate-initiative

For Customers

1. Contribute to GitLab
2. Tutorial: Make a GitLab contribution
3. GitLab Development Kit (GDK)
4. Curated Co-Create Issues
5. GitLab’s Corporate Contributor Agreement
6. Contribution FAQ
7. GitLab Community Discord

Contacts

Support Channels

For program-related questions and GitLab internal inquiries:

• Slack: #cocreate-initiative - General channel for program questions, candidate identification, and internal coordination

For active customer engagements:

• Dedicated Slack Channel: Created for each engagement with format #cocreate-initiative-CUSTOMERNAME
• Includes: Customer team, Account team (CSM, SA, AE), Program Manager, Technical Lead, and GitLab Engineer

For customers and community:

• Email: contributors@gitlab.com
• Community: GitLab Community Discord

Team Contacts

1. Program Manager: Wesley De Vrient - @wdevrient-ext
2. Technical Lead: Raimund Hook - @stingrayza
3. Manager, Developer Relations Programs: Isa Huerga Ayza - @ihuerga
4. Director, Contributor Success: Nick Veenhof - @nick_vh
5. Engineering Coordinator: Shekhar Patnaik - @shekharpatnaik
6. General Inquiries: contributors@gitlab.com

Playbook

For Program Manager

Project Management & Tracking

All Co-Create customers are managed through our Co-Create GitLab project.

Project Structure

1. Epics: One epic per customer to group all related work
2. Issues: Individual issues track each phase of the Co-Create journey:
   • Qualification & Planning
   • Technical Enablement
   • On-Site Collaboration
   • Follow-Up & Long-Term Success

Maintaining Status

The GitLab project serves as the single source of truth for engagement status. Program Managers must:

1. Create an epic when a new customer enters the program
2. Create phase-specific issues and link them to the customer’s epic
3. Update issue status as the engagement progresses through each phase
4. Document blockers, decisions, and key milestones in issue comments
5. Close issues as phases complete
6. Keep epic description updated with high-level engagement summary

Note: Always update the GitLab project before weekly syncs and OKR reporting to ensure accurate program status.

Engagement Execution

Discovery Call Agenda

1. Co-Create overview and customer benefits
2. Customer objectives and desired contributions
3. Technical team readiness assessment
4. Legal requirements overview
5. Next steps and timeline

Project Planning Checklist

1. Product Manager approval on contribution scope
2. Corporate Contributor Agreement initiated if needed
3. GitLab engineer identified and scheduled
4. Customer engineers confirmed and available
5. On-site week dates confirmed
6. Travel and logistics arranged
7. GDK enablement workshop scheduled
8. Success criteria defined
9. Communication plan established

During On-Site Week

1. Daily sync with GitLab engineer via Slack
2. Monitor progress in Slack channel
3. Address blockers immediately
4. Document learnings and wins
5. Capture quotes and feedback for testimonials
6. Plan post-onsite follow-up

Post-Engagement

1. Schedule testimonial interview within 2 weeks
2. Connect customer to Contributor Success for ongoing support
3. Work with Product Marketing on case study
4. Document lessons learned
5. Plan quarterly follow-up
6. Update customer record in SFDC

OKR Update Process

The Co-Create program tracks quarterly OKRs that require regular updates. This process allows any PM to generate reports without deep program familiarity.

Data Location

OKR data is maintained in the Co-Create Metrics Spreadsheet. This data is updated via an automated pipeline.

Running the Update Pipeline

1. Navigate to Contributor Success Toolbox Pipelines
2. Click “Run pipeline”
3. Add the following variables:
   • CO_CREATE_TRACKER = 1
   • PERIOD_START_DATE = YYYY-MM-DD (start of the quarter)
   • PERIOD_END_DATE = YYYY-MM-DD (end of the current week or end of quarter)
   • DRY_RUN = 0
   • CI_PIPELINE_SOURCE = schedule
   • CO_CREATE_REPORT_SHEET_ID = 1JqhcR2PSpKG3lQRU3Y8llo0K71aWWTrJNFjsjzGQiM4
4. Click “Run pipeline” and wait for completion (typically a few minutes)
5. Monitor status until it shows “job succeeded” or “job failed”

Troubleshooting Pipeline Failures

1. Access the “Jobs” tab of the pipeline
2. Open the failed job to review error details
3. Address issues and re-run pipeline

Using the Results

1. Open or refresh the Co-Create results file
2. Navigate to the “Calculator” tab
3. Update the Source sheet field with the dates used in your pipeline (corresponds to sheet name)
4. Use the calculated results to update:
   • Quarterly OKR progress
   • End of Week reports

Update Frequency

Run this pipeline weekly during the quarter or as needed for reporting. Note: Automatic scheduling is pending implementation; currently requires manual execution.

New Co-Create Lead Received from CSM/AE

This playbook covers the Program Manager’s response workflow when an Account Team member (CSM, AE, or SA) surfaces a potential Co-Create opportunity.

Trigger

A CSM, AE, or SA reaches out (typically via Slack) with a customer interested in Co-Create.

Initial Assessment (Same Day)

Review what information the Account Team has provided:

Information	Action if Missing
Customer name	Ask immediately
Account tier (Premium/Ultimate)	Check SFDC or ask
Specific issues or feature areas	Note as TBD - will explore in discovery
Customer contacts identified	Ask who from customer side is interested
Context (escalation, roadshow, proactive outreach)	Ask what prompted the interest

Tip: Leads arrive in different states. Some come with specific GitLab issues already identified (like support escalations), others are exploratory. Both are valid starting points.

Respond to Account Team

Reply within 1 business day with:

1. Acknowledgment and enthusiasm
2. Any clarifying questions from assessment above
3. Proposed next step (usually: “Let’s schedule a quick sync” or “I’ll create the tracking issue”)

Example response:

“Thanks for bringing this forward! [Customer] sounds like a great fit. Before I create the tracking issue, can you confirm they’re on Ultimate and who from their side expressed interest? Happy to schedule a quick call to align on approach.”

Check for Timing Considerations

Before pushing forward, ask the Account Team:

• Is there an active escalation or sensitive situation with this customer?
• Is there an existing regular call we could join vs. scheduling something new?
• Any upcoming renewals or expansion conversations to be aware of?

Why this matters: Joining an existing customer call (like a CSM weekly sync) can be more effective than scheduling a separate meeting. If there’s an active escalation, the Account Team may need to resolve that first.

Create Tracking Issue

Once you have basic information confirmed, create the Initial Engagement issue in the Co-Create Program project:

1. Use the Company Name - Initial Engagement template
2. Assign yourself and the CSM
3. Add to the appropriate customer epic (create one under Contributor epic if needed)
4. Apply Strategy Programs::Co-Create label
5. Tag the Account Team member in a comment with next steps

Determine Path Forward

Based on information gathered, choose the appropriate next step:

Scenario	Next Step
Customer has specific issues in mind	Verify issues exist, check with relevant PM for co-create suitability before discovery call
Customer interest is exploratory	Schedule discovery call to understand their goals; use Co-Create Pitch Deck
Lead came from event/roadshow	Connect with GitLab attendee (often Technical Lead) for context before reaching out
Account Team wants alignment first	Schedule internal sync before customer contact

Schedule the Discovery Call

Coordinate with Account Team to schedule the discovery call. See Discovery Call Agenda for meeting structure.

Attendees:

• Program Manager (you)
• CSM (required)
• SA (if technical depth needed)
• Customer: Engineering lead + manager ideally

Don’t create the dedicated Slack channel yet - wait until after discovery call confirms mutual fit.

Update Tracking

After each interaction, update the Initial Engagement issue:

• Check off completed tasks
• Add notes
• Update status field as appropriate

Common Scenarios

“Customer is dealing with an escalation right now” Acknowledge timing, offer to wait, and set a reminder to follow up in 2-3 weeks. Keep the tracking issue open with a note.

“Customer wants a feature that isn’t on our roadmap” This is still worth exploring - see Getting Product Approval for a Co-Create Issue playbook. The discovery call can help clarify if the contribution aligns with product direction.

“Customer already submitted via the application form” Check the form responses, merge information with what Account Team provided, and proceed to discovery call scheduling.

Getting Product Approval for a Co-Create Issue

This playbook covers the process for securing Product Manager approval when a customer wants to work on an issue that isn’t already on the curated Co-Create list.

When to Use This Playbook

Scenario	Action
Customer wants to work on an issue with the ~co-create label	No approval needed - proceed directly to qualification
Customer wants to work on an issue without ~co-create label	Use this playbook
Customer has a feature idea not yet captured as an issue	Create the issue first, then use this playbook
Account team nominates an issue for the curated list	Use this playbook

Prerequisites Before Contacting PM

Gather this information before reaching out:

Information	Why It Matters
GitLab issue link	PM needs to review the specific issue
Customer name and tier	Demonstrates strategic value
Customer’s use case	Helps PM understand the business need
Customer’s timeline	Affects prioritization discussion
Technical team readiness	Shows customer commitment

Tip: If the customer doesn’t have a specific issue, search GitLab Issues first. There may already be an issue that matches their need.

Step 1: Identify the Right Product Manager

Use the GitLab Product Categories page to find the PM responsible for the relevant area.

Quick lookup process:

1. Identify the GitLab feature area (e.g., “Package Registry”, “CI/CD Pipelines”, “Security Scanning”)
2. Navigate to the Product Categories page
3. Find the Stage → Group → Category that matches
4. Note the PM listed for that category

If unclear which PM owns it:

• Check the issue labels for stage/group hints (e.g., ~devops::package, ~group::pipeline authoring)
• Ask in #product Slack channel
• Reach out to Contributor Success team for guidance

Step 2: Assess Issue Readiness

Before contacting the PM, quickly assess the issue’s current state:

Ready for Co-Create

• ✅ Clear problem statement
• ✅ Defined scope/acceptance criteria
• ✅ Assigned milestone (not just Backlog)
• ✅ Weight estimated
• ✅ No open technical debates

Likely Needs Work First

• ⚠️ Issue is in “problem validation” or “solution validation” phase
• ⚠️ Multiple competing technical approaches being discussed
• ⚠️ No milestone assigned
• ⚠️ Recent significant scope changes
• ⚠️ Blocked by other issues

If the issue isn’t ready: Consider whether the customer can wait, or discuss with the PM what would be needed to get the issue Co-Create ready.

Step 3: Loop in the PM

Where to Have the Conversation

Bring the PM into the existing conversation rather than starting a separate thread:

Situation	Channel
Customer-specific channel already exists	#cocreate-initiative-[customer] - tag the PM there
No customer channel yet	#cocreate-initiative - start the conversation there

This keeps context visible to the account team and avoids fragmented conversations.

What to Include When Tagging the PM

• Link to the issue
• Brief context on the customer’s use case
• Why the customer wants to work on this specific issue
• Any timeline considerations

What PMs Evaluate

When you reach out, the PM will assess:

Criterion	What They’re Looking For
Roadmap alignment	Does this fit with planned direction?
Maintenance burden	Can Engineering support this long-term?
Scope appropriateness	Is this achievable in a Co-Create engagement?
Community benefit	Will this help more than just this customer?
Technical readiness	Is the issue well-defined enough to start?

Step 4: Handle the Response

PM Says “Yes”

1. Thank them and confirm they’ll add the ~co-create label (or ask if you should)
2. Ask if there’s anything specific to note for the on-site engineer
3. Update your tracking issue with PM approval date and any notes
4. Proceed with customer qualification

PM Says “Yes, but needs work first”

Common scenarios and responses:

PM Says	Your Response
“Issue needs clearer scope”	Ask: “Would you be able to refine the scope, or should we schedule a call with the customer to clarify requirements?”
“Needs technical design first”	Ask: “What’s the timeline for that? Should we pause or can the customer help with the design?”
“Need to check with Engineering”	Ask: “Should I reach out to the EM, or will you loop them in?”

Key question to ask: “What would need to happen for this to be Co-Create ready, and what’s a realistic timeline?”

PM Says “Not aligned with roadmap”

This doesn’t always mean “no” - probe further:

1. Ask for specifics: “Can you help me understand why? Is it the approach, the timing, or the feature itself?”

2. Explore alternatives: “Is there a related issue that would address a similar need and fit better?”

3. Check for flexibility: “If the customer is willing to adjust the approach, would that change things?”

If it’s a firm no:

• Thank the PM for their time
• Return to the Account Team with the feedback
• Help identify alternative contribution opportunities for the customer

PM Says “This issue is too early”

Issues in “problem validation” or without clear technical direction aren’t ready for Co-Create.

Questions to ask:

• What milestone do you expect this to be ready for development?
• Is there anything the customer’s use case could help clarify?
• Are there any related issues that might work in the meantime?

Decision point: If the timeline is 3+ months, recommend the customer consider a different contribution opportunity while waiting.

PM is Unresponsive (>3 business days)

1. Send a polite follow-up in the same channel

2. Try alternative channels:

   • Tag them in the GitLab issue
   • Ask in their team’s Slack channel
   • Reach out to their Engineering Manager

3. Escalate if needed (see escalation section below)

Step 5: Escalation Path

Use escalation sparingly and only when:

• PM is unresponsive after multiple attempts (5+ business days)
• PM declines but reasoning seems inconsistent with GitLab’s open source values
• Customer opportunity is time-sensitive and strategic

Escalation Steps

1. First: Reach out to the relevant Engineering Manager for the group
2. Second: Contact the Group Product Manager (PM’s manager)
3. Third: Raise in #cocreate-initiative for Contributor Success leadership guidance

When NOT to Escalate

• PM gave a reasonable “no” based on product direction
• Issue genuinely isn’t ready for contribution
• Timeline just doesn’t work out
• There’s a better alternative issue available

Step 6: Document the Outcome

Update your tracking issue with the PM’s response and any relevant context from the conversation. This ensures the account team and anyone picking up the engagement later has visibility into what was discussed and decided.

Quick Reference: Common Scenarios

Situation	Likely Path
Customer found a ~Seeking community contributions issue	Usually straightforward - confirm with PM and proceed
Customer wants to fix a bug they reported	Good fit - PM typically receptive
Customer wants a feature that benefits only them	May not align - explore if scope can be broadened
Issue has active MR from GitLab engineer	Likely conflict - find alternative
Issue is in a security-critical area	Extra scrutiny required - may need Staff+ engineer review
Issue requires architectural changes	Complex - PM will likely need Engineering input

Customer Declines or Doesn’t Qualify - Closing an Opportunity

This playbook covers how to gracefully close a Co-Create opportunity when it’s not moving forward, and how to keep the door open for future engagement.

When to Use This Playbook

Scenario	Action
Customer explicitly declines to participate	Use this playbook
Customer doesn’t meet qualification criteria	Use this playbook
Customer is interested but timing doesn’t work	Use this playbook - close as “revisit later”
Customer goes silent after multiple follow-ups	Use this playbook
PM declines the issue and no alternative works	Use this playbook
Engagement stalls indefinitely in qualification	Use this playbook

Common Reasons for Closing

Customer-Side Reasons

Reason	Typical Situation
Resource constraints	Customer can’t dedicate engineering time right now
Timing	Busy period, competing priorities, or upcoming deadlines
Legal/compliance concerns	Internal policies prevent open source contribution
Loss of champion	Key advocate left or changed roles
Scope mismatch	What they wanted doesn’t align with what’s possible
Cold feet	Interest faded once they understood the commitment

GitLab-Side Reasons

Reason	Typical Situation
Doesn’t meet criteria	Not CSM-led, wrong tier, or no clear contribution fit
No suitable issue	PM declined their issue and alternatives don’t interest them
Engineering capacity	Can’t schedule an on-site engineer in their timeframe

Mutual Reasons

Reason	Typical Situation
Timeline mismatch	Neither side can align schedules
Stalled conversation	Back-and-forth died out, no momentum

Step 1: Confirm It’s Time to Close

Before closing, make sure you’ve:

• Followed up at least twice over 2+ weeks if they’ve gone quiet
• Explored alternatives if their first-choice issue didn’t work out
• Confirmed with the account team (CSM/AE) that closing makes sense
• Checked if there’s a “revisit later” date vs. a hard close

Don’t rush to close - some opportunities just need more time. But don’t let them linger indefinitely either.

Step 2: Determine the Close Type

Close Type	When to Use	What It Means
Revisit Later	Customer interested but timing doesn’t work	Set a follow-up date, keep tracking
Soft Close	Went quiet, may re-engage	Note last status, stop active pursuit
Hard Close	Explicit decline or doesn’t qualify	Remove from active pipeline

Step 3: Close the Conversation Gracefully

If Customer Explicitly Declined

Acknowledge their decision and leave the door open. A brief message in the channel or to the CSM is sufficient - thank them for considering it and let them know they’re welcome to revisit anytime.

If Customer Went Quiet

Send a final check-in through the account team. If still no response, it’s fine to let it rest. No need for a formal “we’re closing this” message - that can feel pushy.

If They Don’t Qualify

Redirect them appropriately:

• Point them to standard contribution resources if they want to contribute independently
• Let them know they’re welcome to reach out again if circumstances change (tier upgrade, account growth, etc.)

If an AE or other team member surfaced the lead, loop them in on the outcome.

Step 4: Offer Alternatives Where Appropriate

Not every close has to be final. Consider:

Situation	Alternative to Offer
Can’t do full Co-Create engagement	Point to self-serve contribution path
Timing doesn’t work now	Agree on a timeframe to revisit
Their issue didn’t qualify	Suggest curated issues that might interest them
Resource constraints	Smaller scope engagement or async contribution

Don’t force it - if they’re not interested in alternatives, that’s fine.

Step 5: Update Tracking

Update your tracking issue to reflect the closure:

• Note the reason for closing
• Indicate whether it’s a hard close or revisit-later
• If revisit-later, note when to follow up
• Close the issue (or move to appropriate status)

If a customer Slack channel was created, coordinate with the account team on whether to archive it.

Step 6: Debrief with Account Team

Quick sync with the CSM/AE to:

• Share any feedback the customer gave about why they declined
• Discuss whether there are other teams at the customer who might be interested
• Align on if/when to revisit

This doesn’t need to be a formal meeting - a Slack thread is usually enough.

Re-Engagement Triggers

Closed opportunities can reopen. Watch for:

Signal	Action
Customer creates new GitLab issues	CSM mentions it, gauge interest
Champion returns or new advocate emerges	Account team flags for outreach
Customer tier changes (upgrade to Premium/Ultimate)	May now qualify
GitLab adds feature they wanted	Reach out - contribution opportunity may exist
6+ months pass on a “revisit later”	Check in with account team

What Not to Do

• Don’t burn bridges - even a “no” today could be a “yes” later
• Don’t over-communicate the close - a simple update is enough, no need for formal closure emails
• Don’t take it personally - many factors are outside your control
• Don’t leave it in limbo - if it’s dead, close it so your pipeline reflects reality

For Account Teams: Identifying Candidates

Step 1: Assess Customer Fit

Look for these signals:

1. Customer has created multiple issues or feature requests
2. Engineering team actively uses GitLab’s advanced features
3. Organization has open source participation history
4. Technical leaders express interest in deeper GitLab knowledge
5. Recent GitLab usage growth or expansion discussions

Step 2: Initial Introduction

Use this conversation framework:

1. Introduce Co-Create as unique GitLab partnership opportunity
2. Share relevant success story (Thales, Scania, Kitware etc.)
3. Explain value: “Your engineers contribute the feature, GitLab maintains it forever”
4. Highlight accelerated delivery compared to feature request process
5. Gauge interest and identify technical stakeholders

Step 3: Facilitate Connection

1. Direct customer to application form
2. Create Slack channel: #cocreate-initiative-CUSTOMERNAME
3. Invite: CSM, SA, AE, @wdevrient-ext, @stingrayza
4. Schedule discovery call with customer stakeholders

For Engineering: On-Site Best Practices

Please refer to Co-Create On-Site Engineer Guide

FAQ

For Account Teams

Q: Which customers are eligible?

A: Premium or Ultimate tier customers with CSM support. Ideal candidates have engineering capacity, technical curiosity, and interest in platform enhancements. Prior open source experience is beneficial but not required.

Q: What if my customer wants to contribute but isn’t Premium/Ultimate?

A: They can still contribute through our standard community contribution path. The Co-Create Program’s white-glove service (on-site engineer, dedicated workshops) is reserved for Premium/Ultimate customers.

Q: How do I convince my customer this is worth their time?

A: Share these points:

1. Research shows contributing firms achieve up to 2x productivity gains
2. GitLab maintains their contributions forever—zero ongoing maintenance burden
3. Faster than traditional feature request process
4. Builds deep platform expertise that improves their internal GitLab usage

Q: What’s the time commitment for my customer?

A: Typically 1-3 engineers for 1 week on-site, plus 2-3 hours for GDK setup workshop beforehand. Post-engagement time varies based on merge request feedback cycles.

Q: Can customers work on any issue they want?

A: Contributions must align with GitLab’s product direction. We maintain a curated list of pre-approved issues. Custom issues require Product Manager approval.

Q: What if legal is concerned about contributions?

A: We have a Compatibility Guide for Corporate Contributors and can arrange consultation with our legal experts. The Corporate Contributor Agreement is standard across tech companies with open source contributions.

Q: How is this different from a feature request?

A: Feature requests enter product prioritization process with uncertain timelines. Co-Create allows customers to develop what they need immediately, with GitLab maintaining it long-term.

For Customers

Q: Do we need Ruby or Go experience?

A: Not required. GitLab engineers provide pair programming support and teach as you code. Prior experience with any programming language is sufficient.

Q: Who owns the code we contribute?

A: Please refer to https://about.gitlab.com/community/contribute/dco-cla/#do-i-retain-rights-in-my-contributions

Q: What happens if our contribution isn’t accepted?

A: Product Manager approval occurs before the on-site week to ensure alignment. During development, GitLab engineers guide you to meet quality standards. Rejection is extremely rare with this level of support.

Q: Can we contribute to multiple areas?

A: Yes! Returning customers often expand their contributions. Initial engagements typically focus on one area to build confidence and establish processes.

Q: What if we need specific network configurations or can’t run GDK locally?

A: We work with you to find solutions. GitLab Workspaces can help overcome network restrictions. The enablement workshop addresses environment challenges before the on-site week.

Q: How quickly will our contribution be in a GitLab release?

A: Timeline varies by contribution complexity and review cycles. Contributions always ship in the next release following merge request approval.

Q: Can we publicize our participation?

A: Yes! We encourage it. We can support joint announcements, blog posts, and conference presentations. Many customers use Co-Create as part of their open source programs office initiatives.

For GitLab Team Members

Q: How are on-site engineers selected?

A: Engineering leadership identifies engineers with expertise in relevant codebase areas, availability, and interest in mentorship. Engineers typically volunteer for these engagements.

Q: What if a contribution requires significant architectural changes?

A: These should be identified during the qualification phase. Product Managers assess scope and may recommend breaking large contributions into smaller iterations or starting with a simpler related issue.

Q: How do we handle contributions that conflict with planned work?

A: Product Manager alignment happens before commitment. If conflicts arise, we work with the customer to find alternative contribution opportunities that don’t create conflicts.

Q: What if the customer wants to continue contributing after the on-site week?

A: Excellent! Connect them with Contributor Success team for ongoing mentorship. Many customers become long-term contributors.