The Changelog: Software Development, Open Source - GitLab's Master Plan (Interview)

Episode Date: September 16, 2016

Sid Sijbrandij, CEO of GitLab, joined the show to talk about their recent unveiling of the GitLab Master Plan, $20 Million secured in a Series B funding round, their idea of Conversational Development in this "post Agile world", and their focus on the enterprise and on-premise Git hosting as the business model to sustain and build GitLab into something 'modern software teams' can rely upon."

I'm Sid Sibrandi, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 220. And today, Jared and I have a huge show for you. Sid Sibrandi, CEO of GitLab, joins the show today to unveil the GitLab Master Plan, $20 million Series B funding, which is huge for them to help them go into the future. They've got the.com, which is totally free, the open source version, which everybody knows and loves, and also the enterprise on-premise that is funding the future. We talked about conversational development, all the tools they're building around this post-agile world development workflow. They're focused on enterprise and on-premise Git hosting as the business model to sustain and build GitLab into something modern software teams can rely upon. We have three sponsors today, Linode, Rollbar, and CodeSchool.

Our first sponsor of the show is our friends at Linode, cloud server of choice here at ChangeLog. Get a Linode cloud server up and running in seconds. Head to linode.com slash changelog to get started. Choose your flavor of Linux, resources, and node location. Plans start at just $10 a month. You get full root

access, run VMs, run containers. You can even manage your Linodes from the comfort of Terminal using Linode CLI. They've got SDKs in Python, Perl, PHP, Ruby, JavaScript, Node.js, so you can hack away on your Linodes with their API, take advantage of add-ons like backups, node balancers, DNS manager, and more. Again, use our code CHANGELOG20 for $20 in credit with unlimited uses.

Tell your friends. Head to linode.com slash changelog. And now on to the show. All right, we're back with a great show today, Jared. We got a show in the making. It's been three years and a day basically since we published the last anything on the changelog from GitLab. And 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 most interesting about GitLab these days, Jared? I think everything's interesting about GitLab. And in fact, Git hosting in general is heating up.

This is a huge week. Huge announcements from Sid's team, the GitLab master plan, GitHub universe also going on, and big new features coming out of github and as users of git and these services we just get a we just get all the goodies you know we level up use them and enjoy and that's right we level up and gitlab level up quite a bit huge announcement 20 million dollar series b funding is that right sid that's correct congratulations on that yes thanks for coming on the show big congrats yeah. Yeah, thanks for having me. So, Sid, it's been three years. So the last time we had you on the show, it was, I think, Enterprise Edition was just being announced.

You were announcing GitLab 6.0. This is like September 2013. So that means we 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. So I don't know how often you get a chance to share kind of where you began or who you are, kind of introduce yourself to the software development world, but 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. So 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. 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. So literally I examined every surface of this computer, trying to find out how to turn it on. I didn't really get into programming. It was too tedious, I thought. So I studied applied physics for a year and then did 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.

So 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 they want something else. So we made the submarines and we totally failed at our price point because we tried to make it for $20,000 and they now cost $2 million. We really, really tried to make them affordable. It's hard. That's funny. That sounds hard. They're great. And U-Boat Works is still shipping the most

submarines every year, which is a handful. So generally, it's a first for us to have somebody on the show that had been a applied physics for one. And we've never asked that uh you know that kind of background but then also to build submarines well said give us uh your your best takeaway what you learned building submarines that we can apply to the craft of software development well one lesson we uh we had to learn um and i think you can learn that in software as well is that um outsourcing to lower wage countries is not always a good strategy.

And another 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 want to be able to insure their submarine. So yeah, 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 basically computer board and programming a 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 that, 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. And 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 a collaboration tool is something you can contribute to, that it's open source. And I thought SaaS and dot coms 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. So Dimitri, 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. So what, I know you built submarines.

What, you know, what was, what made you want to be an entrepreneur? What made you want to be the person like 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 these websites that do 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. So the code was open source. And I ended up being the business person selling it. And that was in my first year and then applied physics had lots of difficult math. So I figured I liked the entrepreneurial side.

So I switched and I, uh, I, I started doing management science and I've, I've always, now that we run GitLab, I find out about myself that I have lots of opinions how companies should be run more effectively. I've done internships at some Fortune 10 companies. And yeah, I saw lots of inefficiencies. So 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. So I think that's where that business passion is coming in. Yesterday on the live event, just to catch up to listeners, GitLab had a live broadcast of their master plan,

which aired yesterday. That would be September 13th. And on that said, you, you said that the start of GitLab started off as an open source project and you came to it and, Sid, you said that the start of GitLab, it started off as an open source project. And you came to it. And remind me the name of your co-founder again? Dimitri. Dimitri.

And you told Dimitri, thank you, that you were going to take 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 little bit of a background and what you moved to from there? Yeah, so I thought all the money is in the SaaS, like Salesforce. That's what I read on TechCrunch.

So I emailed Dimitri, so, hey, Dimitri, I'm going to do, I'm going to try, I'm going to make money on this, and, well, I'm sorry, but you're probably not going to be part of this. I hope you don't mind. And he was like, wow, it's so amazing. You're doing something with GitLab and making it more popular. And of course, go for it. It's open source.

Do whatever you want. So that was really nice of him. But 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 5 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. But at the same time, Dimitri tweeted in a public tweet, I want to work on GitLab full-time. So that was easy. I contacted Dimitri 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 tried everything we tried donations we tried consulting we tried paid for development but none of these really seemed to work but being able 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 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 budget for.

Can we pause on some of the fails there? Like 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 work out. How do you kind of keep and maintain trajectory on that? Yeah, you have to keep an open mind.

Donations, Dimitri was already doing that. So the first thing was intensifying that. And I think the biggest drive we did, we got $1,000 in a month, which wouldn't even pay for Dimitri. And then it was a single drive. So keeping that up is 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. So it's becoming a better model, especially because Patreon is recurring. But it's hard to build a serious company and competitor out of it. 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 in the documentation and the open source project.

So very quickly, people didn't need consulting anymore. And of course, this is how it should be. It should be very easy to install GitLab. And our open source edition, it's 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 of minutes. And we figured that the project would never become popular if we would make it hard to install and then pay us for the 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. Like 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. So 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 want to 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 figure they 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? So this made it really hard to pull off that model. 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 kind of 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 that's what it branched out.

So 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 it will it will we're working to to a more complete version we'll probably uh talk later about doing the whole software development lifecycle. Yeah. So that's it. All those parts are in the open source version, which you can run without limitations. And over 100,000 organizations run that. It's the most installed and the most popular behind the firewall way to use Git.

And we also have an enterprise edition that contains features that you're more likely to need if you're over 100 people. And 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. So we made the conscious decision to give away everything on.com and make it completely free. So on goodlab.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. And right now, even the CI is free. So you can have as many parallel CI runners as you want on your private project and will even pay for that. So those are the three products that we offer. So the only difference there is perhaps you want for privacy or security concerns, you 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 a firewall. And there are different reasons. Some of them are security related. They want it behind their VPN service, 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 need it on their own servers, or they need to know where exactly in what 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 of existing infrastructure to integrate with and don't want to poke a lot of holes in their firewall. It's more performant if it's on their local network. And that was a surprising thing to me. I thought that everyone would 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 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 100,000 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. So we think the way to do that is that there's 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. So if you can get them to adopt your product, you'll do a lot better. And GitLab was born in the enterprise. Dimitri and Valeri were working in an organization with more than 200 people. And those customers that were asking for features in our 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 said. We're bumping up against our first break. 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,

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? Yeah. So in March of 2015, one and a 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 were standardized on GitLab. And we recognized that it has to be a complete product and that we have to have great marketing and sales to do that.

However, since the beginning, we've been a remote company. So I anticipated having to hire locally in San Francisco. We got an office there and the first salespeople came to the office. 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. And 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 work from home too. I like to not be interrupted. I like to have flexibility in my workday.

I like the ability to travel where I want to travel. So I never made them and we kept that going. So by now we're over 100 people. We're on six continents. We're in 33 countries. And basically everyone works from another location and from the location they want to work from the only exception is that sometimes our executive assistant comes 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? Yeah, there's someone who remarked in our company, he just bought a lot of generators. So maybe he's ready for Antarctica. There you go. Go back to your roots with applied science or applied physics and submarines. Yep. Maybe we should have a station there.

It would be a nice perk. But no, it's the hardest thing to make work is time zone. So it's location is nice. It's also nice to hang out together from time to time. So 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. So we have a call every 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, where you 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 a team. And we're doing, I think, a great job at that at that people feel closely connected even to people that are living on another continent well to do remote work you definitely have to bake it into who you are that's for sure because there's 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 or a you know how the message has to be distributed through the organization is always like, well, is this person local or remote?

And it's always this fragmented communication pattern. And so being all in, having your DNA or 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. Yeah. It does fail. It will fail. You always feel like you're a secondary citizen and, 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. Yeah. 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 like over-communicate. For example, today in our team call, I shared our management notes. We had a two-day, we call it the remote offsite. It 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're 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 the 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 all the formal things. All right, let's take our first break. On the other side, 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. GitLab's just announced master plan and what that means for the present and future of the product. We'll be right back. Hey everyone, Adam Stachowiak here, editor-in-chief of Changelog. And I'm talking to a Rollbar customer. Rollbar puts errors in their place. Rollbar.com slash Changelog. Check them out. Get 90 days of the bootstrap plan totally for free. I had a conversation with Paul Bigger, the founder of CircleCI, and he talked deeply about how they use Robar and how important that tool is to their developers. Take a listen. One of the key parts about doing continuous delivery, you don't just have to test your software, but you have to constantly keep track of it. You're going to be doing deploys 10 times a day or 20 times a day.

And you have to know that each deploy works. And the way to do that is to have really good monitoring. And Rollbar is literally the thing that you need to do that monitoring. You need to make sure that every time you deploy, you're going to get an alert if something goes wrong. And that's exactly what Rollbar does for CircleCI. So obviously CircleCI is important to your customers. You shouldn't have errors. You shouldn't have bugs. And the purpose of a CI is continuous delivery, obviously,

but getting your customers' code to production in a fast manner that's tested and all the necessary things a CI provides. Tell me how important Rollbar is to your team and your organization. We operate at serious scale. And literally the first thing we do when we create a new service is we install Rollbar in it. We need to have that visibility. And without that visibility, it would be impossible to run at the scale we do. And certainly with the number of people that we have. We're a relatively small team operating a major service.

And without the visibility that Rollbar gives us into our exceptions, it just wouldn't be possible. Oh, that's awesome. Thanks, Paul. I appreciate your time. So listeners, we have a special offer for you. Go to rollbar.com slash changelog, sign up, get the bootstrap plan for free for 90 days. That's 300,000 errors tracked totally for

free. Give Rollbar a try today. Head over to rollbar.com slash changelog. All right, we are back with Sid C. Brandage talking about GitLab and the just announced master plan. Sid, you 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 to 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, it got replaced by Scrum, which was a great improvement. But you still had to estimate every 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. And 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 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. And there's five main points in there. We want to reduce the cycle time to increase effectiveness. And the cycle time we measure,

the time it takes from having an idea to having it in production and any anything that impedes that should be measured and you should try to do it more quickly so many large organizations now they take many months to between having an idea and then having the code out there for users. And we think that should be days. And to do that, that's the second thing. You need to monitor the process. So you need to know how long every step takes. And the third thing is you want to track the conversation through all stages.

So when you deploy something, when you get something out to users, you want to be able to go back and see where did this idea originate. You want to make sure all these steps are linked and that you can have a conversation that is supported by your tooling. Fourth is that gatekeepers become part of the conversation. Where it used to be that, for example, a security audit was a step that was kind of a holdup. We think instead, these people should be involved. So they should be invited to contribute. And by deploying, 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, you make it open to other teams. And if they want to reuse your code, they can rest assured that they can forward the project and contribute back to it. So you can reuse the same code base. And we think that the biggest benefits are in reducing the cycle time. It's simply that shipping smaller and simpler changes is more effective. And it's effective in lots of ways. It's more in line with expectations. It's easy to coordinate.

The code review is of a higher quality. It's easier to troubleshoot. And it prevents gold plating, like overshooting needs. Apart from that, if you reduce the cycle time, you have more frequent interactions, like more users get exposed to your code and give you feedback. You're quicker to respond. There's a higher predictability. There's more of a sense of progress in your team. So we think that this is what everyone and especially large organizations need to become more effective. Well, as you're talking through these, I'm just kind of applying those to our own process here, Adam, because I guess I'm narcissistic or something. And we're a tiny little team. But when I think about cycle time, maybe two to three people involved in software development.

And I guess we feel like it's pretty fast cycle time, but we don't really have the monitoring. Your 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 is where a tool, I mean, I'm sure a tool could help with monitoring,

of course, as well. But a tool, which is kind of part of your plan as you're going to unfold is this like 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 Slack, we have GitHub issues, we have Trello. And, you know, half the time we spend trying to find it. Envision. Envision. We have Google Docs.

Sometimes it ends up in a Google Doc. Brainstorming or it's in my notes app, just locally on my computer. And half the time we spend trying to find things that we've. Where we put that idea at, we say, haven't we had this conversation before? And we go searching 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, where you include, you know, the last two points, the gatekeeper and the rest of the organization. How many times, I'm not sure for you, Jared, but I've experienced this

when I worked at Pure Charity, where we would invite people in quotes of what we called the business side of things. We would invite them into the process and essentially ask them, because we host it on GitHub, we would invite them into the GitHub organization to monitor issues and track things. And, you know, these things have obviously evolved since then, but we invited them into the, what is typically as Sid is sharing here, like what's typically shown as, as Agile, which is around just the development cycle.

Whereas Sid, and correct me if I'm wrong, but I think what you're doing is you're, you're, you're sort of like zooming out quite a bit to say, how does product get made from idea to delivery and how can we provide the tools necessary for collaborating around that? Whether you're a 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? And that's, that's, to me, that's pretty interesting. Awesome. Yeah. And it's, to me, that's pretty interesting. Awesome.

Yeah, and it's exactly as you described. And to make that a bit more, to give a practical example of how that could look, many times ideas start in a chat. Like we ship with Mattermost, but many people use Slack. And we want to make sure that those ideas don't die. So we're going to ship it something that allows you to say, create an issue of the last 10 comments

I made. And then that issue should end up on a planning board. So 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 want to make a small contribution, that changes a lot of things. That makes it easier. And another thing, like Google Docs, we also use it extensively. I've been thinking I would really love

if the description field of issues and merge requests was a real-time document. So I 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 tool chain. And if you have it within one data store, you can do the trading a lot better, but you can also do the feedback, like where's stuff getting stuck. Preston Pyshke You know, I think part of this conversation for us to have you back on the show is kind of three

parts. And this is how I look at it. Like it's a catch up show because we us to have you back on the show is kind of three parts. And this is how I look at it. Like 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 kind of differentiating what GitLab is as a Git code repository code source, which in a lot of cases over the years you've been very closely compared 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 talking

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. Yeah, 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 Dimitri started making GitLab CI a couple of years back, I was like, no, let's focus on the code hosting. There's so much left to improve. But he, as a co-founder and original offer, he can do as he pleases.

And he reached this on. He's got the code editor. Yeah. And it turned out he solved, by integrating it closely with GitLab, it was a much better experience. It was easier to set up. It was easier to get started with.

And then the push came to, 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. Like, what are you doing you're making a monorail out of this um the a monorail as in a a huge rails app this is not this is not 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 and we integrated it and it's so it's a so much better experience. And 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 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, it's running their project and can push the containers to there.

So it's a better experience. And that was counterintuitive to me. I like the Unix philosophy, you had one tool, there's 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 pushups that you now have to do. And I can't compare GitLab to the genius of Ruby on Rails, but I was greatly inspired by convention over configuration. And I still think there's a lot of needless configuration in many developer pipelines, and we want to take that away. If you want to go fully GitLab, it's going to be an amazing experience. If you want to use other tools, that's fine too. We'll play nice with Slack, with great Jira integration.

We have a commit status API for Jenkins. We'll play nice with other tools, but we're going to save you a whole bunch of time to make this idea to production happen i think that's the key right there because you know the doubts in my mind as you're talking is is whenever you have you know when you lose that focus like you said and i do believe in integrated uh products for sure when done right and there's therein lies the risk is you know providing everything you need for this style of development there's many tools

involved and i know you guys have laid out kind of a 10 stop or a 10 step thing where some things you provide some you don't yet but you're planning on on it is that if i if you have 10 things you need to provide for an integrated solution and i 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 know, you you've lost me because now it's, it's a, it's a one-stop shop.

So it's all or nothing, but it sounds like there, there still is opt out type of, uh, you know, a la carte style planned for this as well yeah we we want to convince you that it's a better experience but we don't want to force you so you can use just gitlab for code hosting and code review and that will work fine but if you right now we have we identified 10 stages, and eight of those 10 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 ships with repo management to commit your code. It ships with CI. It has the code review. 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 want to 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 Kog from Operable. And then last but not least, the feedback. This month, we'll ship the first iteration

of Cycle Analytics that will start giving you feedback about how long it took you to get from idea to production. And so we're very close to shipping all 10, 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 by better integrating them. So fewer clicks. Right now, we ship with coding and online IDE, but it's still a couple of clicks to set up the project.

And what we want is if you look at an open source project and you like it and you want to 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. And to get there, we're going to invest a lot of time and resources to make that an awesome experience. Let me lay out the 11 points, I guess, is what it ended up being in your talk slash live stream yesterday. So 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 chatbots. 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 10 was ease migration from legacy systems and point 11 was whatever you contribute and our customers request so that was the point you kind of made in terms of this one-stop shop but when we break things down like 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 that 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 want to reuse the best solutions that are out there. So we have no plans to make something ourself or to do something else. Coding, we were in a conversation with coding and and we were so much aligned on the vision for the future that they decided to open source 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.

So now the real work has started of making that easier. And that's where our focus is. And I think that that also goes for Mattermost. Although Mattermost, the integration is deeper. It ships by default with GitLab. The OAuth authorization is completely integrated. But there's more we can do.

And it's a project that will never be completely done. But the things you 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 something else you said there too and i'm not sure if i just heard it right

did you say cog was it a product called cog that you're integrating exactly what is that cog um you might have heard of ubot um it's a chat ops client and chat ops is something that allows you to say for example example, deploy staging to production. It will take whatever is on staging now and deploy it to production. Dubot was a great innovation there. But the people of Kog try to take it one step further. And what they're doing that I think is great, they have permissions, user-based permissions at a much deeper level in the product. Because with many chatbots today,

you don't really have privileges. As soon as you can access the chatbot, you can do everything. And for many teams, especially these larger 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. Many of our customers, that's not acceptable. So Kog splits it up into a coordinator and individual script. Those run on different containers.

And an additional advantage, you can use the programming language that you like. 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. So we think they're onto something. It's still early. It's still hard to use right now, or it's still 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. Kog is very cool.

This had not crossed, I guess I can say Adam's radar either, but definitely not my own. And so as you talk, we are linking it up in the show notes and checking it out on their 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 as you get this thing integrated. That's part of that collaboration to make it better. Yeah. Sid, one of the points in your focuses for the next year or so is version control for everything. And I believe that means large files. But I'm wondering if that also has any vision towards versioning things 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.

So an example is large files. We think GitHub did a great job with Git LFS. Right now that's an extension. We'd love for it to be included in the Git binaries basically so 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 div, you basically want probably, sometimes you comment about the whole image, but sometimes you want to comment about a specific part. And I think we can do a better job of allowing that. So that's a feature we want to ship. Very cool. Any thought on 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 data sets. I know that's popular in scientific communities as well as a few others. But any thoughts towards that in terms of bringing data into the product development lifecycle? I think it's a very

interesting subject. And there's a company called Pekider that is doing great work there where they're trying to bring like the version control of Git to the Hadoop space,

basically. And they're doing amazing work there. We don't have any plans at the moment. But what we like is that because GitLab's 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 base their project on a fork of GitLab. And we try 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 really interesting to learn a lot about this idea of conversational development. I know that this is a kind of an extension to Agile. And we all know your passion for that, Sid. So it's just kind of interesting to kind of dive through each of these points and ask a ton of questions I'm sure we've got tons more but we're a break here real quick and when we come back when you dive a

little further into some of these points 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. So we'll break and we'll be right back. If you want to learn something new, a proven method is to learn by doing. And that's exactly the way CodeSchool works.

You learn to program by doing with hands-on courses. Their courses are organized into paths based on technologies like HTML, CSS, JavaScript, with hot topics like React and Angular, Ruby, Python, .NET, iOS, Git, databases, and even electives that take you off the beaten path. You can try before you buy with free introductory courses like Git, Ruby, Angular, iOS, and more. And you get to play full courses with coding challenges so you can get the hang of things. There's a path for everyone at CodeSchool.

Head to codeschool.com to get started and learn by doing. All right, we're back with Sid, and we're talking about the master plan of GitLab. And Sid, I think it's awesome, too, that you guys did this live stream. You did it in a pretty good fashion, too, except for the unmuted mic during the demo. Pretty much a stellar performance. I think it was pretty awesome. But it's a great way, too, to communicate to the community what you're doing.

And 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, right?

And you talked earlier about being able to track and the cycle timeframe and all this different stuff. But can you expand on what you mean by cycle analytics and how those who may not be using, since it's a new paradigm, you're creating this conversational 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 Postgres. So even though we ship it Mattermost as a chat 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. So it will show you, okay, 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 IDE, 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 a 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. So 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. And this is very new and we'll ship the first iteration of Cycle Analytics this month on the 22nd of September. But I think it's going to be really interesting. And I think, for example, that many companies will find they plan something and then it takes a really long while before they can start 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 the quarter beforehand much better what you need next quarter

than half a year ago? So those are the types of conversations we want to enable in Teams. And yeah, we look forward to people using that and, and improving it and, and starting to reap the benefits of reducing that time and having that sense of progress and getting, getting more information and being able to respond faster. Can you, can you share a bit about what the interface might be, or just sort of like what the user might see in terms of what this is?

Is it, is it reporting? Is it something that somebody has to be interactive with? Or is it simply like a, you know, algorithm searching your data set and pulling back some, you know, 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. And to describe it to the listeners, at the top, was, what the 95th percentile time was. So it took you seven days to plan 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've, you know, we're about to ship something or we're actually beginning to plan for it.

You know, planning and talking about something is two different things. And it would be interesting to see, 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. And so it'd be interesting to see that auto contrasting back to like, here's when we really talked about it, here's when we begin to plan it, and here's when we shipped it. Yeah. And I think people will learn that the only way to get it down is to ship smaller things. So the picture you're looking at will not be our first iteration of cycle analytics. We'll ship only the minimum, minimum product first and then iterate on it. And 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. So it's much better to start small and then just listen to the feedback and then iterate on that. I was going to say this for the listeners real quick. The issue that we're talking through, it's a little visual.

So if you want to pause and go to the show notes, it's issue 847, but we have a link in the show notes. If you want to go find that, you'll be easily be able to find it. So if you want to pause, 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 or two

for the next iteration, you're not going to build the minimal thing. As soon as you got time for your feature, you're going to 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. So 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. I mean, we talk 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, of course, we're always trying to deal with the smallest things possible, but things tend to grow, as we all know.

And it's like defining what is a singular idea. You know, this is a bug fix. Are we doing cycle analytics on this bug fix? And then here's an idea called, you know, a cycle analytics feature, which is a huge idea. How do we normalize these things so that the analytics are useful?

I think the lesson is that if something is larger, you have to split it up. And we've 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. So you start on it and you want to ship with that release. Sometimes it's only one or two weeks that you have left before it ships. And 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. So 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 to do the minimum thing. And we shipped it last month. And this month, we have all kinds of improvements because people had like, oh, you can do this and that and this and that. And splitting something up sometimes, it's hard. It depends on the feature, what it is. But the thing is that there is an incentive to make it smaller because you want to reduce the time instead of having the incentive to make it bigger because otherwise you have to wait so long. So if the incentive is right, you can make everything smaller. And it seems counterintuitive, 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've laid out and that

you're trying to achieve, you know, ability with, uh, GitLab are kind of related. The gatekeeper is a big part of the conversation and the rest of the organization can contribute. Let's just focus on the gatekeeper for now. Um, tools, you know, sharp tools are usually very specific uses.

And so we, 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. There's 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 interactions, with workflows. Are you guys actively 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 think 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 tracker. It's a public one. So I encourage you to check it out. 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 the programmers were, yeah, just plan a sprint and assign a due date to a sprint. And they were like, well, that's not how we work. We want the due dates also in the individual issues. So we learned, we added that. And I'm sure there's 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 lot of demands in there, and then they have to wait half a year before it gets out. 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 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, you know, we're actively working on this. I was thinking about even just your most recent post. It may have been Dimitri in there saying one of the requests is about on issues on code review,

which is a huge aspect for all of us is 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 comments and send a single notification, which is something Adam that I've complained about many times, especially as we use these tools to do editing of, of pros. So we have a bunch of feedback on 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, you know, specific grammar checks and stuff like that. And right in there, there, there was a comment from somebody on your team that said, I just added that to our list of feature requests, or, you know, we're tracking that and we'll consider it. And that is very cool. Then this desire to like feed the entire organization, a singular place to do the software development and a singular tool or set of tools is very cool. Do you worry about feature bloat?

Because if you, 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. So there is more than a thousand feature proposals. But what is important is to have a place to track everything. So we're very liberal.

If you have an idea and it's a good, make an issue so we can discuss it. And many times from the issue, we try to reduce it. What's the minimum we can do? And a minimum not in minimum lines of code, but adding minimal technical complexity to the product. Can we do something without introducing another database table? Can we do something without introducing another model? Can we do something without adding more blow 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? And to do that, you need to have a conversation. And not only the initial offer of the idea needs to chime in, also other users with their use cases. And in our case, also our salespeople. 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 that you guys can't access, but we can, that has more information about the client that wants that.

So 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 and then then we're there then we're forced to to do a review which is a great thing and and and we can take it from there well let's talk about that batch commenting feature what are what are the odds come on give us a we's get that in there i i saw uh that github released uh released transactional uh merchant request comments or they probably call it something else today so i'm i'm sure that is an uh that's an inspiration not only to us as a team but also to our community

to start thinking about that that's a that actually leads me into the question I was just about to ask next, so thank you. Somebody mentioned that that specific feature was in Fabricator, and I believe you chimed in. We'll link 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 Fabricator, which is another tool that is praised. I've never used it but praise for its code review and you just mentioned github you know made announcements and it's hard to miss those today if you're on twitter in the software development scene because there was people talking about it how closely do you monitor your competitors and you know 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. So 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 so like it's it's input to the conversation um but that that is it and 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 a record in the middle of a recording so we asked them to to check in half an hour from now but yeah i think uh we look at each other and and it's great to see like the inspiration is is hopefully mutual and uh i think we can all learn from one another. Certainly Fabricator has been an inspiration,

but it's, 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. So 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 setup time and clicking between different apps. So 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. Please do.

And the question is, I'm not exactly sure the best way to ask it, but I'm thinking about the listeners who are listening to this show and they're thinking back to what I said earlier, which is, you know, 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 enterprise, I work on open source developer. I'm a self-run shop. I work on a team. I work in 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 hosts 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 listen 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. And I think the question really I'm trying to ask is, in terms terms of your mission in terms of what you're trying to do are you trying to

do you see yourself trying to win developers away from github do you see people are you trying to like garner people away from bitbucket is it this is that how this you know 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 that GitLab is just the better solution? Yeah, I think there's a bit of both.

And so many enterprises are still not using Git. So that's an amazing market. But as for our strategy, it's a public page. It's on aboutgitlab.com slash strategy. And we have a sequence in there. And the first step is to become the most popular on-premises. So behind the firewall. We succeeded there.

And the next step is to get the most revenue. So that's why we're expanding marketing and sales, because we want to 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 want to add features to our enterprise edition to make it better, not without stopping to ship features in the open source edition obviously and 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. And you can see in that Hacker News thread, someone saying that it's just awesome to 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. So give me a more direct answer to that.

And 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. The second is revenue or have the most revenue, as you said. Maybe a bit more direct is winning developers away from GitHub, the open source world. A lot of the open source community tends to gravitate towards GitHub.

It seems like, and Jared, we can even say this as part of Nightly. 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 of win some of the open source community? Yes. So if you look at our strategy, point four is win do away open source projects like F-Groid, how we host them on GitLab and making sure that's a great experience. But I think for the masses, we first want to do point free 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 projects. It doesn't matter. If you invite a limited group of people, they can easily create accounts elsewhere or log into GitLab with their GitHub OAuth credentials. So that's why we have that sequence. And obviously, those private developers are now hosting their code either on GitHub or on Bitbucket or someplace else. So we make great importers.

For Bitbucket, our best importer is for 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. And 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, you know, it might just be yet another

failed experiment, or I guess it's probably a bad way to say it. I shouldn't say it like that. But in earlier in the show, you'd mentioned, you know, donations, the early goals of trying to be sustainable. And so now your enterprise edition is, you know, is the moneymaker. It's paving the way. It's providing the sustainable financing to do what you do for the open source, the.com, the free version. What can you share about the lay of the land in terms of enterprise edition

or enterprise internal on-premise code stores? GitHub has their own version. Atlassian with Bitb? 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 listeners about the outlook of the future for you on that front?

Yeah, I think we managed to become the most popular option there. So most organizations that hosted there, they use GitLab. And according to an article in a publication called The Information, where GitHub first focused on individual developers, then focused on the enterprise. They went back to focusing on individual developers again. So 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. So 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 ups. So that's something we'll do many developers effort of GitLab, but when you get to the CIO level, we're less known. Um, so we'll spend more of our, uh, more money on marketing to those, uh, those groups of people. Well, so that's really, I'd like to go back to community real quick, if you'd 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 Change.log 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. 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

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 kind of win the hearts and minds of individual developers. What are your plans for when you get to that point? Like, how are you going to get the mindshare? 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 mindshare of those people. So amongst the open source world of developers,

putting their NPM stuff on GitHub, or their latest, their.files on on github or their latest their dot files are on github everything's on github so what could possibly turn that tide because it's pretty established at this point yeah so there's a huge network effect there and uh that's why we're not attacking it head-on but we first want to convince individual developers. But 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 detritusly 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 and the easy of you make open source maintainers live 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 simply just drop in a readme update, that's great. But if I can actually launch an IDE, run the program, run the application, or do whatever's necessary and drop in my wisdom, then it's a lot more likely for me to potentially become a better Dropbox contributor or even a community member of that project. Awesome. And yeah, if there's anything we can do in the meantime, of course,

we're not going to do this serially. There's a bit of parallelism going on. And 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. Well, we have an open issue and we had a couple emails into some people at GitLab. I'm not calling you 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 Change All 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, is we bring people on the air and then we wait till the right time and then we shame them for not doing our features.

Yeah. 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. And a great example was someone contributed an auto-scaling CI runner for Kubernetes. So 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, the 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. It happens, you know, we all have our moments. One last question as we kind of wrap things up, and I'm thinking about the end of all software development processes, as we talk 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 you know from idea to production and I know that you guys are introducing tools such as CI for testing and and for you know continuous deployment but what about the kind of end the last mile so to speak have you have thoughts of you know just deploy with us yeah we want to make the last mile better and to speak? Have you have thoughts of, you know, just deploy with us?

Yeah, we want to make the last mile better. And there's lots of stuff happening in that last mile. And one of the things that's happening there is monitoring. And that's getting more and more important.

And we're learning that you cannot do continuous delivery, right? Without also adding some monitoring. So 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 we think that projects like Kubernetes, Mesosphere, Terraform Nomad are doing an amazing job there. And we want to work with them. Very cool. 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 ketchup. We had a lot to cover in terms of the master plan,

but we also had some hard questions for Sid, which he graciously took and answered for us here at the end of the show, but couldn't wrap the show without doing that. But Sid, this is a chance, I guess, for you, for us to turn things over to you. Is there anything that we haven't asked you anyway or anything you want to share back to the community right now that is just something that's been on your mind that you have to say 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 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 developer community, we can just build a better tool that we can use every day. So one last quick question for you, which is one of our favorite questions to ask, which is just, you know, for those listening,

you know, 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, you know, in your grand plan? What's the best ways for people to step in? Is it, is it stepping into issues? Is it installing, you know, the, their own self-hosted version of it,

playing with a container? Like how can people best give back to GitLab? Yeah. Use it, use it where you want either the.com or install it yourself. And then you're going to find a rough spot somewhere. And maybe your documentation is a 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 to contributing to GitLab. And we now have MergerQuest coaches, people whose full-time job it is to to help to get you over the finish line with your code and uh i i hope people will uh will contribute and and

and do all the awesome stuff like git lab ci auto scale was contributed by someone external to git lab this new runner on k, again, an external contribution. So 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. Preston Pyshkoff Awesome. I'll say it 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 build 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, you know, blossom over these years. And anyway, we can personally support you as the changelog. We would love to do that. So it was great having you on the show today. But listeners, thank you so much for tuning in. 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? Probably the best way is tweeting out. Feel free to tweet out at both at GitLab and at S-Y-T-S-E-S. Twitter is mostly the facet path. And thanks 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. I mean,

we've actually, we like doing catch-up shows and this is definitely a long overdue catch-up show. And your unveiling of your master plan yesterday and our email to you last week to kind of coordinate this was just like, this is perfect timing. Like we wanted to have you back on the show anyways. And what better time than when you're sharing such a interesting perspective towards the future of where you're going. So we definitely thank you for coming on the show so quickly too and work with us on that. So. I agree. Good timing. Good questions.

Yes, that is it. So one more, one more mention for the listeners. You might know this already because we say this quite a bit, but we have two emails. One we mentioned was nightly and then the other one is our weekly email. So go to changelog.com slash weekly or changelog.com slash nightly. Pending some work with Sid here, we might actually get some GitLab projects in there. So if you have some open source on GitLab that is trending, then we might be including it in ChangeLog Nightly sometime in the near future that is it for this show fellow so let's say goodbye goodbye thanks ed goodbye thanks guys Outro Music