Sytse Sijbrandij, co-founder and CEO of git repository management solution GitLab, joins us on episode five of the podcast to cover everything from his early days building personal submarines to how GitLab has carved its own niche in a GitHub-enamoured world.
We also discuss pricing mistakes, how to decide whether a feature goes into the community or enterprise version, why ease of installation is key for open-source projects, how to license your premium software offerings, how GitLab is becoming the version control system for the web and more.
Alexis: Thanks, Sytse, for joining us on the podcast.
Sytse: Thanks for having me, Alexis.
Alexis: You know, I’d like to say that this is the earliest time that I’ve recorded the podcast, at eight in the morning Pacific Time, so you have me bright and early in the morning.
Sytse: Very good.
Alexis: But we have you in the afternoon all the way from the Netherlands, correct?
Sytse: Correct. This is where GitLab is headquartered, but we’re all over the place really.
Alexis: So, before we get into distributed team in GitLab, tell me a little bit about yourself before GitLab came into the picture.
Sytse: Before GitLab, I studied Management Science at one point and after that I got the chance to go into IT, but I opted for something else. I saw a submersible on a trade fair. I figured that would be cool. So for five years I made submarines.
Sytse: It was awesome. I was the first employee, and it grew into an awesome business. I visited one half week ago, it’s now a 28-person company. They’re the largest builder of recreational submarines. So think three to five people in as submarine, it goes three hundred meters to a thousand meters deep.
Alexis: Wow! You were living The Life Aquatic.
Sytse: Yeah, it’s awesome. It’s part James Bond and a lot of really rich people in awesome boats to put the vessels on. I’m not sure whether it’s a proper way to make money building these things but…
Alexis: It’s certainly fun.
Sytse: It was a lot of fun, yes.
Alexis: So, how did you make the jump from building submersibles for millionaires and billionaires to software?
Sytse: I always liked tech and programming. But I’m a bit of a lazy bastard, so I didn’t really like the work that came with programming. So when I saw the Ruby programming language in 2007, I thought, “Wow, finally programming gets fun. This is awesome. You can make something with Rails in just a few hours.” So then I switched, I started learning how to program, I became a Rails developer basically, and I was enjoying it ever since.
Alexis: Okay. So, when did GitLab come into the picture?
Sytse: In two thousand twelve I saw this project, I was one year old, GitLab, it was awesome, I always thought it was very logical, that as a programmer, almost all my tools are open-source and freely available, and I thought that version control was a logical thing to also be freely available.
So when I saw it, it immediately clicked and made sense, and I thought why isn’t somebody promoting this? I looked at the code base, it was really clean. It was exactly as a, how a rails project should be. So I was very enthusiastic about the quality. I thought, “Now what can I do? What can I do to help people introduce… to introduce them to GitLab?”
So I set up GitLab.com to offer SaaS, where people could experience GitLab without paying anything, without installing everything, just really easy way to get familiar with it. And I sent an email off to Dmitriy, the author that started a year before, thanking him for the project and saying what I was doing.
Alexis: So for people who are now listening to the Podcast are thinking GitLab, GitHub, what’s the difference here?
Sytse: GitLab is an open-source software. Most people run it on premises so they either have their own server at Digital Ocean — Digital Ocean has templates where you can install GitLab in under a minute — or they run It on company server somewhere. And people tend to run on premises because it gives them more control. If you’re a big company, you can integrate it with your LDAP, with your VPN, with all your other software. It’s also very affordable.
You can run as many private repositories as you have, as many collaborators as you wish. And the nice thing about it, it’s open source. So it’s freely available. You can inspect the code, you can modify it, you can set and change the sub-stream and that’s making it a lot more popular. Lots of people are familiar with it and already over six hundred people have contributed to it.
Alexis: So, in two thousand twelve, there’s, you know, GitHub was an attraction, GitBucket was as well. Where was GitLab in this picture? Did it have a lot of users and support at the time or did you really think this was a place for it to grow. Because, I figure, most folks looking from the outside in would think this is going to go up against GitHub in some ways, at least. We know it’s completely different in terms of the whole private offering, because you offered the control. But, you know, what made you… “Bah, forget GitHub. I’m going to do this on my own.” What was the landscape like?
Sytse: The landscape was that GitLab was already very feature rich and very well structured, so the code base lent itself to contributions so it was getting a lot of traction from development-wise. Promotion-wise, I saw some things that I wanted to improve. I wanted to give it a proper website, make it very easy for people to get started with it. I think I’m still top contributor to GitLab, not code-wise, but just having a proper read-me, having proper website documentation. That stuff I really find really important.
And then after a while, we found out that all these companies were also using GitLab and having so many questions and things they wanted to improve, so we also opened up to services. So we started selling these subscriptions where you would get support from us. And it was really demand driven. Companies were emailing Dmitriy. He didn’t know what to do with it. He started forwarding these emails to me and I started replying and seeing what they wanted.
Alexis: Very cool. So you didn’t really have to do much marketing in the beginning, did you?
Sytse: It was very demand driven. But of course you need to make sure that you have a proper website, that you listen in on Twitter, that you’re actively tweeting, that you have a newsletter etcetera, etcetera. But you have to start simple. When I started, I didn’t even have, I didn’t know Dmitriy, so I just started this software service offering, and I thought about making it, and I immediately thought I shouldn’t first build it. I should first ask if people actually want it. So I did a reverse launch. I first asked on Hacker News whether people wanted GitLab as a service. Because I was wondering if everybody was content with what is already on the market? Or, is there space here? Is there energy here?
And I vividly remember starting to make pancakes and checking my phone and at a certain point on the Hacker News homepage I just started replying. I asked my girlfriend to finish the pancakes and the other things. We brought it up to my room because I was just frantically replying on Hacker News why this was a good idea or not. And just talking with people, in the end, after the twenty four hours were finished, there were more than three hundred people that signed up for the beta. It was just a single page where sign up for the beta here. That was it.
Alexis: So what did you learn from doing that on Hacker News? Besides that clearly there was a demand.
Sytse: Yes, that was the most important thing. There was demand, and I should just get started. So after that I just started installing a server and slowly invited everyone to the server and trying to keep it on line while the people streamed in.
Alexis: So, what is your monetization strategy?
Sytse: The initial idea was to make money with the software as a service thing. Because the software can stay open source but you make money on the dot com basically. That was harder than I thought. Because the core value in GitLab is that you can run it on your own terms. That’s why people are attracted to it. So, before we even had the chance to start monetizing it, companies were approaching us for help and support, we thought, hey, there’s an obvious demand here. And people were asking us for all kinds of paid features on GitLab dot com. So we figured it would be easier to start helping these companies.
So we started offering I called licenses or subscriptions, and we just put a number on it. Of course the initial numbers you put on it is way too low in hindsight, we made that mistake. And we started supporting these companies. These companies have all these demands. They were using it in production with thousands of users. So they had all these ideas and demands. And we started adding them to the project.
Alexis: So, that’s now part of the whole, “If you have a feature idea, let us know, we’ll give you a price and if you want to develop pay us and we’ll break it in?”
Sytse: Exactly. We were doing a lot of paid development that way, but we also have some customers, from really large ones which got a subscription and we felt in the beginning that we couldn’t ask them for paid development, so we were making all these features for them for free.
Then, at a certain point we felt like these features are only useful for larger companies, for companies that have more than a thousand users, maybe it’s good to make a paid version and monetize that way. Because software monetization skills are a lot better than doing paid features or paid services.
So we were considering that and we started to have a discussion with the community whether we should make this commercial version because obviously there’s a danger in there if you have a commercial version, will open-source version still get enough attention. This was the big worry in the rest of the community.
Alexis: So, in the end, you wound up making the enterprise edition MIT- licensed just like the community edition. Can you walk me down that road, how you came to that decision?
Sytse: Sure. Basically we had a big discussion. We put an article on line saying “This is our plan to make this enterprise edition and the reason is, because we want, we need the resources to proper release management, proper regression testing.” It takes more money. And the community was very supportive of this idea. But everybody was trying to find ways to guarantee that the paid version wouldn’t overtake the open-source version. There was this one user his online name was Bean. He was proposing all kinds of stuff. And also this.
He had a few proposals, but this was, why don’t you also the enterprise version, why don’t you also make the MIT-licensed version, freely licensed? But offer it to download to the customers that are already paying. I thought was a really clever idea. My initial thought was a ridiculous idea, but that was just me.
Luckily I was on a boat, I was sailing somewhere, so I couldn’t reply right away, I had to think about it. I tried to come up with a reply. In the end I couldn’t. Then I found out it was a pretty awesome idea.
So we took that suggestion and we made the enterprise edition, MIT-licensed which alleviated a lot of worries that hovered. Because now if we would only add cool new features to the enterprise edition, at least people will be able to fork that code base and take it left or right way.
Sytse: Later on we discovered that having your commercial version also MIT-licensed, it was very confusing to all our paying customers. So we were fielding a lot of questions. Imagine we have open-source software that enables you to use open-source methods to write close-source software because that’s what a lot of our customers do, and then our commercial proprietary version is open source license. It didn’t click.
So later on, we changed the licensed back, of course not on the existing code, but on any new code, back to proprietary. But at this point the community had seen that we were really, really serious about advancing the open-source version, by the time the open-source version was already a lot better then, by the time we first announced the proprietary version and people have begun to trust that we wouldn’t only focus on the proprietary version, and they also saw the acceleration that this gave also to the open-source version.
We’ve made a lot of improvements especially around updating and installing GitLab and those were possible because of the extra revenues. So now it’s a lot less controversial and we changed the licensed back in something that our customers would expect.
Alexis: So was there any initial backlash? Was it mostly understanding?
Sytse: No, when we first announced the idea, we mostly communicated to the community and there was a lot of discussion of which good ideas came on the initial announcements of the proprietary version there wasn’t a single negative comment, so that was really good.
And also I think when we announced that we changed the license back, I don’t remember exactly, but I also think not a single negative comment. Yes, if you explain things well, you first are open to ideas before you announce something that helps a lot.
Alexis: So you mentioned some big names are using GitLab, for example Electronic Arts, AT&T, NASA, O’Reily, you’ve got a huge amount of titans using this, but the next webinarticle in June that said you’re building the business with just 0.1% of paying customers. I don’t know how that compares to other open-source projects that have a commercial component to them, but did you ever think doing that with commercial open-source is possible?
Sytse: The popularity of GitLab has been overwhelming. So, we didn’t, we’re never about what ratio of organizations is paying or something like that. We just want to make GitLab the standard infrastructure everywhere to do version management and let people build solutions on top of it.
It’s been awesome to see that more that hundred thousand organizations are using the open-source version. And we think that as long as we deliver great product, in the end, all that mind share will also lead to paying subscribers.
Alexis: So, where are you in terms of sustainability? Have you guys broken even or are you making gains, and how long did that take to get you that point?
Sytse: We have periods in which we are breaking even and we are always finding our ways to spend money mostly by expanding and trying to make an even better product. So we’re hiring again.
And now we’re hiring support staff in North America or at least that time zone. Because we want to help our clients even better, we already have twenty four seven support, but right now it’s more convenient for us to do it with more people in that time zone.
Yes, we always find new stuff and new things you want to expand on, so we are about break even the whole time. Sometimes making a little money, sometimes losing a bit of money but we’re trying to bootstrap ourselves so we just look into our bank accounts and figure out what’s the maximum we can do.
Alexis: Alright, I don’t foresee that you’re going to move on to another project anytime soon. You can correct me if I am wrong. But if you were, or somebody wanted to know what kind of business model, or changes to a business model would be best to support themselves with a commercial open-source kind of set-up, what would you tell them?
Sytse: For us, our model works really well but you have to be careful that what you make is something that a lot of people want. You need immense skill. If you have a product where you have a smaller niche, then you need to convert a higher percentage of customers. You have to think. You have to be a lot more disciplined about which features do put in the open-source version and which ones do I put in the proprietary version and how do I still ensure that the open-source version is not cripple-ware, that it can stand on its own.
That’s a very difficult decision to make. It’s one that you want to make engaging with the rest of the community, both the open-source volunteers and the paying customers. The customers will tell you what new features they want and mostly that’s, hopefully your open-source version is already usable, so that’s fertile ground for finding new ideas to add to the proprietary version.
Alexis: So you mentioned the community quite a few times, I’m curious how you interact with them. Do you use forums? Do you use email lists? Or just, I guess issue tracking?
Sytse: Yes, all of the above. One very important channel is Twitter. But we also have a mailing list. Some people ask questions on spec overflow. There’s a feature request for them which is used very heavily. Some features, we were not able to make them yet, but we marked them what we call “accepting merge requests,” which means we’d like to have this feature, please contribute it. If you contribute it, you’re sure that we’ll give priority to merging in that feature. We have a very good contribution guide, I think it’s one of the most extensive ones in the business. We have an IRC channel, somebody from the community Jonathan Hatty wrote a book. There’s a guitar chat room. YouTube channels.
Alexis: Wow! You guys are everywhere.
Sytse: Documentation site with automated documentation and of course the issue trackers, those are both on GitLab dot com and GitHub dot com.
Alexis: Speaking of issues, how do you handle that? Do you have folks on the staff that are dedicated to knocking those out?
Sytse: Unfortunately, not. So we have to rely on volunteers. They’re volunteers on the issue track who try to help people. But it’s not that you always get an answer very quickly. The more work you put in your issue, the more likely that somebody will respond to it.
Alexis: Before the enterprise edition really came in and started to increase revenue and all that, you were also doing consulting work, right?
Sytse: That’s right, I was full time Ruby on Rails developer and architect, and yes, I did consulting work to sustain the company in the beginning. In the beginning I was doing full time consulting in order to enable Dmitriy to focus on GitLab fulltime.
Alexis: And was that consulting under the GitLab banner or was it under a side project of your own making?
Sytse: No. Yes. It was somebody else’s project. I was just work for hire.
Alexis: Well, right. But, I mean were you doing under the GitLab name? Like, “Yes, my name is Sytse and I’m going to– GitLab is going to develop this for you.” Or did you, were you doing it on a personal basis?
Sytse: That was still on a personal basis.
Sytse: But of course, I can recommend anybody to try to get to your networking under your company banner as soon as possible especially projects that are, if not directly related to the software you’re making, at least somewhat related, somewhat in the same scene. Also it’s somehow, it’s really fun seeing your, the people you work for using your products, even if it’s on the side lines.
Alexis: The question was really to ask the second one, since you guys are doing a lot of training and custom feature development and consulting in that, how do you manage what you focus on in terms of adding new features and doing all these consulting work? How do you split your time?
Sytse: It’s really hard. First of all the products should be secure. So, security, security. We have a responsible disclosure program that goes above anything else. After that our incidents at customers, if they have a question or just stuck, or they have a problem installing something or configuring software, something does go first.
After that, you have the paid development for customers. So something that they requested, you gave a quote, you gave an estimate of when it will be finished, you want to hit that estimate and make sure it’s finished in the time they expect.
Sytse: After that, you have room for new features. And then you want to balance stuff that you hear from the paying customers with stuff that’s from the community and sometimes there’s stuff that annoys you yourself, we’re using it every day and sometimes you’re just, for example, you weren’t able to change the colors of the labels in GitLab, it didn’t make any sense though. Luckily, Dmitriy, just fixed that.
Sometimes there’s something like that. A colleague of mine also just made the ability to view issues if you have a certain milestone attached, if it’s the same milestone, you can view them across projects. So combine all your projects into one overview. It’s something that we needed ourselves and we hope all our people will useful this one.
Alexis: You scratch your own itch. I guess is how GitLab is born in the first place.
Sytse: Yes, exactly.
Alexis: I should note that you guys are also using GitHub to kind of develop this in public, but that’s partly because GitLab focuses on private repositories and doesn’t have public ones yet, right?
Sytse: That’s how it started, but we added those as well.
Alexis: So you did.
Sytse: Yes. You can use GitLab for public projects and also something that we call internal projects. Those are projects that are public to all the logged-in users.
Alexis: Interesting. Okay.
Sytse: Some of the larger organizations are doing something called inner sourcing, where within the company they treat all their softwares open-source.
Alexis: That, is pretty cool. Okay, they probably wouldn’t let me say, “Hey yes, I’d like to see what kind of inner sourcing projects NASA has,” but I could imagine that that would be pretty damn cool.
Sytse: Yes, I also think it’s cool. Of course, I also don’t get to see those projects. But, yes, we can sometimes dream about them and when you see a rocket, you kind of hope that your software is on it. And that it functions. But at least the software was developed on GitLab.
Yes, we also support GitHub that’s because not everyone in this world GitLab dot com account yet. So, we really want to be pragmatic. We don’t want to miss anybody contributing so we want it to be as easy as possible to contribute to the GitLab project.
Alexis: Now is that something you’d like to see, GitLab not just compete with GitHub in terms of internal version management, but in terms of public as well. Creating a community that GitHub has become famous for. Would that be something that you’d love to do? Or is it something that is on the back burner?
Sytse: It’s kind of on the back burner. We go where our community takes us. And right now, they’re really happy they’re are able to like public projects was a wish for a lot of people for a long time, so we thought long and hard about it and in the end we decided to add them.
Once the people have good option without having to maintain an installation, and they’re happy now too. And we see where the community takes us, but right now, lots of people are setting up their own server for various reasons, and that’s top of mind for us. But we’ll see where the community takes us.
Alexis: How big is your team right now?
Sytse: We now have six people. We now have vacancies for head of sales and for service engineer.
Alexis: Alright, that’s telegraphing where GitLab is going next. But how do you manage your distributed team? Was that a conscious decision to stay distributed or is it something that had to happen because the people you wanted just happened to live where they lived?
Sytse: A bit of both. Of course it started with Dmitriy who is living and is still living in the Ukraine, but I was also working with Maddin who is living in Serbia all the time, but after that we added a few people all in the Netherlands, it might have been possible to do an office but a few months ago, we talked about two thousand fifteen and what’s everybody’s hopes, and the number one thing that all the developers said is that I hope I’m still working from home. It gives me the freedom, the freedom to be with my girlfriend when she’s home, help people out.
Alexis: Make pancakes while things are on Hacker News.
Sytse: But yes, all our developers are really enjoying that. But I think we’ll end up having an office somewhere for the sales people and account managers. They like a bit more interaction. Maybe in San Francisco, maybe in Holland, we’ll see. But we’ll not end being a distributed company we all like it that way.
Alexis: How do you keep things organized? How do you manage what you’re going to tackle as a team for the week or for the month? When you’re all distributed and can’t kind of huddle together in one office?
Sytse: Yes, of course we use GitLab a lot. So, we use its issue tracking features, we have loads and loads of those and we’re crosslinking the merge request to the issues, crosslinking issues to one another using the milestones. We do have like a daily standup everyday so for half an hour, we mostly talk about what people did yesterday, during their off time, schedule conversations, talk a bit about stuff issues you think that should deserve more eyes on it. Or stuff you want to discuss in a larger setting. And maybe see who’s volunteering to help you out on certain stuff.
And we ask like “What’s your plan for the day?” But we try to keep this meeting really, really short, so people can go on with their business. But it’s nice to have a moment of time together. And during the day we started using Slack, with a general channel but also random channel where you can post this nice video you found or just comment on or just shout out about some crazy bug that won’t die something like that.
Alexis: You know lately, from the folks that we’ve interviewed, Slack seems to be the most popular, overcoming the HipChats, and the Campfires of the World.
Sytse: Yes, we find it really awesome. We didn’t mind, we were on Campfire before switching to HipChat for obvious reasons, not an option for us. However, we’re really glad that Slack came out with a great offering here.
Alexis: I have to ask, now that I’ve asked about your communication software obviously GitLab, is included in there, what do you use personally for your text editing.
Sytse: I’m trying to switch to them. But I’m still on sublime. Most of the time.
Alexis: Two or three?
Sytse: Sorry? Two or three? Three, yes, I upgraded. I have to pay licenses stuff. I love it. But I’ve seen that some people are just blindingly fast with VIM, and it works for them and it works on all the servers so that’s amazing. So, I’m trying to switch. I’m mostly editing documentation and read me’s and my VIM Fu is still very weak. I hope I’ll get there.
Alexis: Have you taken any investments or is this all totally bootstrapped? Which I think you may have mentioned earlier.
Sytse: Yes, it’s totally bootstrapped. I put in some of my personal money other than that we are paid by our customers which is awesome.
Alexis: Is there any interests in taking in investments? Or is that something you’d rather avoid? And if so, why?
Sytse: At this moment we are not fund raising. There’s some interest in giving us money.
Alexis: Can you imagine?
Sytse: Yes, obviously, it has drawbacks. And we’re not looking to do an exit in four or five years at this point. So, if you’re not willing to exit, you shouldn’t have the entry. For now, we’re keeping it like this. We’re talking also because lots of venture capitalists have pretty good ideas on how to grow our company. But for now, we are very happy in the position where we are now being an independent company and being able to maybe work on the open-source stuff a little more than is economically viable or economically wise decision for us. That’s something we really cherish.
Alexis: And speaking of open-sources, not just that your community version that is your open-source project, you have others as well, right?
Sytse: Right, we also have GitLab CI, our continuous integration solution, and the nice thing about it is that, if you already have the GitLab server, it’s really easy to start any projects. It’s also easy to setup distributed runners, we call them so you can run your tests or your other integration work on multiple machines so it scales out very easily. And it’s easy to see the merge request status within the merge request itself so you can quickly see whether the merge request is green or if the tests are still running you can see the lot scrolling by in real time.
Alexis: Going back to hiring. At least the people that we’ve spoken to in the last couple of podcasts, have said that people they’ve hired tend to have been contributors for a long time to the project. Have you seen that as well? Are there any outlyers that you’ve had maybe apply out of the blue, this person has he chops to contribute to GitLab in a significant way and although they haven’t been contributors to GitLab in the past, are you going to take them up?
Sytse: It’s been mostly people who did something right for a community, and we’d love to hire, I can’t wait to hire certain people, we now have to expand for example in North America, but only if you’re listening to this, we’d love to hire and you know it, when we we’re expanding in the Netherlands.
But, we’ve also hired, for example Yakoc, he didn’t have many comments on GitLab but he was working for Rails Girls, which is a European initiative similar to RailsBridge to help people get started with programming and making a career out of it if they want to. Yes, I met him through Rails Girls, he was a coach there and was a good, immediate click and fit about the way you want to contribute to society. You have certain values as a company, as a team and as a people in a team, community stuff is great way to find other people to, that share the same values.
Alexis: Going back to the distributed team aspect, have you ever gotten together with everybody in one spot, or is that you strive to do maybe once a year or is that something that is still on the to-do list?
Sytse: Yes, good question. Of course it’s important from time to time hang out together and maybe have a drink. We do that from time to time. We try to do that once or twice a year. And the last day was King’s Day in the Netherlands, it’s a big orange celebration in Amsterdam, and we had a lot of fun with everyone. Dmitriy and his partner came over and we did some touristy stuff as well. Browsing the Netherlands, doing stuff you don’t do in your own country was good for me and my partner as well. And you’re getting to know one another on a different level before we went to Railsberry a conference in Poland.
One time we went to Serbia, where the mother of Marin made an awesome lunch for us, that was I think both for breakfast and lunch and two dinners, but yes it’s amazing to see one another together. And that stuff you should really do even though you are distributed team, it doesn’t mean you shouldn’t see one another from time to time.
One other thing if you’re a distributed team, you sometimes forget to have a beer together, because it’s not that obvious, so every time we do a release, we have a release celebration where we just sit in front of the camera at home and we all bring our favorite beer and have our beer together. There’s not a lot of technical talk but just a lot of bark which is nice.
Alexis: Oh, man. And enjoyment, of course. So, pricing. How has pricing changed over time from when you started to you know, when the GitLab steam train is at full speed?
Sytse: Good question. In the beginning, we priced mostly per hour, we just did a feature and we estimated the number of hours and that went out as a quote. Then some companies indicated that they didn’t want to go to a whole purchasing cycle every time they had some question for us. So then we figured, we offered the site license, where they pay a fixed amount a year and we’d give them all the support they needed.
Of course we horribly underpriced our site license. And we did, I think a half year of work where we expected only two weeks of work. That happens sometimes and we gained a very loyal and interesting customer as result and they contributed a lot of ideas to GitLab.
So in the end it worked out because the improvement was in the product. Basically all the features we made for them, we were able to also give back to the community and use for our proprietary offering. So it worked out but be careful not to underprice and be careful with unlimited stuff. We now don’t do unlimited subscriptions except in very rare circumstances. It’s better to price per user, because as the user base grows, the complexity goes up. The complexity of the questions goes up from the customer.
Sytse: Our customers mostly have their own operational department. They don’t have easy questions. Every question is a hard question that there’s no, maybe, you should say there’s no first line support with us. There’s only second and third line support because every question is hard one.
That’s really fun, that’s also really fun for the people that field those questions. But it doesn’t mean that you have to price according to the usage, and the easiest thing for us, according to the users. We started off with the $20 per user per year plan, and we noticed that there was a lot of need for twenty four seven support subscription so people wanted to be sure they got support whenever they need it.
Alexis: At any time of the night.
Alexis: “Something is broken. Quick, help me!”
Sytse: Yes. Indeed. Well you won’t. If you need it, you need it. And you want that piece of mind and also, people had interest in high reliability solutions. So, they did not run GitLab on a single server but on multiple redundant servers. Those are a bit more interesting to support so we created a new package it’s our standard subscription that’s $49 per month and that’s made good.
And recently, we introduced another subscription, it’s even more expensive. It’s $249 per user per month and it’s aimed at people that also want to get some development work done. Apart from that we’ll also throw in some free training, so you’re able to purchase one package as a license in order to, yes, to make sure that all these things happens. And sometimes that’s easier for purchased process than having to come up with all the features you want ahead of time which is not always possible.
Alexis: We should note that there is a free edition right for the hosted community edition so if folks would like to give it a try without yet committing the $249 a year, they can certainly give it a whirl on line.
Sytse: Yes, it’s $249 per year and as said our most popular offering $49 per user per year. And those are our offerings. Most people are using GitLab totally for free and that is only I think one in a thousand organizations is paying at the moment. And they’re using it for free and it’s very functional, it’s not cripple ware, it’s not restricted in any way, and there are a few features that are only in the proprietary offering, that it’s very usable product. If you want to try it out, you can use it on GitLab dot com. Or you can for example put up a server on digital ocean where it’s one of the templates.
Alexis: Now I have to ask. Usually, when people are not fond of the idea of open-source, and also carrying your business with that, they always think that “somebody is going to steal my code or steal my idea or etcetera” and then, make their own similar solution. Have you seen any of that?
Sytse: Can you repeat the question?
Alexis: Sure. Have you seen anybody take the community edition of GitLab and, or at least maybe the enterprise edition when it was MIT licensed and kind of make their own competing hosted solution?
Sytse: Yes, that’s a good question. You’re always very afraid of that but it doesn’t happen. It’s like they say, if it’s a good idea, you only have to ram it down somebody’s throat, and i think that’s the same here. And also because you’re actively promoting it and doing a good job yourself, people don’t see the need to create a competing thing, what does happen is people take GitLab and adapt it for their own purposes and that’s awesome to see. For example there’s this website it’s called Binflip, it allows you to author a book with some collaborators.
Sytse: And they run it on adapted version of GitLab. We have a couple of sites like that where people build upon GitLab to create something else. There’s a French site that has all the French laws in it, that is GitLab adapted for law browsing and we really, that’s heartwarming to see people building upon GitLab so that’s greatly encouraged. Nobody ever tried to like, take it out away from us. I think it will only happen if we somehow turn evil and start I don’t know what did Oracle do. Oracle don’t release their regression test or stuff like that just stuff that you know that doesn’t make any sense.
Alexis: Right. Any of these others kind of adapted GitLab solutions for other things whether it be for the book publishing or a legal kind of data-base. Have they charged for it? Or is it still completely open-source?
Sytse: Oh no, dude. Those are proprietary commercial-only software as a service offerings. These people are making money. And actually, that’s great. We love for people to earn money with GitLab. So there’s O’Riley Media doing all their books with GitLab, but there’s also a company called GitHost.IO. It’s run by an ex-Digital Ocean engineer, and he’s offering managed Gitlab. So if you want a server in the cloud that’s managed, automatically upgraded and backed up. But it’s only for you, it’s not multitenant, it’s single tenant. That you can get to GitHost of IO and you use their services. And we think that’s awesome that people are trying to build a business with GitLab, and we greatly encourage that.
Alexis: Now, I have to ask. You’re seeing GitLab being used in these ways that it wasn’t intended for. Do you have any inclination to adapt it for other projects as well? Is that something you see any worth exploring?
Sytse: We have very many ideas, but we have to restrict ourselves to what people are actually asking for etcetera. But I really hope that in the future if you have a legal negotiation about a contract that you’re not emailing back and forth word document with track changes. But there’s a user-friendly solution that allows you make your contract a mark-down so you don’t have to renumber stuff that you can actually have about discretion about the line change with a group of people. And I think these things make sense, and I think it’s a question of time before people start building them.
Alexis: Now, personally, if I can get on my soap box for a minute here, I think that really is the secret weapon, or one of the secret weapons, of GitLab when it comes to things to better] or other offerings like GitHub and BitBucket is that it can be so much more the versioning system for the web in a way.
Sytse: Exactly, this is our secret weapon. You exposed us a bit I think and complicit, it’s not a secret and it’s a power of open source, and we look forward to fully exploiting that, and helping people build their business on GitLab and generate income for themselves and their families with GitLab. That’s the way open source projects exceed.
Alexis: Now, I’ve heard through the grapevine that you have a separate core team.
Sytse: Yes, that’s right. There’s the team, and there’s the core team. The team is the GitLab B.V. team so six people that are either co-founder or on the payroll but there’s the GitLab core team. It’s invite-only, and you can send the solicitations to the GitLab B.V., but you cannot send your solicitations to the core team. You’ll be invited if you show a lasting contribution to GitLab, and it’s a group of people, less and half of people are working for GitLab B.V. and its people who contributed a lot to GitLab over the time. And that can be both quote but also people that are active on the issue tracker, and we also have people called “Merge Marshals” and they review merge requests and offer people tips how to further improve them so that they can be merchant.
Alexis: Before we wrap things up, I have to ask about the distributive teams that you gave a shout out to a contributor that you would love to hire but, you know, he’s in the Netherlands, and you’re looking for somebody in North America. Have there been any legal barriers in terms of, man, I would really love to hire this person, but they’re, I don’t know, they’re from this country or that kind of thing? Just, you know, curious.
Sytse: There are lots of like, it’s much easier to work in a digital world, globally, than to do it in the physical world. And we’ve have two problems. One thing is that Marin who was in Serbia would like to come to the Netherlands, and that we had to apply with the Dutch government because our limited company didn’t exist yet for longer than a year.
They’ve given us some trouble, so we had to hire a lawyer and now send this two hundred, eighty-seven page appeal that I hoped was convincing enough to actually be able to hire him. So that was some legal problems.
And the other thing that we bought tickets for the whole company to go to Urucco, then Greece, but Dmitriy, because he was in the Ukraine, had to apply for a visa, and he had a scheduled interview, but the Greek consulate just did not recognize that, when he showed up, they forgot about it. And he didn’t get his visa in time.
So there we were, with the whole company except the man who started it all. So that was a really sad occasion.
Alexis: So he Skyped-in while having a beer?
Sytse: Yes. We were in the hotel without Skype. It’s times like that it’s really frustrating. But it also makes you really happy that digitally, you don’t have all these things. Digitally, we have eighty per cent of our customers who are in North America, and we can service them so that they’re really, really happy and they’re saying, “Wow. The service I’m getting from you guys is something we never had from any vendor. And you’re able to do that from Europe.” That’s amazing. It’s an amazing opportunity.
Alexis: Absolutely. Let’s see.
Sytse: Maybe one thing that’s relevant if you want to make money on open source, you have to make it really, really easy to install your software. And we were at a bit of a disadvantage there, because we’re a Ruby application.
Sytse: And historically, Ruby has not been known for being easy to install. So we started off with a really, really good installation guide. It covers all the cases, but there was one problem. It’s ten pages long, ten pages of copying and pasting commands. And that’s a bit too long for comfort.
So we were really lucky that great people of Chef Incorporated made this open source program called Omnibus, and it allows you to bundle up all your dependencies in one big dep or RPM file, and that’s been working out for us. It’s taken a bit of time to get everything rolling, but now that we have it, we’re really really glad. And people are able to install the app and all its dependencies in two minutes on their own machine.
And that’s amazing. That’s a speed you don’t normally see, and that’s because everything is precompiled, pre-bundles, pre-package processed, and it’s been working out for us. And I can really recommend people that, want to make money out of open source, try to make your install as simple as possible because it’s the first most important obstacle to people trying out your stuff.
Alexis: So what’s next for GitLab?
Sytse: Well, we don’t have a very elaborate long-term road map, we just do what the community asks us to do. And we want to grow as a company, we want to end up with staff, in all time zones all over the world. We want to grow GitLab, we want to improve a lot of things, lots of things that are worth improving. We want to make sure we are able to merge a good code contributions, and that we grow the popularity, and that we enable people to spread the word about GitLab. Our goal is to have GitLab be the infrastructure diversion control infrastructure for lots of other products. That’s it.
Alexis: Now you’ve got me thinking of what I can build with the version control on the web. So let’s see, where can people go to find out more about GitLab?
Sytse: On its website, www.GitLab.com. There are lots of resources. Ask us questions on Twitter, it’s @GitLabHQ.
Alexis: And where can we find out what you’re eating for lunch or dinner on Twitter? Or what kind of beer you’re drinking with the team?
Sytse: I’m not sure. It’s always on there at my Twitter it’s @SYTSES
Alexis: Alright. And folks can go to Binpress.com, and follow us on Twitter at @Binpress and myself @alexissantos. And of course, please remember to go to iTunes and subscribe so you can get it there on your computer without having to go to our blog every single week. And please be kind, and give us a review. Five stars would be nice, but we’ll take honesty. Well thanks, Sytse for joining us, and we will catch the listeners next week.
Sytse: Thanks for having me, Alexis. Thank you very much.
Alexis: Not a problem.Open-Source Podcast