Since its inception GitLab has become the poster child for global collaboration on open source development. It now has more than 1,000 contributors worldwide. More than 100,000 organizations and millions of users are using GitLab, which now includes Mattermost in its omnibus installer as an open source Slack-alternative.
We wanted to share some highlight from his Q&A from running an open source company with over 160 staff:
What was your strategy to grow the GitLab team so fast?
Sid: Our development team has doubled over the past six months, so that was very rapid growth. We received a lot of inbound enquiries; in fact, we had roughly one thousand applicants per month. Our policy was, if we have a vacancy and somebody meets our criteria, we hire. So the strategy is simple: get lots of applicants and the money to pay them. What really helped was our public team handbook. Lots of people stated that was the reason they applied. And as far as the money is concerned, we raised $20 million in August.
So tell us, how do you compile your handbook? What motivates people to contribute?
Sid: This is a really big change. People are hesitant to write in the GitLab team handbook, so it has to be led from the top. Many times contributors send an email and I reply, “Document it in the handbook instead” – so often I sound like a broken record. After a while, team members who have been around longer started repeating this mantra themselves. Then for our team call, any announcements we make should be a link to what has changed in the team handbook. There’s no excuse for there not to be a link – but you just have to keep reminding. I am constantly looking for new ways to make improvements.
Since the open source community is spread across multiple time zones, do you have any tips on how to make asynchronous communication work?
Sid: Working remotely is not natural. The natural way for an organization to evolve is through meetings, but when this is not possible the natural alternative is chat, like we do with Mattermost. So you really have to keep hammering out the message, “That’s a great opinion. Can you please add that to the issue?” or “Can you please write that down?” Take a scheduling meeting: sometimes it is simply not possible to get the team together, which is often no big deal: what’s important about scheduling is the decisions that come out at the end, the milestones. Therefore, if you want to change something, leave a comment, or if it is urgent, send a message. That way you can still move forward even when you can’t get together.
A meeting is often the easiest option but not the smartest. Usually it makes more sense to write the first draft of a proposal. Anyone who cares about the topic will comment and those that don’t care won’t waste your time or theirs – so they can spend it on other stuff. I think being a remote company is actually better than being a hybrid, where some people are co-located, either physically or in the same time zone. For example, if you have team members on the US west coast and others in Europe, you can institutionalize a rule that says any meeting must be accessible to both. That way there’s only about one hour of overlap so you will have fewer and shorter meetings – but more productive ones.
It is nice to communicate instantly and non-verbally now and then, so video calls can be great. But only jump into a call when it is necessary to escalate or resolve an issue while eliminating all the back-and-forth. Regular scheduled calls make less sense.
In summary, treat remote working as an advantage, not an obstacle. In a physical meeting your most productive team players tend to get bored when the discussion does not directly affect them and that can come across as impolite. Whereas on a remote call they can generally listen out for the relevant discussions while getting on with other things.
In any case, you can always record meetings for people who can’t attend but don’t want to feel left out!
What is the key value that helps you guide your organization?
Sid: Transparency is very important and relevant to an open source organization that is scaling up rapidly like GitLab. As your company grows, your team is going to know things that the rest of the community doesn’t, so you have to ask yourself, how do we ensure that important announcements get communicated? Regular blog posts are one answer. Basically, anything that you tell the team should be public – i.e. available to the wider community – by default. Though of course, there will be exceptions, such as security or privacy, and you need to be clear about these.
Understandably, many new team members are nervous about sharing. So it is up to the more experienced members of the team to say, “Hey, this is great and it does not need to be confidential”. If you don’t do that you will cease to be an open source project.
You might even consider publishing your chat logs so that people can google them. That already happens with many open source projects.
How does GitLab structure community interactions? Do you have dedicated community managers or do you rely on community members to respond to each other?
Sid: First, the idea of “community managers” is a pet peeve of mine because it sounds like you’re managing the community when it should be the other way round. That’s why we have community advocates at GitLab. That said, I understand what you mean, how do you manage feature requests coming from the community?
We prefer to call them feature proposals, meaning contributors don’t even have to ask us. Anyone can make a proposal and at any time there are thousands of them in our repository for both the Community Edition and the Enterprise Edition. We then work it out in public; the discussion can go on for many months. If a customer makes a proposal, the sales executive will post it on their behalf and anonymize it, but with a sales force link enabling authorized employees to track progress on behalf of the customer. Once the proposal is up there, everyone is on an equal footing. Then, our product managers schedule milestones for specific feature proposals and have the final call on that decision.
Does that mean GitLab product managers schedule milestones for community contributors?
Sid: No, if community contributors post an issue we do not usually assign a milestone because we are not in charge of their schedules. When it’s done, we ship it. However we do have merge request coaches who will help to get community contributions over the finish line and merged into the master code – for example with testing, documentation or security compliance. For the last release we had roughly 50 such merge requests so it’s going very well.
Do you see community contributions for issues that were in your own plans?
Sid: We don’t see that a lot. Certainly less than we might expect. I guess people follow the conversation and think, “I could do that but I will just wait and get it next month without having to do anything”. Which is fair enough, they can pick another feature where they can contribute – and there are infinite possibilities.
That’s the great thing about a public issue tracker. Contributors organize their own time and effort very efficiently, without the need for community managers!
More about Mattermost:
Mattermost is an open source Slack-alternative built for enterprise. Thousands of companies use Mattermost for workplace messaging across web, PC and phones with archiving, search, corporate directory integration and connectivity to over 700 third party applications. Available under MIT license in 11 languages Mattermost offers peace-of-mind, value, control, and freedom from lock-in for organizations around the world.
Install or Upgrade Mattermost
Mattermost Enterprise Edition E10 and E20 are commercial versions of Mattermost designed for large organizations backed by commercial support from Mattermost, Inc. and available by subscription. See the feature list for more detail.
Looking for help on install and upgrade? A subscription also entitles you to upgrade and installation help from Mattermost, Inc.