GitLab Co-Create Program Decoded by Nick Veenhof

When a simple interface tweak by just two engineers can save minutes each day for 30 million users, you know there must be a secret to that kind of impact. At GitLab, that secret is the Co-Create Program, and at its helm sits Nick Veenhof, Director of Contributor Success and Programs. His mission is deceptively straightforward: turn passive users into active contributors who not only report issues but help shape the very code they depend on.

In this interview with Alka Elizabeth, Sub-Editor at The DropTimes, Nick reveals how his role bridges the gap between customer needs and GitLab’s engineering roadmap. He walks us through the nuts and bolts of onboarding new contributors, setting up side-by-side collaboration sessions, and smoothing out the friction that typically slows open source contributions to a crawl. The result is real improvements delivered in days, not months.

With nearly twenty years immersed in open source, beginning in the Drupal community and evolving through countless projects, Nick brings both deep technical know-how and an intuitive sense of community dynamics. He lays out the inner workings of Co-Create, shares standout success stories like the project-creation UI overhaul that now benefits millions, and casts a vision for how rapid, customer-driven contributions could reshape the future of open source collaboration.

TDT [1]: I think we’ll start with a very obvious question. You’ve been involved with open source for about 15 years now. That’s a long time. What has kept you involved for so long? Is there something that still excites you about the whole process?

Nick Veenhof: Yes. I checked the other day because someone (Bert Boerland) was trying to organize a meeting for people who’ve been involved in Drupal for over 20 years. My account on Drupal.org is 17 years old, so unfortunately, I’m not invited.

What’s kept me going is the culture and the openness of communication. It’s about sharing knowledge openly instead of keeping it to yourself for personal benefit. I don’t think I fully understood that when I started, but over time, it became very clear that I couldn’t imagine working in any other way.

What still excites me is going to conferences and meeting people who are passionate about sharing what they know, helping others, and figuring out how to create business models around open source. That’s still a challenging area, but there’s a lot of potential there.

It’s also clear, though not my own statement, that almost every company in the world uses open source, whether they realize it or not. Think about cURL, Linux, all of these tools are everywhere. So yes, it still excites me.

TDT [2]: Let’s move on to your role at GitLab. You’re the Director of Contributor Success and Developer Relations. That’s not a typical title. What does the role actually involve?

Nick Veenhof: You're right, it’s not a common position. It only exists because GitLab is an open-core company. That means a large part of our product is under an MIT license, and the rest is under our GitLab Enterprise Edition license, which is source-available.

You May Like

Blog

The DropTimes: Reflecting on a Year of Insights, Milestones, and Enriching Content

Blog

The DropTimes: Reflecting on a Year of Insights, Milestones, and Enriching Content

If we weren’t open source or open core, it wouldn’t make sense to ask customers to help us improve the code because they wouldn’t be able to access it. But since they can, it fits our business strategy to involve customers and users in contributing.

The idea is that if customers contribute improvements to GitLab, they help shape the product in ways that make it more useful to them. That makes them want to use it even more. We describe this as a dual flywheel, and you can find more about it in our public handbook, just search for “GitLab dual flywheel strategy.”

My job is to work with customers and help them contribute. That includes setting up the right tools, helping with onboarding, and ensuring a smooth journey from wanting to contribute to successfully submitting a contribution.
For example, we ran a user study last year where 20 people tried contributing to GitLab. Around half of them were so frustrated with the experience that they gave up. So, part of my team’s role is to identify and fix those pain points to make it easier.

We also support people who want to fix things that bother them or add features that have real business value. We work especially closely with larger customers. That’s where the Co-Create Program comes in, which I believe we’ll discuss more shortly.

TDT [3]: Yes, we’ll definitely come to that. But before that, how long have you been in this role? Since it's an unusual position, how do you measure the impact of what you’re doing?

Nick Veenhof: Nearly three years now. At GitLab, we’re very focused on transparency and metrics, so we do measure impact clearly. Everything is documented in our public handbook, which spans thousands of pages.

We have two major KPIs. One is the number of unique contributors to GitLab per month. We’re not just counting contributions, we’re counting the number of individual people who are actively participating. If it’s not enjoyable or it’s too difficult to contribute, people won’t come back. That’s my responsibility, to ensure they do come back and keep engaging.

The second KPI is something we call MRARR. It measures contributions coming from large customers. If a company with 10,000 GitLab users contributes something, that change potentially impacts all those users. So, those contributions are very valuable. Tracking and increasing that number is also part of my role.

TDT [4]: Right now, in the Drupal community, there’s an ongoing discussion about makers and takers, how we can increase contributions. Recently, Tim Doyle published a blog post about the rise in Drupal-certified partners, but there’s still a long way to go. Bringing in contributions is always a challenge. So, when it comes to contribution at GitLab, what are the major challenges you face? Specifically, what makes it difficult to bring in more contributors?

Nick Veenhof: The first thing you have to understand is why people contribute. Usually, it’s because they want to solve a specific problem. They’re trying to scratch their own itch. The hard part is understanding their motivation, especially when they’re not contributing. Because if they’re not doing it, they won’t tell you why.

It’s easy to fix something when you can see it clearly in the process. For example, in Drupal, if DDEV isn’t working, it’s obvious and fixable. But what about the silent blockers? Why aren’t some companies contributing at all? Often it’s because they don’t see the business value.

So, in my role, the biggest challenge is explaining that value. We have to understand their needs and start a conversation with them. To bring it back to Drupal, there are agencies, product companies, and end users. One big challenge in Drupal is getting those end users, the companies actually using Drupal, to contribute. Because they’re the ones feeling the friction.

TDT [5]: At GitLab, we focus on getting as close to the end user as possible. If they’re experiencing a problem, we want to work backwards from that pain point and invite them to help solve it. I believe that’s what the Co-Create Program aims to do: bring the end users into the process. Could you explain the Co-Create Program in more detail?

Nick Veenhof: Sure. The idea behind Co-Create is pretty simple. In the open-source world, we know you can make changes to software. But if you're not familiar with open source, you may not realize that. Most people are used to just consuming software. So, how do you go from being a consumer to becoming a contributor? That’s the gap we’re trying to bridge. Here’s how it works in practice: we agree with a customer to run a week-long collaboration, kind of like a bootcamp or hackathon. We send a GitLab engineer to their office to work with them, side by side.

The goal is to get over the initial barrier and have at least one or two contributions merged by the end of the week. That’s a huge motivator. It gives them this feeling of, “I can do this.” And suddenly, their change is live and available to millions of users. That’s a powerful moment.

This is where I think Drupal has a challenge. Getting a change into Drupal core is difficult. And even after it’s accepted, it takes a long time before that change is deployed on a customer’s website.

If it’s not a module, but part of the core, it can take months or even years. That delay really weakens the excitement. It’s like studying hard for an exam and getting your results three years later. The emotional impact is gone by then. Exactly. But if you can show value quickly, by helping someone contribute and then getting that change into production in a matter of weeks, that’s extremely motivating.

Businesses, especially, want to be faster and more competitive. Open source has always had that advantage. In the past, you had to go through procurement, legal, and admin just to install some software. Now, with open source, a developer can download something and be up and running in minutes, even with Drupal.

But when it comes to contributing back, the timeline is much longer. That’s a problem. If we can reduce the time between proposing a change and seeing it live in production, we’re adding real value. And that’s one of the big challenges open source faces today.

TDT [6]: In contrast to the traditional open source contribution process—which, as you said, takes a lot of time, do you think GitLab’s Co-Create Program could represent the future of contributions in open source platforms?

Nick Veenhof: I wouldn’t say it’s the future, because GitLab is a bit of a special case. But then again, every open source project is unique. They all have different governance structures and ecosystems. GitLab is open core. Most of the maintainers are GitLab employees, and they’re paid to maintain the software. That already makes it very different from community-governed projects.

That said, I do believe there’s a future in improving and accelerating the timeline from proposing a change to getting it into production. If you can measure that timeline and reduce it, you’re delivering value to a lot of people.

TDT [7]: Coming back to GitLab’s Co-Create Program, do you have a standout example where this initiative led to significant improvement?

Nick Veenhof: Yes, absolutely. I’ll share two instances that describe public examples in detail. One case was with Thales, a large GitLab user. They worked with us to improve the empty project user interface, making it easier to start new projects. Another great example was with Scania, the automotive company. Scania uses Conan, which is kind of like Packagist in the PHP and Drupal world. They needed support for Conan version 2. It wasn’t on our immediate roadmap, but through Co-Create, we helped them get that support implemented and released.

They were thrilled. It not only gave them the features they needed but also a much deeper understanding of how GitLab works. Having a GitLab engineer sitting next to them helped them overcome the initial complexity. Comparing that to Drupal core, it can feel very intimidating for new contributors. There are people who’ve been involved for years. You start thinking, “Am I good enough to contribute here?” That can be a big mental block.

What we try to do is lower that barrier. Show contributors that, yes, they are good enough. And see, within a week, they’ve made a successful contribution. That kind of experience builds confidence. That assurance is key!

I think this happens at DrupalCon as well with the first-time contributor workshops, although I’m not sure of the exact name. But those happen maybe twice a year. It’s great, but it’s not enough. We need to find a way to keep that momentum going throughout the year. Lowering the entry barrier continuously is the real challenge.

TDT [8]: Moving on to your involvement with the Drupal community, you were a board member of the Drupal Association, and you’ve been chairing the Innovation Working Group. Can you speak a bit about your experience?

Nick Veenhof: Sure. I’m no longer a board member, but it was a great experience. It was fascinating to see the differences between open source ecosystems. When Drupal introduced the Innovation Pitch Contest, I found the idea really exciting, running a competition where people pitch their most innovative contribution ideas. I took that concept back to GitLab and tried to do something similar there. It met with some success.

There was a lot of cross-pollination. Some things that worked in GitLab I tried to bring into Drupal, and vice versa. One thing I helped with was the contribution dashboards. Alex Moreno built them, and I supported him in that effort. But what I learned from that experience is this: if we want to claim that we’re improving, we have to measure it. You need a baseline.

For example, if you can track how long it takes to go from proposing a change to seeing it live in production, and then reduce that time by 10 percent, that’s real progress. But without that data, you can’t say whether you’re innovating faster or not. That’s something I took from my time with the Innovation Working Group.

TDT [9]: So, being involved with both GitLab and Drupal, two very different open source communities, what, from your experience, are the core elements that make an open source community truly successful?

Nick Veenhof: People. It always comes down to people.

We’re all here trying to solve problems, and I think that’s part of human nature. The sense of belonging is also important. That’s why the Drupal tagline, “Come for the code, stay for the community,” rings so true. One important clarification though GitLab is not a community-driven project in the same way Drupal is. GitLab is an open core project with a strong community aspect, but it’s not governed by a foundation like Drupal is.

That difference really hit me when I joined GitLab. I had to understand what motivates people here.
People contribute to Drupal for different reasons than they do to GitLab. Understanding your community—who they are, what drives them, is essential.

This isn’t just true for open source. It’s true for any kind of community, whether it’s built around software, food, sneakers, or anything else. Some people contribute because they want recognition. Others are happy to do it for swag or even just for the sense of accomplishment. You have to know what makes your community tick.

TDT [10]: You've worked with countless contributors over the years. Do you have a personal story where a seemingly small contribution ended up having a major impact?

Nick Veenhof: Yes. There’s a quote from an open source advocate at Thales. He said it only took two months from starting a conversation with a GitLab engineer to seeing their contribution included in a GitLab release. There were just two people involved in that change, and what they improved ended up saving time for 30 million users.
The specific change was related to the interface for creating new projects. On paper, it doesn’t sound huge, but the impact was enormous. It shows how even a small contribution can scale to benefit millions. And that’s an incredibly motivating realization for a contributor.

TDT [11]: With GitLab’s Co-Create Program showing success, what are your future aspirations for it? Is there a next step you’re working toward?

Nick Veenhof: Yes, definitely.
One of the big challenges is sustaining engagement after that initial week. That one-week sprint is great, it helps people get over the first hurdle and make a contribution. But how do we make sure they continue contributing?
The long-term goal is to help them grow into regular contributors, maybe even core contributors. Ideally, they’ll also start mentoring others, and evangelize the value of contributing, not just to GitLab, but to all the open source projects they use.

We want them to see that contributing helps their business and accelerates their work. That’s what we’re aiming for next.