Gitlab leads by example with their passion for creating open source collaboration tools, with the ability to do everything on code. As part of our Open Source Leader podcast series, we interviewed Sytse Sijbranij, CEO of GitLab, to learn how they maintain their open source community and what will be next for their tools.
Below is a sample of the topics we covered :
- Why Gitlab?
- Who should use it?
- What is the relationship between Gitlab and Github?
- Where is the best place to run Gitlab?
- How does the Gitlab community work?
- Where is is Gitlab going next?
Stuart Langridge: This is the Binami Open Source Leaders Series of Interviews. I’m Stuart Langridge, and I’m talking to Sytse Sijbranij of GitLab.
Sytse Sijbranij: Hi Stuart thanks for having us.
Stuart Langridge: No problem. So Sytse, you’re CEO and co-founder of GitLab, yes?
Sytse Sijbranij: Yes. That’s correct.
Stuart Langridge: So tell us, what is GitLab?
Sytse Sijbranij: GitLab is open source software to collaborate on code. It means you can download a package, install it, and you’ll have version control, issue management, code reviews, a wiki, all ready to run within your organization.
Stuart Langridge: So you could think of this essentially like a self-hosted version of GitHub, yes?
Sytse Sijbranij: Exactly.
Stuart Langridge: Since we mentioned GitHub, the elephant in the room. Obviously there’s a big advantage in that I’m running it inside my organization, so it’s private if I want it to be. If you look at this field there are an awful lot of different packaging attempts at this, both hosted, something like GitHub or LaunchPad. Talk about why GitLab’s better than the competition, what you do really well, and why people would want to go with you.
Sytse Sijbranij: A few things we do really well is that you get a lot of possibilities to modify it as you see fit. With some of the other competitor’s products, you get a black box virtual machine that you don’t even have proper access to. At GitLab, you can use it anyway you like with nginx or with Apache. We’re the only product in the whole marketplace, commercial or non-commercial, that you can actually run in a clustered configuration with multiple application servers. GitLab is really complete. It is all about integration; integration with other issue trackers such as Jira and Redmine. It’s just a very polished product compared to a lot of other open source projects that are out there. It really contains everything you need. We really listen to the community and our clients, and there are a lot of features that enterprises find handy in GitLab. For example, not only do we have public and private projects, but we also have internal projects; projects that are visible only to people who are logged in.
Stuart Langridge: Even within the organization, you can lock off certain projects to certain development teams and so on?
Sytse Sijbranij: Sure, that’s a feature in many projects, but these internal projects are visible to anybody who has a login. Imagine as an organization, most of your projects are only for internal use, but you’ll have some public projects that you released out to the public and have them contributing back. Within the company you probably want to collaborate on most projects, but you have to first be added to a project before you can see it, and that’s a hindrance compared to the open source workflow. This is not a problem if you’re with five people or ten people, but it starts becoming a problem if you’re with 50,000 people which some of the organizations running GitLab are. Now you can say this is an internal project, and everybody in the organization can see it and can try to contribute back. With this, you get the open source workflow within this large company. It’s also called inner sourcing, working with an open source workflow within a large organization.
Stuart Langridge: You spoke about large organizations using GitLab. Are you targeting particular types of organizations or companies? Give us a sense of the sorts of people who are running GitLab now and the sorts of people who you’d like to be running GitLab in the future.
Sytse Sijbranij: We’d like everybody to be running GitLab, so we’re not targeting anything specific. I cannot talk about some of our largest and most impressive, but some of the companies running GitLab are Redhat, Electronic Arts, NASA, Comcast, IBM, SpaceX, NASA, Qualcomm, SOHO, AT&T, but also universities, such as Michigan State University, University of Texas at Austin. Also non-profits such as Interpol, the police agency, International Center for Missing and Exploited Children. It’s really all over the world. In advertising, publishers are running it, but also in research, the Fraunhofer Institute is running it. We like that diverse of a group, it’s great for GitLab to be everywhere.
Stuart Langridge: What about if I’ve got a small development team? Is there a size of organization, a size of project below which it’s not worth running GitLab, or will it be suitable if I basically have one small internal project and only a couple of developers?
Sytse Sijbranij: Yeah, for sure it’s suitable then. Of course your logo won’t end up on our homepage, but many people run it with a really small organization. They just start a Digital Ocean server, and they get up and running within a few minutes. People even run it for themselves on their own server back at home, for their own projects. They use GitLab to have a visual overview of all the repositories as a kind of remote backup. They use the code review things to review their own changes. So they run it on a home server or even on a raspberry pi.
Stuart Langridge: GitLab is obviously set up so we can be scaled out to as large as you want. How does that scaling story work technically? If you’re using Bitnami for example, to deploy into EC2 or Rackspace or something like that, how are you set up to scale GitLab to the size that you need it to be?
Sytse Sijbranij: If you just provision a decent Amazon server, let’s say C1 medium, you can size it up to thousands and thousands of users. For years, GitLab commerce has offered a service with more than 10,000 people, which has been running on a single Amazon server. So you can scale on the single server for a very long time, and we do strongly recommend that. If you want to scale out on Amazon, you could have one file server. You’d attach an EBS drive of one terabyte, use that as an NFS server, and then have a couple of application servers in front with an elastic low balancer and use Amazon RDS with PostgreSQL or MySQL to store the database. One limit on Amazon is the one terabyte limit for EBS drives. So we have experience with striping across a couple of those volumes with LVM, so you can scale to multi-terabyte setups.
Stuart Langridge: Obviously in order to set up that kind of environment, you need quite a lot of technical knowledge. What would you consider to be the level of technical knowledge to run GitLab - not necessarily in a very complicated, multiple-striped, multiple cloud deployment - just internally in my organization? Is it something where you’d need a very competent system administrator? Is it something that can be set up and left to run relatively easily?
Sytse Sijbranij: I think it can be set up and run relatively easily, and I think the Bitnami packages are a good example of that. People just set it up and those keep running. There are also a lot of other options to install GitLab. What we focused on is making it very easy to install even if you download a package that installs in two minutes. It doesn’t require any rails knowledge, none whatsoever, and then you’re still able to upgrade with a single command. We’ve really focused on installing and upgrading over the year last year, and that’s become so easy. As long as you’re comfortable with the command prompt on a UNIX server then you can do it, and with Bitnami it’s even easier.
Stuart Langridge: If you think about your large, diverse user base, do you get a sense that most of them are deploying on hardware inside their own company or are most people deploying into the cloud, digital ocean servers, or is it quite evenly balanced between all those different ways?
Sytse Sijbranij: Yes, quite balanced. Some people like digital ocean. For a small team that will be a common way to start. If you’re an individual probably your home server. If you’re a larger organization, sometimes they have hardware at their sites. Sometimes they have hardware and data centers, or sometimes they have a private cloud. People, even if they’re comfortable with the cloud, still want their own GitLab installation. They don’t want to use a SaaS, because they want to inspect the code, be able to modify the code, customize the installation to fit their preferences, connect it to an LDAP server hosted behind their VPN, and run their logging and intrusion monitoring software on it, so there are lots of reasons to run it in the cloud but still run it on a server that you control.
Stuart Langridge: GitLab is itself hosted on GitHub, so we’re obviously happy to work with existing SaaS solutions, but obviously again there are benefits to running your own stuff in house. There’s quite a divergence between strongly open source bits of software, and a proprietary commercial SaaS alternative which might have the features you want, but you can’t inspect the code. Talk about how GitLab is trying to find a balance there.
Sytse Sijbranij: We try to be really pragmatic about these choices. That’s one of the reasons that we still have a repository on GitHub, and the reason is that many people have GitHub accounts. We don’t want to miss out on contributors who want to contribute via that channel. I do want to mention that the canonical source of GitLab is available on gitlab.com, so that’s where you find the real version, but what is the real version in a world of distributed version control. So we’re quite pragmatic. If people are comfortable contributing from a certain platform, we don’t want to deny them the opportunity. We want to make software that works. It’s open source, but it’s not GPL-licensed. It’s MIT, so anybody can do anything they want with it, and we believe that’s real freedom for people and companies. They don’t have to be worried about anything. We want it to be a very polished product that you can use without any problems. We spend a lot of time fixing all the small things such as fixing the UI or having good documentation. That’s why we need income as a company so we’ve created a version of GitLab that’s called the Enterprise version that focuses on organizations with 100 people or more using GitLab. It offers some extra features, and it’s how we generate revenue and also grow as a company.
Stuart Langridge: That makes sense. GitLab is primarily web-driven, yes? You use the web interface to get everything. What are your policies on things like supporting modern browsers, on working well on people’s mobiles, or using responsive designs? Are you using the latest cutting edge HTML for that and cutting off older browsers, or does it work all the way back down to Lynx?
Sytse Sijbranij: No, it’s web-driven of course. SSH connections are supported, but you mainly interface with it via web browser. We do have strong support for mobile. For example, everything is tested on iPad before it ships, so the whole user interface works very nicely there. We do support the latest version of Chrome, Firefox, Safari 7+, Opera, and Internet Explorer 10+. We expect developers to have relatively recent browsers and also if they have a mobile phone that it has a substantial screen area, but we definitely want to support a mobile. We’re on the latest bootstrap, and we’re on the latest Java script frameworks so that people can have good experience there.
Stuart Langridge: What’s the GitLab release strategy? How often do you put out new versions and what’s the cadence of that?
Sytse Sijbranij:
Stuart Langridge: How do upgrades work? Do I just SSH into my server and do git pull, or is there some kind of managed upgrade service?
Sytse Sijbranij: Yeah it can be like that. If you installed it by hand, you can do the git pull, and look at the instructions for what else you should change. We also have an upgrade script, so you don’t have to type as many lines. Many people nowadays use the packages and that means you’re downloading the package and just do an opt install, and that manages the whole rest of it.
Stuart Langridge: So you’re providing Debs or RPMs?
Sytse Sijbranij: Exactly, debs and RPMs for CentOS, Redhat, Debian and Ubuntu for multiple versions. We make those for Omnibus, which is a very interesting piece of technology from Opscode, and they allow us to make a package that has everything, that not only has the rails components but also all the gems, all the rails assets precompiled, and all the native compilation for the rails gems. Also Nginx, Postgres, Unicorn, everything you need to run a GitLab server. It prevents a lot of problems and it makes things a lot easier, especially upgrades.
Stuart Langridge: I love the idea of people having little parties when you do a release. So that leads us on to talking about the GitLab community. Obviously you’ve got a contributor community, but you’ve also got a user community. How much do they overlap and what’s going on there? If I’m a GitLab user, if I’m using it in my organization, would I want to get involved in the community and what would I get from that?
Sytse Sijbranij: Certainly it’s up to you if you want to get involved. I think the vast majority use GitLab and are very happy using it and that’s great. We love our users. You don’t have to contribute anything back. But it might be fun to explore, and most other people start offering small suggestions. They have a feature request they’d like to see. They contribute to our feature request tracker, and sometimes they find a piece of text or some small thing that’s broken and they contribute it back, and that’s how they get going. We have a core team of more than ten people, most of them not from GitLab BV, but just the rest of the community. We also have some people out on the issue trackers that are called merge marshals, so they review all the merge requests that come in and help people get them, so they can be merged. More than 600 people have contributed to GitLab so far.
Stuart Langridge: Do you find the GitLab community, the GitLab user community are helping one another, or is it kind of hub and spoke where everyone talks to you and you help them out?
Sytse Sijbranij: No, it’s certainly people talking to one another. I’m very glad not everybody talks to me, because I wouldn’t have any time left. People find one another, and there’s some people who like to get in our chat room and are very active there. There are some people who manage IRC and there are all these different preferences, and people find one another there. There’s people on GitHub and GitLab talking about contributions. There are a lot of ways, and people are even making money with GitLab. There’s githost.io, where you can spin up a GitLab CI server, as a managed instant, which is a great service and it’s run by George. We just really welcome people also, not only doing volunteer work but also trying to make money with GitLab.
Stuart Langridge: If I’m looking to do something like this within my organization and I’m looking at GitLab and at the competitors, what sorts of questions should I be asking to help me decide between them?
Sytse Sijbranij: I think you should think about what kind of workflow you want. You should realize that the whole open source workflow is what we do. We’re doing merge requests, proposing code, and that’s what makes Git so powerful, so that’s why people have switched to Git. If you’re doing Git without having proper software, without doing code reviews, I think you’re doing it wrong and you want software that supports that. There are lots of things to look into, but I think that the advantage of the GitLab is that it's open source version is already very powerful, it’s not limited in any way. You can grow to an installation of many thousands of people and just run it without owing anybody anything. Although if you want commercial support or if you want the extra features, there’s also a company behind it that can support you, and most people find that GitLab is easy to install, has excellent documentation, and that if there are problems, they get fixed very, very fast.
Stuart Langridge: Where’s GitLab going next? What are your plans for the next six months, the next year, the next five years?
Sytse Sijbranij: We have some ideas, but we don’t really have a roadmap. We used to have a roadmap, but we didn’t like it because it’s always very easy to come up with what we should do this month because everybody’s saying the same thing. So two months ago, we heard from multiple channels that people were fed up with the issue labeling. You had issues, you had labels, you had callers, but they were impossible or hard to customize, so it was really clear that that needed to change so we spent some time on that, and it’s always like that. It’s really easy to decide what to do because somehow there’s a signal coming from multiple sites from the community. We don’t want to run ahead of ourselves and we don’t want to start thinking about what should be done in five months and start promising that. We don’t have a big master plan. For example, a year ago, everyone was complaining that upgrading was hard, so we fixed that with our omnibus installer, and I’m sure that for this release we’ve got it figured out. We have some ideas for the next release, and I’m sure by the time we do the next release, we’ll have ideas for the release after that. So we’re very roadmap-lite, and if we have any time left, we can always spend a little time on GitLab CI our continuous integration product.
Stuart Langridge: Is the continuous integration thing a separate project which happens to be from the same company, or are you seeing CI as being tightly integrated into GitLab as a whole?
Sytse Sijbranij: It’s a separate application, but you can only use it with GitLab. We found that with CI, one of the hurdles is to set everything up to add projects to it and to arrange for all the code cloning and authorizations. With GitLab CI, you can just login with your GitLab credentials, we’ll show you the list of projects on the server, and with one click you can create a CI project out of it and it will clone automatically. There’s very little to configure and we think that it’s unnecessary to convince people to actually start using CI because lots of companies don’t have all the projects in their CI server yet. So it’s bound to GitLab, but it’s a separate application and you can work on it separately. You can host on a different server, etcetera.
Stuart Langridge: That’s interesting that you talk there about the tight integration. One of the strengths of SaaS solutions in this kind of area is they have a very strong developer API because they’re up in the cloud, and you can’t fiddle with the code yourself. If you look at GitHub, BitBucket, or LaunchPad they have a strong developer API so you can build applications which talk to these things, web hooks for notifications when projects have changed and so on. Does GitLab also have that detailed developer API, so I can build apps and scripts which integrate with GitLab?
Sytse Sijbranij: Sure. The APIs that GitLab CI uses are all public and there are CI tools like Macnew CI that even have explicit support for GitLab.
Stuart Langridge: That makes perfect sense. Where do people go if they want to find out more about GitLab the project and the product?
Sytse Sijbranij: Just Google GitLab and you’ll probably see our site about.gitlab.com, and you can read more there. There’s a video on the bottom of the home page that has a few examples, and get into the documentation.
Stuart Langridge: Excellent, so thank you very much for talking to us.