The Changelog: Software Development, Open Source - GitLab and Open Source (Interview)

Episode Date: September 13, 2013

Andrew and Adam talk with Sytse Sijbrandij, one of the Co-founders of GitLab, about building GitLab, sustaining open source, community management, and ways to handle a "road map" for your product or project.

Welcome back everyone. This is the change log where members support a blog podcast and weekly email that covers what's fresh and what's new in open source. You can check out the blog at the change. Dot com are past shows at five by five dot TV slash change log. And now you can subscribe to the change log weekly. It's our weekly email covering what's fresh and what's new and open source. We send them out every Saturday.

Subscribe at thechangelog.com slash weekly. This show is hosted by myself, Adam Stachowiak. I almost said Andrew Thorpe. And also Andrew Thorpe. Say hello, man. Hey, how's it going? It's a good day, man. And this is episode 103, man.

It is a good day, man. And this is episode 103, man. It is a good day, yes. It's good stuff. We're joined by Cisse, C-Bron-D, C-Bron-D? Sorry about that, Cisse. He's the co-founder of GitLab with Dimitri, so they've got a fun thing going on over there. They just versioned to 6.0, so Cisse, welcome to the show, my friend. Thank you, no problem. Honored to be on the show. And Andrew, congratulations on your birthday, C.J., welcome to the show, my friend. Thank you. No problem. Honored to be on the show. And, Andrew, congratulations on your birthday, man. Thanks.

You can virtually wish Andrew a happy birthday because today, Thursday, I think this will air on Friday, but you'll be in the future. But today's his birthday. Good stuff. Big day. And before we kick off the show, I want to pay some homage to our sponsor, DigitalOcean. Super awesome cloud hosting server, so cloud hosting provider. DigitalOcean is a simple cloud hosting provider dedicated to offering the most intuitive and easy way to spin up a cloud server. Users can create a cloud server in 55 seconds which is super quick and pricing starts

at five bucks only for a half a gig of ram 20 gigs of ssd drive space one cpu and one terabyte of transfer which is pretty awesome for five bucks they feature 99 actually it's 99.9 correction uptime sla onLA on their services. They have data centers here in the U.S., in New York, in San Francisco, as well as in Europe, not very far from CSA, in Amsterdam. So pretty neat. Their interface they have to manage it all is intuitive. It's super fast, and power users can actually replicate it on a larger scale because they have an awesome API to go with it. DigitalOcean uses KVM virtualization and additionally hosts a library of helpful walkthroughs and tutorials that cover server config and optimization, so it's pretty easy to get your services set up. We have a pretty awesome promo with them,

$10 off. So when you sign up, you enter your credit card information on the billing page. There's a promo code filled there. Go ahead and pop in our coupon code, changelog. That's not the changelog. It's just changelog to use our $10 off promo. So thanks so much to DigitalO move to their services. Kelly, you know, his service, get Portly. Yeah, Portly, yeah. He's been using Linode, and I think one thing that was pretty enticing about DigitalOcean for him was the fact they have private IPs now, so he was like, oh, that's nice. Plus it's on SSD, so it's super fast too. Yeah, he likes Linode, but I think that he always kind of knew

that it was good to get started with, and he was going to have to migrate eventually. So DigitalOcean loves it. I think it's always kind of knew that it was good to get started with and he was going to have to migrate eventually. So DigitalOcean loves it. I think it's a pretty good move. Oh, yeah. DigitalOcean's – one thing I've heard about it is like it's just fast because it's SSD. But anyways, let's get this – It's really neat.

We use it to – GitLab is hosted partly on another provider, but all the new servers are on DigitalOcean. We're really happy with them. Is that right? Nice. It's neat that they're sponsoring the show too, of course. Double sponsor. Yeah, double. Double sponsor.

Yeah, well, we don't get a discount, I guess, but it's an amazing price and value anyway. Oh, yeah. Yeah. And the $5, I mean, they're basic plans. So we get $10 off. It's basically two months free. You know, the easy way to say that. I mean, that's a super extended promo for DigitalOcean,

but we certainly appreciate the support of the show. But that's cool that you guys are using them too. But let's get off the show. Andrew, you want to take the lead, my friend? Yeah, yeah. So, C.J., why don't you kind of go ahead and give us – so we mentioned it before, but we had a little sponsor. So you're with GitLab.

So why don't you kind of give us an intro, the history – or why don't you start with what GitLab is? Why don't we go there? GitLab is a code and project management system. So you manage your Git repositories in there. There's an issue tracker. there's a wiki system you can manage users and all kinds of permissions and the whole goal is to collaborate as software developers to do code reviews to communicate stuff to work together more efficiently and to do a continuous delivery of your software supported by this management in

gitlab so obviously that makes go ahead no does that make sense yeah it does and obviously for anyone that's listening that is familiar with it um i'm sure you have to answer the question with how you guys relate to github and and other you know those providers bitbucket and those guys so we'll get into that a little bit later on in the show. So basically GitLab is just – do you only support Git or do you support other version control systems too? No, we're Git only. Obviously some people use it with SVN things, but there's no support in GitLab for that. Gotcha. Why don't you go ahead and give us a little bit of a history?

I think you guys are starting to gain some real traction, but you've been around for quite a while. You're definitely not a brand new service, so there's some history behind you guys. So why don't you kind of give us a little peek into that? Sure. GitLab was created in September 2011 by Dimitri Zarapovets and Valerie Seesoff. Dimitri continued with the project and is still the lead author, and he's a co-founder of me. A year after Dimitri made the project, I started GitLab.com to also offer commercial services around GitLab. But then GitLab was already out for a year and it already gained some traction, mostly from people who want to run their own hosting service. So on-premises within their company, the organization, they want to be in control of their own repos and access and backups.

And GitLab enables them to do so. A big step in the development of GitLab, in my view, was version 5.0 when we got rid of all the dependencies on Githo Lite, which is an awesome piece of software, but it allowed GitLab to scale a lot better and to support many thousands of users on one installation. And it's been open source the whole time. It's MIT licensed, and we got an awesome community around in contributing and helping people out.

I guess you mentioned being 5.0 is the last milestone. You said kind of a shift for you, but you recently celebrated 6.0. I think it was about like a week or two back, week and a half back? Yeah, it came out on the 22th of the month of previous month. Since 2011, it's always come out on that date. So you can expect a new major or minor release on the 22th of each month. So that's something the whole community is always looking forward to. 6.0 was also a major release.

We added lots of awesome features. Most importantly, the ability to combine groups of people and groups of projects. So you can now have a group where you have a couple of developers in. And then if you add projects to that group, all the developers get their authorizations on the project automatically and vice versa. And this makes managing bigger enterprise installations a lot easier, but also

for smaller companies like 50 people or 20 people or five people, it's nice to be able to group projects and access. And among, of course, there were many, many other changes and improvements as well. But this was the biggest one in the 6.0 release. So the Enterprise Edition is new in the 6.0 release, is that right? Yes, we also introduced Enterprise version. The difference from the Community Edition is that it has support for LDAP groups. So normal GitLab can sync to your company LDAP server for permissions and authorizations. But this can also sync with your LDAP groups. So everyone who is in your company LDAP server can also gain access to a certain group in GitLab.

It's more a feature for bigger organizations with more than 50 users. And this version is only available to subscribers of GitLab.com. So that's our business model. We make two books a month for every user that is using an enterprise edition. So with that, we've become a sustainable company. And we were really glad it was positively received in the community.

And we're trying to build on that to grow as a company and do even more improvements to GitLab. The GitLab though – sorry, Andrew. I wanted to make this point because the Enterprise Edition though is only available to subscribers of GitLab.com though, right? So like you got the community edition, which you mentioned is open source and GitLab EE or enterprise edition is subscriber based. Is that right? Exactly. Okay. So you announced 6.0 on August 22nd.

And since then you've had a few weeks now. So you kind of said that the reception has been pretty good with the enterprise edition. But what does that mean? How, how has the reception been, you know, specifically?

We got a major increase in the number of subscribers, people who wanted to new features, but also people who saw like, we were really serious about it and that it's becoming a sustainable company. people who saw like we were really serious about it and that it's becoming a sustainable company there were already lots of organizations using GitLab over 25,000 is our estimate and now all kinds of organizations came to us and said okay we'd like the enterprise version or we'd like to support so we didn't have like multiple companies signing up every day before, and now we have that. And it was starting to gain major traction around the release.

Some of the features in 6.0 were made in discussions with some major enterprises, and we now have like three Fortune 100 companies being paying customers of GitLab.com. So that was a major milestone for us, signing up these big companies and working with them to make GitLab even better. You kind of alluded in a conversation we had that there was quite a bit of discussion that actually went around the licensing of the Enterprise Edition. Yes.

Obviously, making two versions is a major step, and you can do it the wrong way or the right way. And obviously, what Oracle is doing to MySQL is not the way we wanted to do it. And we thought the best thing would be just to talk to our community about it, what our plans were and how we were going to do it. So on GitLab.org, about a month before the release, we said, okay, these are our plans and this is how we're going to do it. And then all the hard questions came about how you're going to license it, and that was a main point. And obviously, we were thinking about a commercial license. All the extra code would be

commercial code, and you couldn't copy it, etc. And some of the people in the community said, well, why don't you just put your faith in the community and just make it open source? That's what we all believe in. And people are going to be okay, like the GitLab community is pretty awesome, and nobody's going to be mean and redistributed. Why should they? If we're being a good member of the community, we can expect the rest of the community to be cool. So that was a pretty convincing argument. So we MIT licensed the Enterprise Edition, which I think is pretty unusual for enterprise software.

You see it sometimes in smaller plugins and everything, but this is a bit of an experiment. And so far, it's going really well and a very positive response to it. So I'm proud that together with the community, we could do this. And you saw it when we released 6.0 that there was no – everybody was happy about it, how we approached it and the end result. So feeling really good about the discussion we had, especially with a user called Bean in the pre-announcement. Let me ask a question here because there's some – I was reading some of the comments on your 6.0 release and then the link out to your Enterprise Edition. And Andrew, this kind of keys off of something we asked Mike Parham when he was on about Sidekick and Sidekick Pro,

which is like, and the question that I'm going to ask is basically from one of the comments here is like, if the community develops your EE LDAP groups feature and they want to push that into the CE edition, I think you eventually had kind of a response to, but it was pretty much just it would be appreciated. So what was your official stance on like, it seemed like there's some sort of divide there between the editions,

even though you were graceful and offered it as MIT. Yeah, obviously that's a hard question to answer. So what happens if somebody contributes a feature to the community edition that is already in the enterprise edition? Would we merge that? I think the first question we're going to ask ourselves is why do people want this? Are we, because we promised that any features we put in only the enterprise edition would be features that would be mainly useful for larger organizations. And the fact that someone is contributing it to the community edition kind of indicates that maybe we're wrong. Maybe this feature is really useful for smaller organizations because we have pretty affordable pricing.

So if you're in a large organization, you should have no trouble convincing the management of actually purchasing a subscription. So why is this happening? That will be the first question. And we might be mistaken. We might think about a feature that's only for large ones,

but it's also good for smaller organizations. In that case, we're wrong and we'll just merge that code or enterprise code into the community edition. If that's not the case, I think it's what would be important is the seriousness. Some of these features are non-trivial to make. Is the code that is contributed, is that of a high quality? Did someone take it really serious to try to add this feature? Or is it just like, hey, I saw that this feature is missing and I tried to whip something up, but it's not that functional. So if someone is serious, that makes it more likely that we'll include it. Obviously, if the code was directly nicked from the Enterprise Edition, that would be legal, but that would not be very cool. Yeah. It seems like one of your answers is like that I was just reading through is that some features can be kind of bottled up into – because somebody suggested a plug-in system and then kind of making it where these enterprise features could be bottled up in plug-ins and just kind of added on through some sort of subscription that you've already mentioned.

But that some of them are just kind of bigger interfaces to the application that it's just not easy to bottle up into a plugin. Yeah, there might be – we have services, we call them, but they kind of function like plugins. So we might have some enterprise things that we'll be able to package as a service. That would be neat. I like what, for example, Vagrant is doing in this regard where their VMware plugin is paid and the rest of Vagrant is open source. But some of these features would have to build a whole special interface into the community edition just to be able to build on top of that. And what we don't want to end up is with a worse community edition because we want to build on top.

That shouldn't be the goal. So it's not always feasible to abstract something as a plugin. So we'll do it if it's easy, but we're not going to complicate the code base too much. With Git, it's very easy to just keep two separate versions

in existence. So we'll rather do that It's very easy to just keep two separate versions in existence. So we'll rather do that than build all kinds of extra non-functional stuff that everyone has to maintain. So speaking about the code base, and again, I want to kind of get into this a little bit, but I'm sure you answer this question a lot or kind of have conversations about about this a lot but git lab itself is hosted on github so why don't you kind of give a little bit of a insight into that decision and if if that's going to be a long-term solution or if you eventually would move git lab over to git lab or you know whatever you would say to that yeah um we're we're trying to be really pragmatic about everything. So pragmatic that sometimes it hurts. So if it's about making something an awesome new feature that people can use or building something just to serve our pride, then we built an awesome feature that people can use. So the thing is we haven't gotten around to making public repositories. So on a GitLab server, everything is private. And for most people running a GitLab server, this is why they're running GitLab

because they want unlimited private repositories. So most of the people are really happy with that. And building, we want to, we're not against public repositories. So we're accepting merge requests for that. But it would be a big change. You have all kinds of problems, like you don't no longer have a current user. So lots of code needs to be adapted. and we want to do it in the right way so that all the security tests and everything, it doesn't become brittle. So we haven't gotten around to it.

If somebody contributes it, well, a really good code will merge it. If there's a customer that really insists on it, we'll do it. But so far, everyone's really happy with the private stuff. But I think it's a question of time because there are people right now building Fedora

packages. There are people building Debian packages. There is discussion on the Drupal mailing list about using GitLab. So the pressure is on to start supporting public repos. So I think it's a question of time. But yeah, we're trying to be pragmatic about that. Does that make sense? Yeah. So basically right now, just to kind of summarize and make sure I understand this correctly, right now, just because GitLab is itself open source and maybe gitlab.com the cloud is not the best solution for an open source project right now because there are no public repositories but eventually if that happens you would consider moving gitlab itself into gitlab to be hosted there yeah exactly and we might have open open public repositories even before we move.

So we're just going to stay where the people are. And right now, GitHub is where the contributors are. So we're not going to force anything on anyone. Just to be more proud. Our pride is in building something that people can use and that's stable and that's affordable and that's that's open and free and and that that's our pride and yeah if we have to host somewhere else that's that's that's really fit for the purpose then that's okay yeah and that's a really cool attitude i think you know you kind of speak about the pride

thing and i think that's something that in open source a lot of times kind of takes over. And, you know, some projects, not all, I mean, thankfully not most, but, you know, there are some projects that seems like the maintainers of the project are very proud. And it's their way. It's what they want to do, not what the community wants. And that's kind of anti-open source. So it's really cool to see, you know, that at a company level, you guys are all saying, you know, it's not about our pride. It's about delivering what people want. And I think that's really cool. Have you kind of received any attention from GitHub itself, the company or any of the team members about this?

No, we haven't. I think that maybe it's a matter of time before you would hear something as you guys continue to grow. I mean you guys are getting very big, over 10,000 stars on GitHub. So the scope of this project seems to be exploding, and it's real fun to watch it. I'm sure they are aware of us. Yeah, definitely. I did want to – So I was just going to point out their, their URL.

So while the listeners are listening and maybe go hang out there, it's github.com slash GitLab HQ. Yeah. And there's lots of stuff more, you know,

GitLab, a lot of you guys that contribute back to the open source community a lot in areas other than just on GitLab. And that's cool, right? So what other, what other projects have you guys contributed back to the community

besides just GitLab.com? Besides the GitLab thing, the other main project is GitLab CI. So it's a very basic continuous integration server. I think the cool thing about it is that it's really user-friendly, so it's very easy to set up your projects. You don't have to set up new user accounts or new permissions. It communicates with GitLab over the API, and it gets your existing projects, and you can set up a new project in under a minute. And the other thing that's really cool about it is that it's distributed by nature. So your tests do not run on the CI server.

They can run somewhere else. And this is the default setup. So what we commonly see with people, they set up a CI server, but the tests run on the server. So any project that runs on the server can access the whole CI server. And that's a bit of a security concern. And also maintenance and everything is complicated. And GitLab CI is distributed by nature. And I think that's really cool. If you want to know more, you should check out the architecture, GitLab's architecture blog post.

Awesome. So GitLab Git is a... So kind of to go back, I read an article from one of the founders of GitHub about grit and how it kind of... I don't remember if it was Tom, but one of them was talking about how they just were in a bar one night,

sat down, decided to start writing the Git bindings for Ruby. And so Grit came about. You guys have written a wrapper around that called GitLab Git. And can you elaborate on what that is and why you decided to do that and how you chose to kind of use that architecture? I think it's a pretty minimal wrapper. It's because the grid project is a bit, well, there are lots of pull requests waiting to be merged in the grid project.

And I think that's why we have our own fork of the project. The thing that we built on that with a thing called GitLab Shell, maybe that goes a bit too far now, but it's more of a fork with some additional fixes and things that we need than a replacement. So, yeah, we're really grateful for the Grid project that was contributed by GitHub. Yeah, just to add some numbers to the mix here for those listening, I'm assuming this is the canonical repo, which is Tom Preston Warner's username on GitHub, which is Majumbo. That's

Majumbo, right? Yeah. Slash Grid grid and there's 63 pull requests uh waiting to be merged i think without throwing stones what do you think the reasons why there's so many pull requests waiting is it just that they're they're opinionated and maybe these pull requests don't really represent where they want to take grit no i'm not sure i'm not yeah you'd have to ask him okay yeah it's a hard it's a hard question to answer. The oldest pull request is from three years ago. So you would think that some kind of action would have happened on that pull request by now, but they got their reasons and why things are happening. Yeah, I'm not trying to throw stones.

I'm just trying to see. Because you said one of the reasons why you did GitLab Git was that because of those being stacked up and obviously you had some motivation and inertia of where you wanted to take it, so some vision for what Git could be. So you had to essentially, you know, fork from where it was at and wrap around it and do some other things in addition to it. So it sounds like, you know, just you can't wait for other community members to move if you're trying to move ahead of they are, you know, ahead of where they're at.

Yeah, and on the same time, we know how hard open source is, and keeping up with the issue tracker is really hard. And you cannot expect the same people who write software to always keep maintaining it and investigating everything and our git lab grid is mostly for stuff we need so we're not trying to to be a better project or something like that we're just trying to merge in stuff that we need yeah solve your own problems i think that's the problem i make was like is it you know what's the is it solving your own problems or is it, you know, I don't know, just easy question to answer. Well, it's kind of moving. It's solving our own problems. And I think one thing infrastructure-wise that we did try to contribute that has some pretty unique functionality is GitLab API, so it's a bit specific, but it's code that allows you to host an SSH session and to have people download the code and clone the code and push the code. So basically what Gitolite is doing with Perl, this is doing with Ruby code in a nutshell. And I think that's a pretty neat

piece of work and it might be a good reference for other people trying to do this. So Githo Lite is what you guys were using and that's what you said you replaced at GitLab 5.0 and that was with GitLab Shell. Is that right? Yes, exactly. Okay. Awesome. Well, you kind of talked about this a little bit. I wanted to maybe shift gears a little bit. One of the things that we've kind of hit on a little bit now is, and I've said a little bit, quite a few in those sentences. A little bit. A little bit, a little bit. One of the things that we've talked about a small amount in the last couple of minutes is building commercial company

around open source. And you talked about, you just mentioned something about issue trackers and how they can be hard to kind of keep up with as one core maintainer. So at GitLab, you guys have a specific team of two people dedicated to the issues. Is that right? Can you talk about that? Yeah, there are two people, but they're not part of GitLab.com. They're part of the community. So I want to shout out to Ben Bodemiller and Robert Schilling. They're doing an awesome job on keeping the issue tracker as clean as possible. So trying to help people there, trying to close duplicate questions,

and they're doing that in their spare time. And we really appreciate it. It's one of the most important things in open source. And we're really grateful if people step in to help out on the issue tracker. And I think that that comes from a mindset of, and you guys have it, which is when you're very open to the community and what the community desires, I think your community that your specific community that comes up around you is open to giving back. And I think with Ben and Robert that are obviously committing, I mean, the one thing that you don't, you know, you can't buy more of his time, right? You've heard that before. And so they're taking more of their time from whatever

their regular jobs are to commit back to GitLab. And that's something that you get from a mindset of being open to the community. And when you're truly open to what the community wants and willing to kind of shift in the direction that the community wants to take you, I think you kind of can gain a lot of the joys of the community. Would you agree with that? Yeah, but I think the community is doing a way better job than we are.

I'd like to hang out a lot more on the campfire rooms and everything to help the community. So we're not doing as good of a job as we could doing that. We had some help from Yves Sen, who is also working on the Rails core, and he helped us set up campfire rooms and help coach some people to become better contributors and better issue team maintainers. So, yeah, we just have awesome people in the community. It's not because of us, but because of the community that it's going so well. Yeah. So what's it like building a commercial? You said that you've recently become sustainable. Is that right? Yeah. With the introduction of GitLab Enterprise Edition, we've become a sustainable company.

And before that, we took on consulting assignments to make ends meet. And you're going to be working full-time at the end of the month on GitLab. Is that right? Yes. I'm finishing up the last consulting work and I can't wait to start working full-time at the end of the month on GitLab. Is that right? Yes. I'm finishing up the last consulting work, and I can't wait to start working full-time. I think that's an important point to camp out on. I know we talked a little bit about some comments we heard back from those on the announcement of GitLab 6.0 and then also the Enterprise Edition, just like asking questions of why fork it or why have this divide or why have these separate options.

And I think, you know, maybe you can say this on your own, but I think generally speaking, to be sustainable, you know, at some point you have to be able to sustain yourself through money and not do additional consulting and focus fully on GitLab. So that seems to be the answer to the question, which is that's why you've done it, to be sustainable. Yeah, we've done it to be sustainable. And because we saw there was a lot of demand for features that only larger companies would use. And like there's, we had already for half a year, GitLab.com hired Dimitri as a co-founder to work on GitLab full-time.

And he's working on all these awesome features. But, yeah, the money has to come from somewhere. And we need to, yeah, having a paid product is a great way to make ends meet. And I think there are also other things like donations. We did that as well, and we're really happy with all the people who donated. We also had a software-as-a-service product. So for some people, that might be the best way to generate income, but we thought this was the best way for GitLab.com.

Yeah, it's something we talk about a lot on the show because, you know, unfortunately, if you get a pizza delivered to your house, you can't pay it with contributions, right? You have to have money to pay bills. So we talk about, you know... Well, let me respond to that. Dimitri called it ice cream money when he started. But we had some very, very generous contributions come in. We had companies donate $1,000, $600, like pretty big amounts. So it's not that the community is not willing to pay up.

Oh, when I say contributions, I meant like to the code itself, like commits. Oh, yeah. Oh, yeah, sure. I was confusing it with donations. Yeah, no, no, no. Well, that's the point is, you know, you can't pay your bills with code, right? You have to somehow make money, whether it's through donations or, you know, some sort of a business model or something. And so we talk about a lot on the show, different business models that people have. And this is one, I don't know, I mean, maybe I'm just making this up, but I have nothing to back this.

But it seems like this type of a business model where you have like your open source product and then you kind of extend it for like an enterprise edition or a paid version or something like that this is kind of growing in popularity and it seems that this model is growing in popularity specifically when your target um you know your your target customer is a developer right because i think developers understand that this stuff isn't free that the people that are doing this still have lives, they have families and bills and all this and that. And so the, I think that it's a, it's a model that is lent to be successful because, you know, myself, like I'm more than willing to give money to a project that I rely on to get my job done because I know that this, this guy has to do his job. And the only way he can keep going is if

he makes money and if he can't keep going, then I don't have this project anymore to work with. Does that make sense? Yeah, absolutely. Yeah, totally. And what also comes into play is that many times the benefactor of the open source project is a company. And in a company, it's really normal to pay for software. It's not so normal to do a donation. Yeah. So for a lot of people who wanted to donate, it was much easier if we just said it was for software. But yeah, we can only do that if it really is for software.

So that's also why it's good to have a commercial offering. So let me ask you this. So GitLab itself is open source, and you guys are kind of reaching out to companies to start using this. Have you gotten any flack from companies that may be a little more old-fashioned that aren't comfortable with the fact that your software is open source? No, we haven't. But maybe that's because we're not reaching out that much. I think the whole community around GitLab is doing the promotion and just we have enthusiasts and champions within companies

that started using GitLab. So it's a great fit for their organization. And they reach out to us. Maybe when we become more active in doing outbound sales that we get that reaction. But most people are really comfortable with open source. And, yeah, people see, I think, the benefit of having more eyes on the product. Right. product. And maybe they like that there's a commercial company that has a lead developer that is inspecting every last line of code that comes into the project. Maybe that

helps, but we haven't had any negative reactions to GitLab being open source. And it's again, you have the community kind of, or the clients are coming to you. You mentioned to me that GitLab is actually looking to hire, and some of the roles you're looking to hire for are support to you. You mentioned to me that GitLab is actually looking to hire and some of the roles you're looking to hire for are support and sales. So do you, you said this already, but you could see that happening a little bit if you're starting to reach out and do outbound sales. And what is your response to that? If that starts to happen, if somebody says, I like what you guys are doing. I like that it's all private but i don't

like that the code itself is open source do you say they're not a good fit for you or how would you handle that oh i would ask why they say that like what is their concern are they concerned about security or about copyrights or what is their concern about people inserting backdoors and and all these questions i I think, have different answers. And I think they all have a good answer. But yeah, it will be about a specific concern. Do you want me to go into the concerns? No, no.

I just wonder if you guys have put any thought into that as a company. And the only reason I bring it up is because you say you are looking to hire sales, which I think is unique. I think that unique. I think that companies that are open source with an enterprise edition don't often do much outbound selling. I think that's a unique thing that you guys are going to do. So I wonder if you guys have had those conversations at all and if those questions come up or you hire a salesperson, are you going to want to train that salesperson on these questions and stuff like that?

Yeah, I think we'll see what we get for questions and then we'll start answering them and making notes. I think the sales vacancy we have at the moment is going to be inbound. So just keeping up with all the requests that are coming in and making sure people have all the information and following up on all the questions they asked and all the wishes they have. So we're hiring for that and we're hiring for support, making sure that you help people with their environment, setting everything up, making sure the backups are OK and doing high availability configurations. So right now we're hiring for that. And outbound sales, that's still in the future. We just have trouble keeping up with the growth we're currently having.

So although I'd like to do even more sales, let's first – we're still doing a great job at servicing our customers, but we need to hire in the very near future. So if you're interested, please let us know because we need you to grow further and keep doing a good job. So on that note then, what are some of the biggest challenges you face then? I mean, so if you – is it manpower? Is it – we just talked about you becoming sustainable with the Enterprise Edition. What is the biggest challenge you face right now? Yeah, good people are always the challenge. And I think we've been able to hire some amazing people because they like being in open source. but for example getting a person that wants to do inbound sales

and is enthusiastic about that that are not the people who come into contact with open source projects so I think that maybe we should do some more marketing and PR in non-developer channels

some outbound sales to get some inbound sales people yes but Non-developer channels. Some outbound sales to get some inbound sales people. Yes. But, yeah, it's a very positive problem to have. So that's okay. And I don't – yeah, so far no major problems. It's just keeping up with all the extra demand after we announce the Enterprise Edition. That's right now the focus for the next few weeks.

Yeah. So you can look at GitLab's jobs at gitlab.com slash jobs. Let's shift from where we're at now with GitLab to what we can expect coming up. I know that you said that you guys don't have like a big roadmap, so we'll talk about that in a second, but specifically for 6.1, what is going to come out with this release? We have three big features coming out. The first thing is issue referencing. So when you commit in Git, you can write a commit message. You can say something like fixes number 27, which means fixes my issue number 27. And all these kind of comments and links are all detected by GitLab

and the appropriate comments are closed. And we normally work with feature branches, which means that if you're going to solve a ticket, you're going to make a new feature branch for it. And then when you accept this feature branch, there's a big, nice green button that says accept. And then right on top of there, it will say, well, this will fix issue this and this and that. And it got that from the commit message you did earlier.

Fancy stuff like that is now possible. The other thing that was a popular demand for, we call them pseudo API calls, which means that as an administrator, you can do API calls and you can do them as another user. So, for example, if you need to comment or move someone's project, you can do it as that user so that you don't have any weird users showing up in the history of stuff. And the third major thing is project-specific IDs. Like now, if you open an issue for a project, it gets a global ID. So suppose you have on your entire GitLab installation, you have 100 issues, it gets number 101, while on the project, you just have 10 issues.

So it's not really logical that it's then number 101 when you have only 10 issues. So it's not really logical that it's then number 101 when you have only 10 issues. So we're going to fix that and make sure you have project specific IDs and merge request IDs. So every project starts at issue one. Exactly. Gotcha. Awesome. So that's coming out for 6.1. I think it's interesting that you guys have no – and you kept – when we talked, you kept talking about we have no roadmap. We have no big audacious goal or no big private plan of where we're going. So that kind of means that your sight and your vision is very close to what you're working on right now. I want you to talk about that.

I don't know if that was a decision or if you guys just naturally kind of organically grew into that, but why don't you guys have some big roadmap? Why don't you have a long-term plan? We used to have this roadmap file in the repo, but it wasn't maintained any longer, so we deprecated it. And we found that normally when a release is almost done, so most of the time it's a few days before the 22nd, Dimitri kind of knows what he wants to work on. The community knows what they want to work on. But you just figure it out then, right there and then. So you're done, the stress is gone, and you think, oh, I'd like to work on this or that.

Or I heard so many people complain about this or that. And these things, you cannot predict them two weeks or a month in advance. Sometimes you can, but sometimes you can't. And we want to be working on the things that inspire us and that are important to the community and to the clients of GitLab.com. So why work on something less important just because you said so a month ago so we don't want to end up in that situation and i think david heinemeyer henson said very eloquently when he said inspiration is perishable if you're inspired by something just go work on that and we try to keep that alive. conversation we're having today. You might be inspired by something we suggest or part of the conversation that reminds you of something. You're not going to want to wait

two months to go and work on that. You're going to want to take care of it at that moment because it'll perish. Exactly. And if it's important, it will come back. And last but not least, many, many new awesome features such as the pseudo

API calls, they're contributed by people. So we couldn't have predicted that. That comes up, and at a certain point, they're ready, and we can merge them, and then they're in the next release. So it's useless to try to predict a community. We just have to go with their flow. Yeah, I think that this is something that I think about a lot.

Working as a developer full-time, it's incredibly, I don't know if the right word, but stressful to think about long-term. In six months, we're going to want to do this feature. And to me, when we, we started and Adam knows, like, I think he could probably laugh because he actually, when he, when he starts talking about features that are like more than today's work, he says, Andrew's going to kill me for bringing this up. But, you know, it's funny because I think as developers, we do like to be inspired and work on what is current and what is currently important. Right. So it's, it's like, I is current and what is currently important, right?

So it's like I want to know what I'm working on right now so I can, you know, my thoughts and my brain cycles are not unlimited and I want to be able to devote it to what's important. And when I have to spend a ton of time thinking about, you know, does this match the roadmap? Does this match the six-month plan? That's just overwhelming, right? It's stressful and I don't think it really, I don't, how often do companies actually stick to their roadmap? And so when you have the open source community that's very, I don't know, active with your project, I feel like a roadmap would lock you into something that maybe wouldn't be the best idea. All the energy you spend on the roadmap, it's wasted.

So you'd have, before feature branches, you'd have people at companies who are called release managers. Like most companies still have them. If you do software as a service product, you don't need a release manager. You can do continuous delivery

and you can just deliver the features as they are completed. There's no need to do a release. There's no need for Git flow. Please use feature branches and just release what's ready. And you can, the release manager can do something else and be productive. And no one has to stress out or fight about which features get in which release, which is not adding anything. So, yeah, I feel really strongly about this,

as you maybe noticed, and I'm really glad we're able to practice what we preach. What were you going to say, Adam? I was just going to say on the idea of roadmaps, something that I heard from somebody pretty respected, actually from 37 Signals. A while back, I had Ryan Singer on a different show I hosted for a while called the Industry Radio Show. And it clicked when he had mentioned this thing, this idea, because he's a product manager at 37 Signals. So he tries to know where they might want to go, but he doesn't let that

impact how he works today. And I kind of lament on how he said it in his trajectory, like knowing where you want to end up potentially, but being able to kind of deviate along the path, along the way, you know, based on this perishable resource called inspiration or, you know, feedback from the community or whatever, but you kind of have an idea where you want to go. It's not exactly a roadmap. It's like an idea of where you might want to be i kind of think of it like that well i mean yeah if gitlab for instance like gitlab is not going to switch from doing you know like version control hosting to you know playing music right like they they there's no roadmap they they know in in a year they there's some things that they know, right?

They still want to be a company, so that's a given. They want to still be doing Git. But what they don't know is what if the community comes up and starts saying, like, we really, really want support for X, whatever that feature is. Well, that feature could be a huge thing, a small thing, whatever, but as long as they have the mindset that they're being flexible and they're willing to, you know, go in that direction, then that could drastically change the roadmap, right? So if there was a roadmap, it could be altered greatly if you have a flexible mindset. And I think that's what's

scary is if you are roadmap driven and you're not willing to move drastically away from that roadmap, I guess there is two extremes, right? You could be kind of chasing every little rabbit trail of every little potential feature, but when you think of it that way, those rabbit trails tend to be bigger features. You have your core product, and your core product, it doesn't change that much. It can change your, in the feature set, but as long as you're, you're not chasing down, you know, core rabbit trails where your core changes drastically. I don't think you want that roadmap. I don't think you want to know where you want to be at,

maybe where you would like to be at business wise, but to sit down and say, I mean, how, I think that we all can understand and all can admit that if you try and sit down and talk about features and where you want your feature set to be in 12 months, that you're not going to accurately estimate or predict what's going to happen. That's the exact person I was going to say. You're not going to accurately depict the future like that. It's going to be a rough estimate. Yeah, totally with you on that one for sure. Yeah, and I think that the problem is a lot of companies invest a lot of time trying to figure out how they can accurately predict 12 months down the road. And it's like –

Why? The sooner that you can embrace the fact that you can't predict 12 months down the road, the more that you can realize that you're wasting time and money on trying and you can invest that time and money into what's happening right now. And that's important. Yeah, I totally agree. And great quote of Ryan as a product manager. I think what you're trying to do, if you're making a roadmap, you're drawing roads on a piece of paper that doesn't have a map. It doesn't list the terrain you're in.

So you're drawing this path you will take, but you're not taking into account the terrain because the terrain, like it's hard to see how much effort stuff will be or what's important or what's the weather going to be. So you don't want to draw exactly which path you'll take. You need a direction, like we're going northeast, because that's our goal.

And then you'll figure out how to get there and which streams to cross and which route to take along the way. And you know your direction. And we also know our direction. We want to polish GitLab CI a bit more because right now it's a bit rough around the edges. We want to package GitLab better because right now you have to install it by hand.

We have a really good installation manual, but still, if we make it easier to install, then more people would install it, which would be awesome. So these are things you know, okay, this is the direction we want to go, but we'll see how we get there. Right. And what tomorrow brings, and we'll just look up, look around, and see what pull requests

are coming in from people. Gotcha. So what's on the roadmap for? It's cool. No, I think that that's a man. It's almost like you could do a whole nother talk, a whole nother, not even just talk a whole nother show about, you know, I don't know if procedure is the right word, but, but, you know, what's the solution, right? I mean, you, you kind of talked about knowing the direction you want to head.

Well, how do you know the direction you want to head? How can you accurately talk about a direction without talking about goals? And I think that there's something there. And whoever can figure it out and bottle it up, I think you'll become a bajillionaire on figuring that out because there's obviously been companies that have been – I mean, that's what release managers do. That's what, you know, that's what these people do. And so there've been companies that have been investing tons of money and time into trying to be able to figure this out. And I think if you can figure it out and figure out not just, you know, it's not just figure out what I want to do in 12 months, but it's figure out how can I get us going in a direction and maintain the mindset that we're going to be flexible.

But at the same time, I don't want to jump ship on this value because it hasn't panned out in the first two weeks. So I need to give it its due diligence, right? So if you can figure all that out, then more power to you and bottle it up and sell it and then hire me at your company to just collect a paycheck. Yeah, it's really good. Product managers are really, really valuable. I think at GitLab, we just talk within the company, but also with the community, and we just see where we're going. And we're driven by Dimitri's dream to give awesome tools to developers.

And I think that the mission is a bit expanding into just collaboration in general. I think Git is an awesome tool to collaborate and to be flexible. Like people used to send an email with an attachment and then you edit something and you send it back and they send it to three other people and now they have a problem. And these things are going away and version management is going to solve it. But it's really hard to do it in a user-friendly way. space about working together on code, but also on technical documents, legal documents, and eventually everything that's digital will be version controlled. And people are starting to figure that out.

But I think it will be as important as web servers, these collaboration servers. And I think there should be a really good free one that everyone can use in Freedom. And that's how I see GitLab. Dimitri might say something else and we have to figure that out as we go along and listen to our users and to the people in the community. Yeah. So it's been two years and you guys are at 6.0.

Would you say that you put out another major release? in the community. Yeah. So it's been two years and you guys are at 6.0. Do you, would you say that you put out another major release? You know, you bump the version in a major number every four months or so. Is that,

has that proven to be pretty accurate? Yeah, that's pretty accurate. Cool. So we can expect to see 7.0 coming out in the next three or, three months or so. That's exciting. Christmas.

Yeah, it'd be Christmas present, huh? That would be nice, yeah. All right, so I think that we could – there's plenty more we could talk about, but we do try and keep the show under an hour or to an hour. I think we're about reaching that point now. We ask our guests the same questions at the end of every show, and so I'll go ahead and ask you now. See, I didn't prep you with these, so don't kill me for putting you on the spot with these.

But our first question is, and I'm drawing a blank right now on what the question is. Call to arms. Call to arms, yeah. So first question, for the community, you guys obviously have a very active community, so I'm not sure that there's anything specific. But what would be something that you would like to see the community kind of rally around and work on? Or even better way to put it is, is there a feature, specific feature that you think is missing from GitLab that you would like to see somebody kind of get involved with? Well, if I'd have to do a call to arms, I would say help people out using GitLab. So there are IRC channels, there's an issue tracker, there's a mailing list, and people are asking loads of questions, trying to figure out the problem, trying to see how they have

to configure something. If you want to help GitLab, please help out these people. The community is doing an awesome job helping these people, but there is a lot of room for further improvements. There's room for better answers. Just pick your favorite medium, if it's Stack Overflow or an RSC channel,

but help out these people with GitLab questions. That will be my call to arms. And of course, yeah, if you need an awesome feature yourself, please make it and contribute it. But there's no need to go around looking for something to make. Make something you want. Don't make something somebody else wants. That's the most important thing.

So you're inspired to do a good job and you know what you want. That's good advice, yeah. What about – so if you weren't doing what you're doing now and I ask that question, let's say assuming it's a month from now and you're working on GitLab full-time. And if you weren't doing that, what would you like to be doing instead? I would like to learn JavaScript and play with Node. I listened to your episode with Isaac, the RPM maintainer, yeah, that sounds awesome. I'd like to know more about that and play with it. I'm a Ruby developer.

I love Ruby, but it would be good to learn a second language in a good way. So I'd do that. Awesome. And our last question is a programming hero or somebody that you have been influenced by greatly in your life that you would like to give a shout out to. I want to shout out to Yehuda Katz. He's core on Merb, Rails, jQuery, Ember, making Skylight application, but also making a Tokaido application and that is to help people install Ruby on Rails easily on their Macs and it's just amazing how

much he has given to open source and I don't believe he's actually one person there must be three more in a basement somewhere. Many Yehudas. Yeah, many Yehudas. It's just amazing what he has done. And I greatly respect that. And we cannot stand even near him compared to our contributions. I think it's really awesome that there are people like him.

And he's a great inspiration to me personally. I'm always inspired by some of his tweets where he's like, hey, I'm hacking on this. Anybody got any – anybody that knows something about this? Like he's still humble even though, like as you said, you don't deserve to stand next to him compared to contribution. I think he's a pretty humble person. And speaking of Yehuda as your hero, Andrew, are we still in talks about getting him on to talk about the latest Ember release and whatnot in a couple weeks? Yeah, we're still trying to work it out. But hopefully in the next few weeks we'll be talking with him about Ember. And yeah, it'll be a good one.

Yeah, it's good stuff. Well, we definitely appreciate'd be a good one. That's good stuff. Well, yeah, uh, definitely, um, appreciate you coming on the show. See, it's a, I mean, the, the work you guys are doing. Thanks for having me. Yeah, absolutely. I mean, the work you guys are doing is, is really inspiring. Um, definitely the way you're leading the community and listening to the needs of the community is, is super inspiring. So, uh, appreciate you coming on the show.

I want to give another shout-out to our sponsor, DigitalOcean. Definitely cool that you guys actually use them, for one, and two, that they're sponsoring the show because it helps us sustain. So, I mean, that's what helps us make sure that Andrew and I can show up here every week and talk to people, like Zeed said, about what they're working on and give shout-outs to people like Yehze about what they're working on and give shout outs to people like Yehuda and others on the work they're doing. So you can go to digitalocean.com and plug in our coupon code CHEESELOG to get $10 off your subscription.

So do that whenever you feel like. But to the listeners, thanks for tuning in. We'll be back next week. That's kind of a neat show. we'll put something in the email so if you're not subscribing to uh the changelog week that you've got to go to the changelog.com slash weekly it's where we're putting uh our updates as well as tons and tons of other stuff that hits our radar that we don't always have time to hit uh hit up on the blog so definitely definitely a huge Saturday read. And that's pretty much it. So let's say goodbye, guys.

Thanks so much again, man. Goodbye. Thanks for having me. Awesome that you're doing this show on open source. Great work. Thank you. Thank you. We'll see you, everyone, next week.

Later. Later. Later. later later you