GitLab&#39;s Master Plan

Alright, we’re back with a great show today. Jerod, we’ve got a show in the making. It’s been three years and a day since we published the last anything on the Changelog from GitLab. Today we have Sid joining us; the GitLab Master Plan, a lot of fun stuff around where they came from… What do you think is the most interesting about GitLab these days, Jerod?

I think everything’s interesting about GitLab, and in fact Git hosting in general is. This is a huge week, huge announcements from Sid’s team, the GitLab Master Plan, GitHub Universe also going on, and I think new features coming out of GitHub. As users of Git and of these services, we just get all the goodies. We love to use them and enjoy them…

We level up.

That’s right, we level up. GitLab leveled up quite a bit. Huge announcement: $20 million series B funding - is that right, Sid?

That’s correct.

Congratulations on that, and thanks for coming on the show.

Yes, big congrats!

Yeah, thanks for having me.

Sid, it’s been three years… The last time we had you on this show the Enterprise edition was just being announced. You were announcing GitLab 6.0; this was September 2013. That means we’ve recorded it probably a week before that, so it’s still early in terms of that timeline you presented yesterday in that live broadcast. But I don’t think we know much about you yourself; I don’t know how often you get a chance to share about where you began or who you are, introduce yourself to the software development world; introduce yourself and maybe take us back to maybe where you got some of your first initializations into software development.

My first computer I remember vividly. It was an old Tandy from my uncle and I had a really hard time finding the On button. I got the thing, I plugged it in, it was an integrated thing and it turns out the on and off button was under the keyboard; but it’s hard to look under the keyboard when you have to lift up the entire thing. Literally, I examined every surface of this computer, trying to find out how to turn it on.

[03:54] I didn’t really get into programming. It was too tedious, I thought. I studied Applied Physics for a year and ended Management Science. One investor called me an “organizational design junkie”, and I think that’s a good way to describe me.

After my studies, I was the first employee of a submarine company for five years. We made recreational submarines, where people can dive in. It’s basically if you have a boat of more than 50 meters, 150 feet, you already have the helicopter - or not, because they’re tedious - and then you want something else, and so we made the submarines and we totally failed at our price point, because we tried to make it for $25,000 and they now cost $2 million. We really, really tried to make them affordable. It’s hard…

That’s funny… [laughter]

That sounds hard.

They’re great. U-Boat Worx is still shipping the most submarines every year, which is a handful.

Jerod, it’s a first for us to have somebody on the show that has been in Applied Physics, for one, or maybe we’ve never asked, that kind of background, but then also to build submarines.

Well, Sid, give us your best take away. What you learned building submarines, that we can apply to the craft of software development?

Well, one lesson we had to learn - and I think you can learn that in software as well - is that outsourcing to lower wage countries is not always a good strategy… [laughter] The other thing is that even though there might be no government rules for things, that doesn’t mean that there are no rules. There are all kinds of implicit rules and we figured out… We had to learn that for submarines. Although the government doesn’t require anything, the insurance company does require things and people kind of what to be able to ensure their submarine.

It was a very interesting time. I did Applied Physics only for a year, so I hired one of my friends from college to actually do the mechanics and I focused on the electronics and the automation, building my first computer board and programming chip. I was really, really beyond joy when that chip booted up the first time, because I would have no idea to troubleshoot it.

But at the end of those five years I saw Ruby, the programming language, and I said, “Wow, instead of tedious, this looks beautiful. This looks great. This is what I’ve always wanted.” I started learning Ruby and became a developer and after a few years of consulting for various companies, I saw GitLab and I thought, “Wow, this is amazing.” It makes so much sense that our collaboration tool is something you can contribute to, that it’s open source and I thought SaaS and dotcoms are the future. That’s the way to make money, so I got started with that.

So the role you play now is CEO, right?

Yeah, that’s correct. Dmitriy, the author of GitLab and I co-founded the company. He is CTO and I’m CEO.

So would you say that you’re business and he’s software, or would you say you’re kind of a mix of both?

No, I think that’s a good characterization.

I know you built submarines… What made you wanna be an entrepreneur? What made you wanna be the person defining a company, leading a company, hiring employees, building a product?

I think I’ve always seen stuff where I’m like, “Wow, that would make a great business”, and the first one was during my studies. I saw someone made an infrared receiver, and this was in ‘99, where everyone was starting to run MP3s on your computer, and we’d have this website that did reviews of how much CPU a different MP3 encoder would take, and this infrared receiver allowed you to use the existing remote you have of your stereo to skip to the next song and I thought, “That’s amazing.”

[07:59] The code was open source and I ended up being the business person selling it, and that was in my first year. Then Applied Physics had lots of difficult math, so I figured I like the entrepreneurial side. I switched and I started to do Management Science.

Now that we run GitLab, I find out about myself that I have a lot of opinions how companies should be run more effectively. I’ve done internships at some Fortune 10 companies and I saw lots of inefficiencies. Now at GitLab I’m trying to prevent having that and making sure that people can be very effective and can get lots of results. I think that’s where that business passion is coming in.

Yesterday on the live event - just to catch up the listeners - GitLab had a live broadcast of their Master Plan, which aired yesterday (September 13) and on that, Sid, you said that GitLab started off as an open source project and you came to it, and… Remind me of the name of your co-founder again.

Dmitriy.

Dmitriy - and you told Dmitriy that you’re gonna take this and turn this and turn it into software as a service, and he said, “Okay”, or I don’t recall what he said, but you tried that and then that seemed like it kind of fell flat. Can you give us that, a little bit of a background and what you moved to from there?

Yeah, so I felt all the money is in the SaaS, like Salesforce, that’s what I read on TechCrunch. I email Dmitriy and say, “Hey, Dmitriy, I’m gonna make money on this and well, I’m sorry, but you’re probably not gonna be part of this. I hope you don’t mind.” He was like, “Wow, it’s so amazing you’re doing something with GitLab and making it more popular. Of course, go for it. It’s open source, do whatever you want.” It was really nice of him.

A year later, I learned that I was wrong. It was really hard to make money on the SaaS, but at the same time there were all these enormous companies, like Fortune five companies, that were running GitLab and were asking me for more features, because I was easy to find on the internet; but I wasn’t the world’s best programmer.

At the same time, Dmitriy tweeted in a public tweet, “I want to work on GitLab full-time”, so that was easy. I contacted Dmitriy and said, “Well, I can pay you to work on GitLab full-time”, and he started making those features and we spun off some of those features into the enterprise edition in order to have a business model, because we’ve tried everything. We tried donations, we tried consulting, we tried pay for development, but none of this really seemed to work. But licensing software, it was very easy for users to pay for that. It was very easy to just have a “buy a license to use software”, they were very used to that, so that model worked much better than donations, which they didn’t have a budget for.

Can we pause on some of the fails there? You mentioned consulting and donations… How hard is it to maintain vision and trajectory when trying ideas to sort of become sustainable, I guess, in terms of funding? How hard is it to maintain your promises to customers, your promises to end users, while trying things and experimenting with different funding models and then ultimately those not working out? How do you keep and maintain trajectory on that?

Yeah, you have to keep an open mind. Donations, Dmitriy was already doing that, so the first thing was intensifying that. I think the biggest drive we did, we got a thousand dollars in a month, which wouldn’t even pay for Dmitriy, and then it was a single drive, so keeping that up was super hard. I think now with Patreon and stuff, you can get like up to $10,000 in subscribers, so that will pay for one or two people. It’s becoming a better model especially because Patreon is recurring, but it’s hard to bill the serious company and competitor out of it.

[12:16] We also tried consulting, helping people fix their GitLab installation, but at the end of a consulting arrangement, we would of course take all the lessons we learned and incorporate them into documentation in the open source project. So very quickly, people didn’t need consulting anymore. Of course, this is how it should be. It should be very easy to install GitLab, and our open source edition is even easier to install than the paid one, because you don’t have to add a license, but both of them you can set up in a couple minutes.

We figured that the project will never become popular if we would make it hard to install and then pay as for consulting, that didn’t make sense to us. It’s not efficient, it’s not the way the world should work. And then paying for development, that was hard. First, you have to agree on the feature. A potential customer wants a feature; you still have to agree and negotiate a bit about how exactly it should look. Then you have to make an estimate; then they have to purchase it which sometimes is hard, because for the purchasing department, this falls under paid development, and they frequently have a preferred vendor for this.

Now they need to get out from this preferred vendor agreement, and then last but not least, you have some perverse incentives, because sometimes there are multiple people asking and willing to pay for the same feature, and of course you don’t wanna cheat on them by making everyone pay the full amount, but as soon as you inform them there are others, they’re not as likely to agree to paying for it because they figured they’d just wait, and in general that’s the incentive. Because GitLab was moving so fast, if you wanted a feature, it’s very likely it will ship in the next few months. So why go through all the hassle of purchasing something? This made it really hard to pull off that model.

It’s maybe useful at this time to get a lay of the land of GitLab, and we’ll do a little bit more on the history side, but just what it is in terms of products; you have a community edition, there’s Enterprise, there’s your gitlab.com… Can you just lay out all the different ways you can go about using or engaging with GitLab as a product today?

Yeah, so GitLab started as a Git hosting and code review tool, and it branched out. Now it also includes CI, it includes CD, it comes with a chat client, an open source Slack alternative, you can run behind the firewall, and we’re working towards a more complete version. We’ll probably talk later about doing the whole software development lifecycle. So that’s it. All those parts are in the open source version, which you can run without limitations, and over a hundred thousand organizations run that. It’s the most installed and the most popular behind the firewall way to use Git.

We also have an enterprise edition that contains features that you’re more likely to need if you’re over a hundred people. You get these additional features if you pay us a subscription of $39 per user per year. Now, we also wanted to offer it as a service; not because the money was there, because that’s what I learned, but to make it easy to get started and to explore the product.

We made a conscious decision to give away everything on .com and make it completely free. So on gitlab.com you get the Enterprise edition with all the features and you pay nothing. You don’t pay for public repositories, you don’t pay for private ones, you don’t pay for collaborators… Right now even the CI is free. You can have as many parallel CI runners as you want on your private project and you won’t even pay for that. So those are the three products that we offer.

[16:12] The only difference there is perhaps you want for privacy or security concerns you don’t want the on-premise enterprise version… Otherwise wouldn’t everybody just use your free hosted version?

Yeah, exactly, but what I learned in that year was that all large organizations in the world basically run it behind their firewall, and there are different reasons. Some of them are security-related; they want it behind their VPN servers, or they want to hook it up with their single sign-on service, or they want to do LDAP Group Sync. Some of them are legal, they needed it on their own servers, or they need to know where exactly, in which jurisdiction it’s located and they want to see when someone serves them a warrant.

And last but not least, some reasons are technical. They have a lot existing infrastructure to integrate with and they don’t wanna poke a lot of holes in their firewall. It’s more performant if it’s on the local network.

That was a surprising thing to me. I thought that everyone will be using a SaaS, and it turns out all the large companies without exception are currently using something on-premises, so that’s where we monetize, that’s our business model.

So basically the on-premise version is the funding model, and that funds the free .com, that funds the host-it-yourself version that is open source; 100,000 people, as you mentioned, use that self-hosted open source version, but the on-premise is essentially the way you make money, the way you sustain, and essentially what pays for all the development for the .com and the open source.

Exactly, that is the model, and it’s a hundred thousand organizations, so it’s millions of developers. There are some companies using GitLab with over 20,000 people, and some of these are even using the open source version.

Just curious, I mean, considering there’s other code hosts out there, which we know, why is this model better than the other models? And I don’t think you need to go and speak to their models particularly, but why do you feel like this is the better model or how did you come to the conclusion that this is the best model for you?

Yeah, I think what we wanted to do is we wanted an open source version that is not crippled in any way, that doesn’t have any artificial limitations, that gives you the complete experience, that allows us to, when someone has a feature that maybe already exists in the enterprise edition, it still allows us to merge that in the open source one without completely destroying our business model in one go.

We think the way to do that is that there are some features that larger organizations need, and the great thing about larger organizations, those are the organizations that make up the majority of all software spending. If you can get them to adopt your product, you will do a lot better.

GitLab was born in the enterprise. Dmitriy and Valery were working in an organization with more than 200 people, and those customers that were asking for features in the beginning were also enormous organizations, so from the beginning we focused on the feature set for them, and that’s why we’ve become the most popular there, and the lucky thing is that’s also where the money is.

Well, Sid we’re bumping against our first break, but before that let’s talk real quick about your company size and way of catching up. I think probably when you were on the show last time you were quite small; I know you mentioned in your timeline, I think it was 2012 or maybe it was 2013 when you had nine employees. Of course, we just stated that you just raised $20 million Series B, so that is to support many people. You now have 104 employees, and quite interesting to me at least, in 103 locations - can you tell us about that?

[20:03] Yeah, so in March of 2015, one and half years ago, we graduated from Y Combinator, and for us that was an inflection point. After that we started growing a lot quicker than we had before because we wanted to make sure that all companies will standardize on GitLab, and we recognize that it has to be a complete product and that we had to have great marketing and sales to do that.

However, since the beginning we’ve been a remote company, so there was a… I anticipated having to hire locally in San Francisco; we got an office there and the first sales people came to the office, and then after a few days they started working from home, because all of our tooling, all of our organization was set up to be able to do that. They were making their quota, they were doing great and I figured it’s fine. I like to work from home too, I like to not be interrupted, I like to have flexibility in my work day, I like the ability to travel where I wanna travel, so I never make them and we kept that going.

By now, we’re over a hundred people from six continents, we’re in 33 countries, and basically everyone works from another location, and from the location where they wanna work from. The only exception is that sometimes our executive assistant comes to the office here where I also live. But we found that this remote-only way of working is making us all a lot happier. There’s a much better harmony between work and the rest of your life, and it’s something that we want to keep going. And it allowed us to hire amazing people.

I bet you’d like to have somebody on that seventh continent though, wouldn’t you? [laughter]

Yeah, there is someone who remarked, in our company, he just bought a lot of generators, so maybe he’s ready for Antarctica.

There you go.

You can always go back to your roots with Applied Science or Applied Physics and submarines…

Yeah, maybe we should have a station there, that would be a nice perk. The hardest thing to make work is timezone, so… The location is nice. It’s also nice to hang out together from time to time. We do have a summit every half year, and we spend a lot of time trying to make remote work so you still feel part of the company.

We have a call four times a week, and more than half of the time is spent with people telling what they did in their private lives. We have the concept of virtual coffee breaks. We schedule half an hour to talk about things that don’t have to be work-related. We really want to make sure that everyone feels part of the team and we’re doing I think a great job at that; people feel closely connected. Even two people that are living on another continent.

To do remote work, you definitely have to bake it into who you are, that’s for sure, because there’s companies that have this kind of hybrid version where you have some remote and some in office, and you always feel like a divide, and how the message has to be distributed through the organization is always like, “What is this person, local or remote?” and it’s always this fragmented communication pattern. So being all-in, being remote-working in your DNA has to be the key there.

Yeah, we think doing a hybrid model is the hardest thing. We think being remote only…

It’s impossible basically. It does fail, it will fail.

[23:49] You always feel like you’re a secondary citizen, and even companies with multiple offices will always have the feeling of either you’re in the main office or you’re in the satellite office, and you’re missing a lot. And here, everyone is on the same level and we really try to over-communicate. For example today in our team call I shared our management notes. We had a two-day, we call it the remote off-site, which basically means we sit a couple of hours in a call with the whole executive team, and we shared all the notes with the whole company.

We had a fundraising channel, a chat channel where we kept a score-by-score of this investor, we were on to the next meeting, this one said no for that reason… People cheering us on, people learning about what it means to invest, to the point where when I announced we had a second term sheet or the third term sheet, someone said, “Yeah, what’s the liquidation preference?” and this was coming from a junior developer who recently joined the company; so really having everyone involved in stuff that normally wouldn’t be a formal process, it will be something you ask during a lunch break… But we’re recognizing that if you’re remote, those lunch breaks are spent with your family and your friends, so we have to over communicate in an all the formal things.

Alright, let’s take our first break on the other side, and we will dig into the heart of the conversation around GitLab’s just announced Master Plan and what that means for the present and future of the product. We’ll be right back.

Break

[25:26]

Alright we’re back with Sid Sijbrandij, talking about GitLab and the just-announced Master Plan. Sid, you’ve got big plans for the future, exciting ones to say the least, and it’s all kind of focused around this idea of conversational development, so I thought we’d start there. Talk about what that is and then how GitLab is going help promote it or provide for it.

Yeah, I’d love to. I wanna take a step back to the evolution of different paradigms in software development processes. We used to have waterfall in the ’70s, and it was very rigid and inflexible, and luckily got replaced by Scrum, which was a great improvement, but you still had to estimate everything single issue, there was a lot of negotiations going on…

Most of that got fixed by agile development, which I love, and conversational development is an evolution of that. What we wanted to evolve is that Agile doesn’t cover the whole process, it covers only part of the process, the development one. For operations we had to like add DevOps to it, but I think there’s still something missing from the beginning. There’s also a process before you decide to start doing something, and another thing with Agile, it focuses really on collaboration in the same location, and I think with open source we’ve seen that you can collaborate effectively even when you’re remote. So we think it’s time for a new paradigm, or an evolvement of Agile, and we call that conversational development.

There’s five main points in there. We want to reduce to cycle time to increase effectiveness. In the cycle time we measured the time it takes from having an idea to having it in production. And anything that impedes that should be measured, and you should try to do it more quickly. Many large organizations now, they take many months between having an idea and then having to code out there for users, and we think that should be days.

To do that - that’s the second thing, you need to monitor the process; you need to know how long every step takes. And the third thing is you wanna thread the conversation to all stages. So when you deploy something, when you get something out to users, you wanna be able to go back and see the where did this idea originate. You wanna make sure all these steps are linked, and if you can have a conversation that is supported by your tooling.

Fourth, is that gate keepers become part of the conversation. It used to be that, for example, a security audit was a step that was kind of a hold up, we think instead these people should be involved; they should be invited to contribute, and by doing this more frequently, you can reduce the scope of every iteration and it’s easier to review.

And fifth, the rest of the organization should be able to contribute. We’re seeing that large organizations are adopting the practices of open source and then call it inner sourcing, where if you have a project you make it by default open to other teams, and if they wanna reuse your code, they can rest assured that they can fork the project and contribute back to it, so you can re-use the same code base.

We think that the biggest benefit are in reducing the cycle time. It’s simply that shipping smaller and simpler changes is more effective, and it’s effective and lots of ways. It’s more in-line with expectations, it’s easy to coordinate, code review is of a higher quality, it’s easier to troubleshoot, and it prevents gold plating, like overshooting needs.

[31:55] Apart from that, if you reduce the cycle time, you have more frequent interactions; more users get exposed to your code and give you feedback. You’re quicker to respond, there’s a higher predictability, there’s more a sense of progress in your team. We think that this is what everyone and especially large organizations need to become more effective at.

Well, as you’re talking through these, I’m just kinda applying those to our own process here Adam, because I guess I’m narcissistic or something, but… We’re a tiny little team, but when we think about cycle time, maybe two to three people involved in Software Development… And I guess we feel like it’s a pretty fast cycle time, but we don’t really have the monitoring. Number two is monitor the process, from idea to production, so it’s more of a feeling than something that’s been quantified. But when you got to point three about threading the conversation through all stages, that’s where I started to think, okay, this where a tool – I mean, I’m sure a tool can help with monitoring of course as well, but a tool which is kind of part of your plan as you’re gonna unfold, is this providing kind of all things that you need to have this style of development, whereas right now, if we just look at the tools that Adam and I are using internally - we have a Slack, we have GitHub Issues, we have Trello - half the time we spent trying to find a…

Envision…

Envision; we have Google Docs - sometimes it ends up on a Google Doc, Brainstorming, or it’s in my notes app just locally on my computer, and half the time we spend trying to refine things…

Yeah, “Where’d we put that idea at?”.

We say, “Haven’t we had this conversation before?”, and we go to search and through all of the things and eventually find it. So I think threading that conversation, that’s where I really feel like there’s a disconnect in tooling.

I also feel like the second part of that, the last two points with the gate keeper and the rest of the organization, like how many times – I’m not sure for you Jerod, but I’ve experienced this when I work at Pure Charity, where we would invite people in what we call “the business side of things.” We would invite them into the process, and essentially ask them – because we hosted on GitHub, we would invite them into the GitHub organization to monitor issues and track things. These things have obviously evolved since then, but we invited them into what is typically, as Sid is sharing here, like what’s typically shown as Agile, which is around just the development cycle. Whereas Sid, correct me if I’m wrong, but I think what you’re doing is you’re zooming out quite a bit to say, “How does the product get made from idea to delivery, and how can we provide the tools necessary for collaborating around that, whether you’re remote team or not? How do you deal with inner source and then ultimately how do you invite the right kind of people into the conversation, so that no one is an outsider?” That’s to me pretty interesting.

Awesome. Yes, it’s exactly as you describe. And to give a practical example of how that could look, many times ideas start in a chat. We ship Mattermost, but many people use Slack, and we wanna make sure that those ideas don’t die. We’re gonna ship it something that allows you to say “Create an issue of the last ten comments I made”, and then that issue should end up on a planning board.

Last month we shipped an issue board with GitLab, and then to make it easier to pick up an issue and to start coding on that, we’re shipping now with an online IDE, where on any repo you can say, “Start my IDE”, and then seconds later you have a terminal with everything set up. Maybe that doesn’t help you if you’ve already been working on the same project for a year, but if you’re new to a project or you just wanna make a small contribution that changes a lot of things, that makes it easier.

[36:10] And another thing, Google Docs - we also use it extensively. I’ve been thinking, I would really love if the description field of issues, merge requests was a real time document. I’d have a Google Doc right there, because many times a Google Doc is basically a substitute for an issue in our company, and we’re also looking at that. We haven’t decided whether we’ll ship it, but we’re actively thinking to make that better, so that you can have it within one toolchain and if you have it within one data store you can do the threading a lot better, but you can also do the feedback, like where is stuff getting stuck.

I think part of this conversation for us to have you back on the show is kind of three parts, as I look at it. It’s a catch-up show because we haven’t had you back on since 2013, part of it is also talking about this master plan, but also part of it is kinda differentiating what GitLab is as a Git code, repository code source, which in a lot of cases over the years you’ve been very close to compare to GitHub or even Bitbucket, and when Software developers look at these platforms to choose, they think, “Well, okay, either one - where’s the community or why should I use it or what should my company use or what provides me the better thing here?”, and I think what is interesting about what you shared yesterday and the things you’re thinking about is rather than just saying, “Hey, we’re the best place to host your code”, it’s, “Hey, we’re the best place to develop your product.” And it seems like that’s what you’re saying, versus just simply “Host your code here” basically.

Exactly. We want to be the best place to collaborate and we think that an integrated software developer lifecycle is way better than using multiple tools, and it’s something that wasn’t intuitive to me. When Dmitriy started making GitLab CI a couple of years back, I was like, “No, let’s focus on the code hosting, there so much left to improve”, but he, as a co-founder and original author, he can do as he pleases and he pushed on.

[laughs] He’s got the code editor.

Yeah, and it turned out he solved that by integrating it closely with GitLab; it was a much better experience. It was easy to set up, it was easy to get started with, and then the suggestion came, “Let’s integrate this GitLab CI app with GitLab”, and I was not in favor in the beginning. I was like, “We already have a giant monolithic app. What are you doing? You’re making a monoRail out of this (a monoRail as in a huge rails app). This is against all the best practices, we shouldn’t do this.”

And it took a bit of time for me to come around, but our CI lead also said the same thing. We integrated it, and it’s a so much better experience. Now if you look at places like Hacker News, people say, “I’m using GitLab and I could replace not only our Git hosting tool, I could also replace our CI tool. I could also replace the Docker Registry for private containers. And not only could I replace it, but it was so much easier to set up. I’ve spent days setting up all these old products, and these products - it was a question of minutes, because it’s integrated.” You don’t have to ferry credentials around to the private container registry. No, your CI runner knows it’s the CI that’s running that project and can push the containers to that.

[39:59] So it’s a better experience, and that was counter-intuitive to me. I like the UNIX philosophy - one tool does one thing, but what I’m seeing more and more is that it is a very complex thing to make software, and that we’re using these collections of tools and if we integrate them together… Over a thousand people contributed to GitLab, so if we get all the best practices of the best people in the world and we integrate them into a tool, we just prevent a whole bunch of needless push-ups that you now have to do.

I can’t compare GitLab to the genius of Ruby on Rails, but I was greatly inspired by conventional reconfiguration and I still think there’s a lot of needless configuration in many developer pipelines; I would wanna take that away. If you wanna go fully GitLab, it’s gonna be an amazing experience. If you wanna use other tools, that’s fine too. We’re playing nice with Slack, we have great JIRA integration, we have Commit Status API for Jenkins…. We’ll play nice with other tools, but we’re gonna save you a whole bunch of time to make this idea to production happen.

I think that’s the key right there, because the doubts in my mind as your talking is whenever you lose that focus, like you said - and I do believe in integrated products for sure when done right, and therein lies the risk - is providing everything you need for this style of development, there’s many tools involved. I know you guys have laid out kind of a ten-stop or a ten-step thing, where some things you provide, some you don’t yet, but you’re planning on it. If you have ten things you need to provide for an integrated solution – and I’m down with eight of your products, but those other two completely contradict the way that I believe, or I hate them, or whatever it is, you lost me. Because now it’s a one-stop-shop, so it’s all or nothing. But it sounds like there still is opt-out, type of a la carte style plan for this as well?

Yeah, we want to convince you that it’s a better experience, but we don’t wanna force you. You can use just GitLab for code hosting and code review, and that will work fine. Right now we identify ten stages, and eight of those ten are now shipping with GitLab; it ships with Mattermost, it ships with an issue board, it ships with an issue tracker, it ships with coding and online IDE, it’s ships with repo management to commit your code, it ships with CI, it has the code review, it has the continuous delivery, it has many other things we’re still working on to improve that.

For example, we wanna ship with something called Review Apps, and then two things we’re still working on: ChatOps - we’re looking into a Slack bot right now, because most of our users are still using Slack. But long-term, we’re thinking about integrating Cog (from Operable) and then last but not least, the feedback. This month we’ll ship the first interaction of Cycle Analytics that will start giving you feedback about how long it took to get from idea to production.

So we’re very close to shipping all ten, but that’s not where it ends, because then we didn’t have to raise 20 million. The hard part is making it a better experience with this, by better integrating them. So fewer clicks. Right now we ship with coding an online IDE, but it’s still a couple of clicks to set up the project.

[43:54] What we want is if you look at an open source project and you like it and you wanna contribute something, you press one button, you don’t have to provide any credentials, and there you are, in the terminal, and the product is running. To get there, we’re gonna invest a lot of time and resources to make that an awesome experience.

Let me lay out the 11 points - I guess that’s what it ends up being - in your talk/livestream yesterday. Number one was cycle time, number two was review apps. This is all in terms of your one-stop solution for conversation development. So point one is cycle time, point two is review apps, point three is monitoring with Prometheus, number four is embracing container schedulers, point five is Integrated, but plays nice with others, point six is version control for everything, point seven is powerful chat bots, point eight was online IDE - I think you mentioned coding there for that - point nine was speed improvements, which who doesn’t want things to be faster? Like, no one said, “Make it slower. Point ten was ease migration from legacy systems and point eleven was whatever your contribute, or our customer’s request.

So that was the points you made in terms of this one-stop-shop… But when we break things down, like the IDE part, it seems like that was sort of like maybe experimental and there was a collaboration there with Coding. Is that something you’ll take over yourself, eventually? Will you acquire them? Do you plan to make your own thing there? Can you break that down for me?

Yeah, we wanna reuse the best solutions that are out there. We have no plans to make something ourselves or to do something else. Coding, we were in a conversation with Coding and we were so much aligned on the vision for the future that they decided to open resource their code base, so we could ship it in GitLab. Because any major part of GitLab will also have an open source component to it.

They did that and it’s now - we’ve announced it, but it’s not a great experience yet. It’s hard to set up, there’s still screens to click through. Now the real work has started off making that easier, and that’s where our focus is. And I think that also goes where Mattermost – although with Mattermost the integration is deeper. It ships by default with GitLab, the all off authorization is completely integrated, but there’s more we can do, and it’s a project that will never be completely done. The things you’ve just outlined are things that are priorities for us for the rest of the year and for next year, where we want to make this a better experience.

And then you also said there are too - I’m not sure if I just heard it right, but you say Cog? Was there a product called Cog?

Yeah, exactly.

What is that?

C-O-G. You might have heard of Hubot, it’s a ChatOps client, and ChatOps is something that allows you to say, for example, “Deploy staging to production.” That will take whatever is on staging now and deploy it to production. Hubot was a great innovation there, but the people of Cog try to take it one step further. What they’re doing that I think is great, they have permissions, user-based permissions at a much deeper level in the product. With many chat bots today you don’t really have privileges. As soon as you have access to the chat bot you can do everything, and for many teams, especially these large enterprises, that’s not acceptable.

Another problem is many scripts can do everything. So you can have one person making a mistake in a script and then pulling down the entire production environment. For many of our customers that’s not acceptable, so Cog splits it up into a coordinator and individual script. Those run on different containers, and as an additional advantage, you can use the programming language that you like.

[48:04] Also, they’ve done some nifty things where you can use like command line syntax with pipes to stream the output of one script as an input to the other. We think they’re onto something. It’s still early, it’s still hard to use right now, or it’s so hard to set up, but we think it’s the future, and we’re working with them to ship them with GitLab in the future.

Cog is very cool. It has not crossed, I guess I can say, Adam’s radar either, but definitely not my own. So as you talk, we are linking it up in the show notes and checking out the readme. You mentioned that it’s still early… Their status actually says, it’s public alpha and not currently recommended for mission-critical workflows, so I hope you all know what you’re doing when you get this thing integrated.

That’s why that collaboration - to make it better.

Yeah. Sid, one of the points in your focuses for the next year is version control for everything, and I believe that means large files, but I’m wondering if that also has any vision towards versioning thing that are not code or files, like database or data in general?

Yeah, it means making version control more accessible. Because right now a lot of developers are using it, but a lot of design teams are not yet using it. An example is large files; we think GitHub did a great job with Git LVS. Right now that’s an extension; we’d love for it to be included in the Git binaries, basically. We’re paying someone to work on that.

A thing we shipped ourselves is file locking, where you can lock certain files, binary files, to prevent other people from working on them at the same time and overriding your changes. That is something we ship, but we think we can still improve and make better, and there’s also an example that says Comments on images. If you have an image, you basically want… Sometimes you want to comment about the whole image, but sometimes you wanna comment about a specific part, and I think we can do a better job of allowing that, but that’s the feature we wanna ship.

Very cool. Any thought on the data stores or data in general? I know Max Ogden has a very interesting project called DAT, which is trying to be version control for datasets. I know it’s popular in scientific communities, as well as a few others, but any thoughts towards that in terms of bringing data in for the product development cycle?

I think it’s a very interesting subject, and there’s a company called Pachyderm that is doing great work there. They’re to bring like a version control of Git to the Hadoop space, basically, and they’re doing an amazing work there. We don’t have any plans at the moment, but what we like is that because GitLab is open source, people can build upon it. So for example there’s a site called Penflip that allows you to write a book collaboratively, and they based their project on a fork of GitLab, and we tried to do the best things that the community is building on top of GitLab, and learn from that to make GitLab more user-friendly.

It’s certainly interesting to learn a lot about this idea of conversational development. I know that this is kind of an extension to Agile and I know your passion for that, Sid, so it’s just kind of interesting to kind of dive through to each of this points and ask a ton of questions. I’m sure we’ve got tons more, but we’re gonna break here real quick and when we come back we’ll dive a little further into some of this points, and we also have some questions around just the Enterprise edition and the overall ecosystem you’re building and how that begins to continue to play out. And how maybe even those who are listening can start to get involved in what GitLab is doing and moving things forward. We’ll break and we’ll be right back.

Break

[52:04]

Now, we’re back with Sid and we’re talking about the master plan of GitLab. Sid, I think it’s awesome too that you guys did this Livestream. You did it in a pretty good fashion too, except for the unmuted mic during the demo; [laughter] pretty much a stellar performance. I think it was pretty awesome, but it’s a great way to communicate to the community what you’re doing.

One of the things that was mentioned there was regarding this idea of ecosystem. This comparison to Atlassian and the ecosystem of developer tools. I think you even alluded to it earlier, having this monoRail or even monolith idea, but you mentioned having all the tools have one data store. You talk earlier about being able to track and the cycle timeframe and all this different stuff, but can you expand on what you mean by a cycle analytics and how those who may not be using, since it’s a new paradigm you’re creating this conversation development process, how they’re missing out on the details learned from understanding your cycles?

Yeah, so GitLab has one data store; most of the data is in the in Postgres, so even though we ship in Mattermost as a tech client, they will store the data too in Postgres, so we can do analytics there. Cycle analytics will show you how long you spend in every part of the process. We will show you, Ökay, you were chatting about something. How long did it take you to convert that into an issue? How long did it take you to plan that issue? How long did it take you after planning it to boot up the IDEs and start coding on it, and after you committed it, how much time did the CI take to run? How much time did it spend in the merge request? How much time did it spend in an acceptance or a staging environment? How long did it take you to then deploy it and get it out for real?” We think that showing this enables a conversation with your team and the rest of the organization about what you can do to improve it.

This is very new, and will ship the first iteration of cycle analytics this month, on the 22nd of September, but I think it’s gonna be really interesting. I think for example that many companies will find they plan something and then it takes a really long while before they get started on it, and that will open up the conversation, “What’s most important to plan when? Can we just decide a month before we start doing something, to do something? Maybe we’re planning too far out. Why are we building two or three quarters of features? Don’t you know a quarter beforehand much better what you need next quarter than half a year ago?” Those are the types of conversations we wanna enable in teams, and we look forward to people using that and improving it, and starting to reap the benefits of reducing that time and having that sense of progress and getting more information and being able to respond fast.

[56:07] Can you share a bit about what the interface might be or what the user might see in terms of what this is? Is it reporting, is it something that somebody has to be interactive with, or is it simply like an algorithm searching your dataset and pulling back some pointers basically towards how long things played in certain cycles, as you mentioned in your answer there?

Yeah, of course. There’s a public issue and I just chatted it to you, and you’ll probably include it in the show notes. To describe it to the listeners, at the top you’ll see the pipeline of how many ideas get shipped, how many issues got closed, how many people collaborated? And then on the left side you see all the stages, what the median time was, what the 95th percentile time was. So “It took you seven days to find something on average, or median time.” And then on the right side it will show you “Of the last deployments, this is how long ago someone first chatted about this idea.” And that can be anything from a couple of hours to more than a year.

Wow. I love that too, because I’ve done that where we’re about to ship something or we’re actually beginning to plan for it. Planning and talking about something is two different things, and it would be interesting to see like, “We actually talked about the need for this feature a year and a half ago and we had this issue or this support request”, or whatever might come from it. So it would be interesting to see that auto-contrasting back to like, “Here’s when we really talked about it, here’s where we began to plan it, and here’s where we shipped it.”

Yeah, and I think people will learn that the only way to get it done is to ship smaller things. The picture you’re looking at will not be our first iteration of cycle analytics. We’ll ship only the minimum product first, and then iterate on it. I think that’s the big lesson we learned at GitLab and what I saw going wrong in lots of other organizations. If you just add anything that you think might be useful to an issue, you’re probably overbuilding it. It’s much better to start small and then just listen to the feedback and then iterate on that.

I will say this for listeners real quick, the issue that we’re talking through is a little visual, so if you wanna pause and go to the show notes, it’s issue 847, but we have a link on the show notes, you wanna go find that. You’ll be easily able to find that, so if you wanna pause and go find that, come back and start listening again, you can. But go ahead, Sid.

Yeah, I think it’s such a better experience if you build the smallest possible thing, but if you have to wait half a year for the next iteration, you’re not gonna built the minimal thing. As soon as you’ve got time for your feature, you’re gonna put everything you can possibly think of in there and request it, because it will be half a year before you can request anything else. In order to do small iterations, you need to get your cycle time down, otherwise your stakeholders will never agree with it.

So cycle analytics seems like it’s very much dependent upon comparing apples to apples. We talked about this development style - it’s idea to production, right? There’s your cycle. Some ideas are bigger than others and one of the things that I struggle with all the time, because we’re always trying to deal with the smallest thing as possible, but things tend to grow, as we all know. And it’s like, defining what is as a singular idea… This is bug fix - are we doing cycle analytics on this bug fix? And here’s an idea called a cycle analytics feature, which is a huge idea. How do we normalize these things so that the analytics are useful?

[01:00:08.25] I think the lesson is that if something is larger, you have to split it up. We have never found an instance where we could not make a smaller iteration. In GitLab right now many things – basically, everything has to ship in the same month you start on it. You start on it and you wanna ship with that release. Sometimes it’s only one or two weeks that you have left before it ships.

For example cycle analytics, I hope it will ship, but it was built in a month, and that’s because we didn’t do the whole thing we designed here, we did just the minimum thing. We could ship in those weeks that were left, and we’ve seen it even with very complex features. For example, we did issue boards; that’s like a whole extension of the product, and that took us two months; we’re not happy, we should have done it in one month; we can learn.

But I think if you add everything in there that you can think of, you’re easily spending more than half a year to ship something like that. The trick is you do the minimum thing… We shipped it last month, and this month we have all kinds of improvement, because people had like, “Oh, you can do this and that and this and that”, and splitting something up sometimes is hard; it depends on the feature, what it is, but the thing is that there is an incentive to make it smaller because you wanna reduce the time, instead of having the incentive to make it bigger because otherwise you have to wait so long. If the incentive is right, you can make everything smaller, and it seems counter-intuitive, but for us, we’ve always been able to do that, even with big things like rewriting, switching JavaScript versions and stuff like that.

The two final aspects of Conversational Development that you laid out and that you’re trying to achieve ability with GitLab are kind of related to Gatekeeper as a big part of the conversation, and the rest of the organization can contribute. Let’s just focus on the Gatekeeper for now.

Sharp tools are usually very specific uses, and so when we have a broad range of people using the same tools, so we go everywhere from the backend engineer using it, to QA using it, to product dev or the product designer, even to the stakeholder. You’re somebody in upper management, and you’re trying to bring all those people to the same conversation, to the same place, there are a lot of challenges there with user interface, with interaction, with workflows… Are you guys actually thinking about how you can build a single tool that works well for all these different stakeholders?

Yeah, we think that’s extremely important, and I’m sure that there’s still many things we can still improve, but I think that companies and higher management are getting more comfortable with using things like this. I mean, the popularity of Slack is an indication. That’s not just developers using that, that is multiple people in the organization.

For example in GitLab itself, our marketing team also works from an issue checker. It’s a public one, so I encourage you to check it out. They’ve been able to adopt that, but we’ve also learned, for example, they insisted that issues would have due dates, and all programmers were, “Yeah, just find the sprint and assign a due date to the sprint.” And they were like, “Well, that’s not how we work. We want the due dates also in the individual issues.”

[01:03:58.02] So we learned, we added that and I’m sure there is many other things we can improve in GitLab to make it easier to use, but I think that many people higher up now feel frustrated about the lack of control and the lack of information they have. They basically throw a whole a lot of demands in there, and then they have to wait half a year before it gets up. I think they’ll be delighted if they can give a big idea, work together to make it smaller and then have some output a week or two later.

One of the things that I’ve noticed about you and your team just as your announcements and products do make their way across Hacker News and other mediums (or media) is that you’re very receptive to feedback and feature requests, and you’re very quick to add something to your issue tracker or even say, “Oh yes, we’re actively working on this.”

I was thinking about even just your most recent post. It may have been Dmitriy in there, saying one of the requests is on issues on code review, which is a huge aspect for all of us - better code review tools, which I’m sure you guys are furiously working on… And one aspect is like, “Can I just batch up my comment and send a single notification?” Which is something Adam and I have complained about many times.

Yes, you have.

Especially as we use these tools to do editing of pros, so we have a bunch of feedback of something somebody’s written, and I have 17 things to say, and I just feel terrible as I’m going through saying those things, and I send 17 emails to somebody about specific grammars checks and stuff like that. And right in there, there was a comment from somebody on your team that said, “I just added that to our list of feature requests, sir. We’re tracking that and will consider it.” And that is very cool, and this desire to feed the entire organization a singular place to do the software development in, as a singular tool or set up tools, is very cool. Do you worry about feature bloat? Because if you do all the things, surely you may end up with too many things.

Yeah, so you don’t do everything that you have a feature proposal for it. There’s more than a thousand feature proposals, but what is important is to have a place to track everything. We’re very liberal - if you have an idea and it’s good, make an issue, so that we can discuss it. And many times from the issue we try to reduce it; like, what’s the minimum we can do? And the minimum not in minimum lines of code, but adding minimal technical complexity to the product. Like, can we do something without introducing another database table? Can we do something without introducing another model? Can we do something without adding more bloat to the interface? When it’s needed, yeah, make that extra database table of course, but what’s the minimum we can do so that we make it easy to extend the product in the future?

To do that, we need to have a conversation, and not only the initial author of the idea needs to chime in, also other users with their use cases, and in our case also our sales people. You’ll see comments on the GitLab issue tracker that says, “Potential client with 300 users is interested in this”, and then a Salesforce link which you guys can’t access but we can, that has more information about the client that wants that.

As a community, you can see what was requested, all the different opinions and then people start exploring, “Okay, what’s the technical impact?”, and depending on the demand and the complexity, the product managers make a decision to schedule it or not, or someone makes the code and then we’re there, then we’re forced to do a review, which is a great thing, and we can take it from there.

[01:08:07.02] Let’s talk about that best commenting feature. What are the odds? Come on, give us an answer… Let’s get that in there.

I saw that GitHub released transactional merge request comments - or they probably call it something else - today, so I’m sure that’s an inspiration not only to us as a team, but also to our community to start thinking about that.

That actually leads me into the question that I was just about to ask next, so thank you. Somebody mentioned that that specific feature was in Phabricator, and I believe you chimed in to the Hacker News thread because there’s a lot of good conversation there around the Master Plan, and whether or not people are bullish or bearish about your odds and all that fun stuff..,. But there’s a mention of Phabricator, which is another tool that is appraised. I’ve never used it, but praised for its code review. And you just mentioned GitHub made announcements, and it’s hard to miss those today if you’re on Tweeter in the software development scene, because there was people talking about it. How closely do you monitor your competitors and think about them in light of your product roadmap?

Well, obviously when they release new features, we pay attention and I try to encourage us to also give a more fair comparison between their product and ours. If they have a cool feature that we don’t have, we try to add it to our comparison page. In the end, the feature still has to stand on its own. It’s input to the conversation, but that is it.

You’re hearing some background noise here… We have a telepresence robot in the office and someone just came into the office just right now, unaware of course that I’m in the middle of a recording… So we asked them to check in half an hour from now.

But yes, I think we look at each other and it’s great to see; the inspiration is hopefully mutual and I think we can all learn from one another. Surely Phabricator has been an inspiration, but for example we released GitLab Issue Boards last month and now GitHub, who’s probably started working on this a long time ago, but they also released it.

In some parts we’re thinking in the same direction. I think where we differ is that we clearly see the value of a product that’s more integrated and has more convention over configuration, and it saves you a lot of time and clicking between different apps. I think that’s where we’re clearly going in different directions.

So Sid I got a hard question for you… A hard ball, so to speak, maybe we’ll say that. The question is - I’m not exactly sure the best way to ask it, but I’m thinking about the listeners who are listening on the show and are thinking back to what I said earlier, which how do I choose? How do I choose where to host my code? Whether I’m an open source developer, I’m a self-run shop, I work on a team, I work in an enterprise, I work on open source… How do I choose between GitHub, GitLab, BitBucket…?

We talked a bit about your business model. People use the word ‘winning’ and I think what the better word might be is ‘succeeding’, because I think that you can have an ecosystem of code host where you have all three of you and you all win, so I don’t think it’s about like you’re trying to beat any of these people, it’s just you’re trying to succeed at your own mission, which is obviously around this conversational development process and all these tools you’re building around that… But I think the question I’m trying to figure out here is for those listening - and I think it’s pretty fair to say that most of the audience that listens to this show is very familiar with GitHub. A little less familiar with GitLab, and that’s not saying that obviously you’re not succeeding or winning, so to speak, and then maybe even a little less familiar with Bitbucket, but very familiar with all three of you as code hosts.

[01:12:13.05] I think the question really what I’m trying to ask is in terms of your mission, in terms of what you’re trying to do, do you see yourself trying to win developers away from GitHub? Are you trying to like garner people away from Bitbucket? Is that how this enterprise game is being played - not so much your enterprise product, but just in general? Is that your plan to win or succeed, is it to take people away or is it to have people’s idea of how you develop software evolve, like GitLab is just a better solution?

Yeah, I think there’s a bit of both. Many enterprises are still not using Git, so that is an amazing market, but as far as strategy, it’s a public page, it’s on aboutGitLab.com/strategy and we have a sequence in there. And the first step is to become the most popular on-premise, so behind the firewall. We succeeded there.

The next step is to get the most revenue, so that’s why we’re expanding marketing and sales, because we wanna make sure right now 99% of GitLab organizations are using the community edition, and we would like to have a higher percentage being a customer. So we wanna add features to our Enterprise Edition to make it better; not without stopping to ship features in the open source edition, obviously.

Then the next step is having a better experience for private repositories, because we think that there are people that want to spend less time on integrating their tools and switching between tools. You can see in that Hacker News thread someone saying that, “It’s just awesome. You have one tab with your repo, one tab with your Docker containers, one tab with your deployment.” It’s a much better experience to have that all-in-one tool.

Give me a more direct answer to that. I think it’s really awesome that you have your strategy listed, and not so much just listed for those who may come to love GitLab and use GitLab as developers or development teams of software and products, but even your competitors. I think it’s just interesting to put that out there, wide open and say, “These are our goals. One is to do this, second is revenue”, or have the most revenue as you said; maybe a bit more direct - is winning developers away from GitHub, where a lot of open source community tends to gravitate towards? Jerod, we can even say this is part of Nightly, like we have an email called Changelog Nightly. Everything listed in there is a GitHub repo, none of them are GitLab repos. Is that part of your mission, to sort to win some of the open source community?

Yes. If you look at our strategy, point four is win over the open source repos, and we’re trying to… We’re making improvements already to the way open source projects like F-Droid, how we host them on GitLab and making sure that’s a great experience. But I think for the masses, we first wanna do point three. Because there is a big network effect to open source projects hosted on SaaS. For private repositories on SaaS that network effect is much reduced. It doesn’t matter that much where you host your own your project. If you invite a limited group of people, they can easily create accounts elsewhere or log into GitLab with their GitHub OAuth credentials.

[01:15:53.03] That’s why we have that sequence, and obviously those private developers are now hosting that code either on GitHub or on Bitbucket or someplace else; so we make great importers for Bitbucket, but our best importers are from GitHub. It transfers not only your repos, but also your issues, your pull requests, your labels, your milestones, and we want to make that an amazing experience. We’re getting more than a terabyte a day of new repos being created on GitLab, so we’re seeing amazing growth there.

One last question I guess on the enterprise side, especially since it’s the underpinning to your business model. So if this fails, it might just be yet another failed experiment? Or, I guess it’s probably a bad way to… I shouldn’t say it like that. But earlier in the show you’d mentioned donations, the early goals of trying to be sustainable, and so now your Enterprise Edition is the money maker; it’s paving the way, it’s providing the sustainable financing to do what you do for the open source, for .com, the free version… What can you share about the the lay of the land in terms of Enterprise edition or enterprise internal on-premise code stores? GitHub has their own version, Atlassian with Bitbucket has their own version, and obviously you have your Enterprise Edition. Who’s winning, what’s the goal there for you and I guess what can you share with the listeners about the outlook of the future for you on that front?

Yeah, I think we managed to become the most popular option there. Most organization that hosted there, they use GitLab. According to an article in a publication called The Information, GitHub first focused on individual developers, then focused on the enterprise; they went back to focusing on individual developers again. We have high confidence that these organizations will start consolidating on GitLab, and also previous generation solutions like for example Perforce - Perforce is shipping with GitLab to make that transition easier.

We think that we should keep listening to what these enterprise customers want, keep accepting and working with them to get their code changes accepted, and we can do a better job at promoting GitLab to the higher up, so that’s something we’ll do. Many developers have heard of GitLab, but when you get to the CIO level, we’re less known. We’ll spend more of our… There’s more money on marketing to those groups of people.

I’d like to go back to community real quick, if you let me…?

Do it, yeah.

Cool, because I had a thought about that, specifically around the point that Adam made with individual open source projects. GitHub is the de facto host for those things. We’d love to get GitLab into Changelog Nightly, by the way. We actually tried, but your API doesn’t quite expose the data that we need in order to track such things, and I know you’ve mentioned that your first goal is to get people contributing to GitLab open source, the product, the community edition, and then after that it’s gonna win the hearts and minds of individual developers. What are your plans for when you get to that point? How are you going to get the mind share? Because what you don’t have in the individual space which, like you said, you also don’t have quite at the CIO space, but you’re working on that, is the mind share of those people. Amongst the open source world of developers putting their npm stuff on GitHub, or their latest DotFiles are on GitHub, everything is on GitHub, so what possibly turn that tide? Because it’s pretty established at this point.

[01:20:02.02] Yeah, there’s a huge network effect there, and that’s why we’re not attacking it head on. We first wanna convince individual developers. I think as we grow more and more of our stack and of the modern software development lifecycle, I think that open source projects, at some point they’ll see that it’s just easier for people to contribute via GitLab. If you can press a button and then have a complete IDE, it makes it a lot easier to do a drive-by commit of a small thing you just found, instead of having to dig through the readme and install all kinds of tools.

That’s a really good point on drive-by contributions. We have a show called Request for Commits where we’ve talked extensively about onboarding contributors, graduating those contributors to people who contribute more than just once, but actually come back again and again and become established community members in that repo, but also just the allure of an easy… You make open source maintainers’ life so much easier when you make the drive-by contributions so much lower of a barrier to entry to do that. Because if I can go there and somebody just drops in a readme update, that’s great, but if I can actually launch an IDE, run their program, run the application or do whatever is necessary and dropping my wisdom, then it’s a lot more likely for me to potentially become a better drive-by contributor or even a community member of that project.

Awesome. Yes, if there’s anything we can do in the meantime… Of course, we’re not gonna do this serially; there’s a bit of parallelism going on. If we can extend our API to make it work better with your Nightly, then let’s talk about that and hopefully we can open an issue and discuss it.

We have an open issue, and we had a couple emails in to some people at GitLab; I’m not calling out, but we have a desire to make that work. So just so you know, we definitely have a desire. We didn’t go onto your issue tracker and create an issue, but we’ve made some steps to make that happen, and even the readers of Changelog Nightly have that same desire, so let’s definitely collaborate and make that happen, because I know it’s important to us, and it’s important to the community who reads that email every night.

For sure.

This is how we get all of our feature requests done, Sid; we bring people on the air and then we wait until the right time and then we shame them for not doing our features. [laughter]

We have a lot of open issues, but I see that the people who are patient and that are constructive, in the end they get it done. A great example was someone contributed an autoscaling CI runner for Kubernetes. If you run a Kubernetes cluster, it will automatically spin up as many runners to run your tests as are needed. And it took this person a year to get it in, so we’re not always doing great on cycle time. But in the end they got it in, and if I review it only… I think our team did great, this person did great. The only stupid person in that conversation was me not completely understanding Kubernetes a year ago. [laughter]

It happens. We all have our moments.

Right.

Yeah.

One last question as we kind of wrap things up, and I’m thinking about the end of all software development processes that we’ve talked about, this post-Agile world, and you trying to provide the one-stop-shop for everything you need for conversational development, cycle time is defined as ‘from idea to production’, and I know that you guys are introducing tools such as CI for a testing and for continuous deployment, but what about the last mile, so to speak? Do you have thoughts of “Just deploy with us”?

[01:23:53.18] Yeah, we wanna make the last mile better, and there’s a lot of stuff happening in the last mile. And one of the things that’s happening there is monitoring, and that’s getting more and more important. We’re learning that you cannot do continuous delivery right without also adding some monitoring. We’re excited to start shipping with Prometheus, working on that, and allowing you to monitor the apps you deploy with Prometheus.

If you’re hinting at that we also become a deployment platform, that’s not our ambition. I think what we’re seeing in the market is that there’s great container schedulers, and for example we can already deploy to Kubernetes, and that is just a great pathway to deploy your app. If you look at our scope on the direction page, you’ll see also what’s not in scope. We’re doing a lot, but that is the point where we hand it over to a production environment, and that we think that projects like Kubernetes, Mesosphere, Terraform Nomad are doing an amazing job there, and we want to work with them.

Very cool.

Well, Sid we have certainly kept you for a while, and listeners, I know we’ve gone over probably by a hair on this show… We had a great outline for this show; we knew we had a lot of catch-up, we had a lot of cover in terms of the Master Plan, but we also had some hard questions for Sid, which he graciously took and answered for us near at the end of the show, but couldn’t wrap the show without doing that.

Sid, here’s a chance I guess for you or for us to turn things over to you - is there anything that we haven’t asked you, any way or anything you wanna share back to the community right now that is just something that’s been on your mind and you have to say it before the show wraps up?

Yeah, I think you did a really good job of asking lots of questions. I hope that people will give GitLab a try and then when they find something they don’t like, they create an issue, or they search for issues and then voice their opinion, so we can keep improving the product; or even better, contribute some code to make it better. It’s over a thousand people contributing, and I think that’s the strength, and I think as a development community we can just build a better tool that we can use every day.

So one last one quick question for you, which is one of our favorite questions to ask. For those listening, they hear you say that now and they’re thinking, “Okay, I can contribute.” Can you give a quick guidance towards what’s the best way the community can step in and help this mission that you’ve described yesterday in your grand plan? What’s the best ways for people to step in? Is it stepping into issues, is it installing their own soft-hosted version of it, playing with the container? How can people best give back to GitLab?

Yeah, use it where you want - either the .com, or install it yourself, and then you’re gonna find a rough spot somewhere; or maybe our documentation is little off and there should be an example somewhere, or maybe there’s a feature missing, or maybe something doesn’t work in Safari. So create an issue or try to make some code.

We have a CONTRIBUTING.md file that walks you through contributing to GitLab, and we now have a Merge Request coaches, people whose full-time job is to help to get you over the finish line with your code.

I hope people will contribute and do all the awesome stuff. GitLab CI autoscale was contributed by someone external to GitLab; this new runner on Kubernetes is, again, an external contribution. They’re making all the awesome stuff and we’ll take care of the boring stuff, the security updates, the performance updates and the packaging.

Awesome. Well Sid, again, thank you so much for all you’ve done. I know this has been a long road for you. Everything from Applied Physics, to submarines, to now helping teams built better software through conversational development. I think it’s an awesome story that you have personally, but also corporately, as your company, GitLab. I think you’ve got a really interesting legacy and a really interesting dynasty that we hope to see blossom over these years. Any way we can personally support you as the Changelog, we’d love to do that.

[01:28:17.02] It was great having you on the show today. Listeners, thank you so much for tuning in today. If you have any questions for Sid…. Sid, where can people reach you at if they have any particular questions directly for you, or just in general? What’s the best way to reach out?

Only the best way is tweeting out. And feel free to tweet at both @GitLab and @sytses. Twitter is the mostly the faster path. Thank you so much for having me on. I hope to be back sooner than in three years, and thanks for all the kind words.

Yeah, sorry that it was actually three years. We like doing catch-up shows, and that this is definitely a long overdue catch-up show, and you’re unveiling of your Master Plan yesterday and our email to you last week to kind of coordinate this - it was perfect timing. We wanted to have you back on the show anyways, and what better time than when you’re sharing such an interesting perspective towards the future of where you’re going, so we definitely thank you for coming on this show so quickly too and work with us on that.

I agree. Good timing, good questions.

Yes, that is it. One more mention for listeners. You might know this already, because we’ve said this quite a bit - we have two emails. What we’ve mentioned was Nightly, and then the other one is our weekly email, so go to Changelog.com/weekly or Changelog.com/nightly. Pending some work with Sid here, we might actually get some GitLab projects in there, so if you have some open source in GitLab that is trending, then we might be including it in Changelog Nightly sometime in the near future. That is it for this show fellows, so let’s say goodbye.

Goodbye. Thanks, Sid.