 I think I'm going to do a bit more questions, so I'll go to my presentation, I'll end the questions. Thank you so much for coming. I'm very glad to see so many faces, familiar faces, and new faces. Thanks for coming on a Tuesday night. We're very excited to have this meeting here in San Francisco about gift lab. I'll be talking for about 20 minutes about the growth of our team, our mission and product, our adoption so far, our milestones that we achieve. I'm going to present some cloud-native slideware. I'm going to talk about the SIT shuffle, and we're going to have a Q&A session at the end. So gift lab is an open source project started in 2011, but the first time that we physically came together as a company was in 2014, and as you can see it was quite exclusive. The second time was during a recombinator in Mountain Cube, and nine months later we brought the whole company together in a canal house in Amsterdam, and it was quite cramped to fit everyone in. Our fourth site was in Austin in May of 2016, so that was half a year ago, and since then, since half a year ago, we doubled the size of our team. We now have 160 team members, and we just had our fifth summit in Cancun, Mexico. So that's not gift lab because gift lab is way bigger than the team I just showed. More than 1,500 people contributed to the core of the piece, and many more have helped by spreading the word about gift lab and helping people with questions. Over 100,000 organizations are using gift lab currently. So they are all helping with our mission, and our mission is to change all creative work from read-write, from read-only to read-write so that everyone can contribute. Gifts change software by making contributing something that you did have to be invited for, but something you could do as soon as you have completed. And we want to make it easier to collaborate on software and will not stop there. Now many parts of our culture are not open to suggestions. So we strive to make every book, every movie something that's open to collaboration because culture evolves much rapidly when you can stand on the shoulders of other people. So to realize our mission, we're taking it step by step. And the first step we already took, we already became the most popular self-hosted gift solution. Now the second step is to become the gift solution that generates the most revenue. So that's what we are currently working at. And that will allow us to finance the rest of the journey. The next step would be to convince people to host their private projects on GitLab.com. And in the end, we wanted people to use GitLab to host their public projects, but there's a strong network effect there, so it's going to take a lot of time to get there. And our big, hairy, audacious goal is to make sure all creative work is made with GitLab. Right now we focus on step two, but because GitLab is open source, companies like Handflip and O'Reilly are already using GitLab to make collaboration looks easier. And we look forward to people using leveraging GitLab to work on other media formats. So we think GitLab is a better experience for making applications because it's an integrated set of tools. With GitLab, you get one package which makes it easier to install. It's one configuration, it's one convention, one interface, one license, one data store. So one data store means we can show complete analytics to you. And we use the same code base for a .com product and a product you download. So although it's integrated, we want to convince people to use GitLab for all things, not force them. So we'll always have great integrations with tools such as Jenkins and Jira and Slack. But we think an integrated set of tools allows you to perform the complete product lifecycle in GitLab and we think that's a better experience. So if you download GitLab, you get MetaMOS to chat. From chat, you can create an issue. That issue, you can plan with an issue board and like travel. You can code from GitLab. You can start a web terminal. You can commit that code in a repository. It will run CI for you. It will run a container registry where you can commit your container. Then it allows you to review your code. It has merge requests and it has something called review apps. So review apps are your apps spun up at the state of the merge request you're sending. So you're proposing a code change and straight away you can see how that code change influences the application because you've got a copy of the application spun up in that state. Then we want you to go further, deploy to GitLab and we recently launched something called AutoDeploy. AutoDeploy allows GitLab to figure out what kind of application you're pushing and deploying in. So it's kind of like a Roku except that it's completely open source. So you can run it yourself. You can run it on a container scheduler and there's an upgrade path. If you're no longer happy with the default AutoDeploy, you can modify it to add all the other functionality because it's open source and you can contribute to it. Then you want to deploy to production. You have complete chat upstairs, GitLab. Then the last and one of the most important steps is getting your feedback. So GitLab ships with something called Cycle Analytics. Cycle Analytics allows you to see from when I had an idea to when I deployed it, how long did that take because we think that's the most important thing to improve in a company. And reducing the time from idea to production. And GitLab can give you feedback about that. And then the most recent thing we ship is Prometheus. It's a monitoring technology. And with that we can see where are the applications we deploy, how they are acting and whether it was an improvement. So we figured out that if you do continuous deployments, if you deliver your software continuously, you also need feedback whether you're meeting your surface level objectives. And we can only do that if we have monitoring in GitLab. So that's why we're now shipping with monitoring technology. So this is the vision we presented this summer in June when we were fundraising. And at least three investors said we couldn't ship the complete idea to produce some lifecycle this year, last year, 2016. So we're very glad that we did manage to ship it. December 22nd, all these parts ship. And I think looking back in 10 years, people will think it's strange that this lifecycle used to require many different tools before we integrated them. So we're very thankful for all the customers that believe in us. Here's a selection of the 400 customers we've added in the last quarter. But even more important are that our existing customers are happy with GitLab. So at GitLab right now we've retained 98% of our customers. And after a year they spend 75% more money with us. And that's important to us because it shows that GitLab can help them get from idea to production costs. It wasn't one of our goals, but I'm also proud that we're the largest remote-only organization. So everyone works from the location they prefer. That allows us to focus on results, be disciplined in how we communicate. And it also allows us to hire the best people no matter where they're from. We now have people from over 33 countries. We try to practice our 10 values. Results, transparency, efficiency, frugality, collaboration, directness, kindness, diversity. Boring solutions and quirkiness. And I think this year a good example was our blog post. How we knew it was time to leave the cloud. It was transparent. All of these conversations are internal. It was efficient. We got the opinions of hundreds of experts. It was frugal because it just cost me half a Saturday to write it. We collaborated with the people that responded. And there was some directness involved because we ended up changing our opinion. We're staying in the cloud. We were wrong. We were trying to leave the cloud for the wrong reasons. And changing our opinion, let's just stick with the boring solution. They're not trying to host our own hardware. So we're trying to, with everything we do, we're trying to be transparent. We're trying to listen and be upfront. There's a big change happening right now. And that is the shift to cloud native. So the previous generation was virtual machines. And virtual machines means VMware, AWS, Heroku, but also Chef and Public to configure stuff. And we think that's going away. We think that people are moving to container schedulers, and in particular Kubernetes. So Git for us, although we were late, was a kind of a once-in-a-generation opportunity to enter the version control market. But now we have a once-in-a-generation opportunity to revolutionize the development experience. Because it's very, very hard to deploy your application on a container scheduler today. And if we at GitLab can make that easier, we think we have to show that becoming the default application development tool for cloud native development. So that is what we want to become. And we want to make using container schedulers as easy as using Heroku. And in GitLab 8.14, we launched auto-scaling CI, shadows and review ads on top of container schedulers. In 8.15, we now allow you to auto-deploy any app, or recognize your app and deploy it accordingly. And January 22nd, this Sunday, we launched integrated monitoring. Prometheus is now part of the GitLab packages, and we'll extend that over time to improve things such as review boards and extensive monitoring. So to make it really concrete what we want to achieve in the first quarter of this year, I want to present some slightware. So this is an example of the flow we want to achieve. We want people to go to Google Cloud and create an account. Start a new Kubernetes cluster and install GitLab on it. Chat about a problem in metamos chat that gets installed with GitLab. From there, create a project, create an issue. And the issue you create should have the context of the chat you had before. Should include the last three messages. Should be able to plan the issue with our issue boards. Then, you open up an issue and you click create products. And it should create a repository. It should allow you to get an auto-deploy template and initialize the repository so you can start coding. And then you start a web terminal. It's running on a container. And you get access to whatever is there. You can go in there and do a Rails new. Create a new Rails app and push it to the repository. And from there, you create a merge request. You check out the review app. So as I mentioned earlier, that app is like a new state. You can check it before you merge anything into master. So you're no longer dependent on staging. Every branch, every proposal gets its own staging environment. And that's now possible because we're using container schedulers. You can use chat ops to deploy to production. So you can say deploy staging to production. And that will understand what it means. And it will be preconfigured out of the box. And then the monitoring. So you get feedback about what happened. Because right now, many people are deploying things but they don't see the effects of what they're deploying. And if you work at a large company, hopefully you've got really good monitoring for your core repo setup. But it took a lot of work to get there. I want to make sure that that monitoring is something you get in the first 10 minutes. So you can see how it influences your systems, CPU usage, your application, your error rate. But also hopefully your business metrics. Like this revenue going up or down because of these things. And we can show those changes in the merge request. Right there where it mattered, where you took the action. We're going to give you feedback. And last but not least, disciple analytics. How long did it take me to get from having an idea to getting that out into production. And we believe that right now this is the metric that all large organizations should try to optimize. People say startups are fun to work for. They get results. They are efficient. And it's really hard to articulate why big organizations fall behind. And we think this is a great mention. You should not optimize for hours. You should not optimize for how many velocity points you got. You should not optimize for how many issues you solved. All those things are very easy to gain. This is really hard to gain. If you're able to get from having an idea to having it out in the field within a couple of days, you're going to be more effective. You're going to get better feedback from the field. You're going to have more motivated people. It's part of a larger team that we have. We call it conversational development. And if you Google that, you'll find conversationaldevelopment.com where we articulate more of this. But we think this reducing the cycle time is the essence. And because GitHub is an integrated solution, we're uniquely suited to give you feedback and allow you to see what's slowing you down and try to improve that. And we want to make our tooling so that we help you with that. So there's about 200,000 developers using container schedulers in production today. And to get this flow with other tools, it takes weeks of integration. And with GitHub, you should be able to do it within half an hour from starting a new container scheduler. So to kind of expedite shipping our cloud native vision, I posed a challenge to our team. During the Summit in Mexico in the beginning of this month, I said that if they are able to show that demo right there, I'd dance a sit shuffle from my Sitesport. Immediately, a chat group was formed and people got on it. And they didn't disappoint. Well before the Summit ended, they had a demo ready. So we're very, very proud that in this release, January 22nd, we shipped with Google Container Engine support and we shipped with Prometheus. So in the release blog post on GitHub 8.16, you can find the video of the demo and my dance. I'm too embarrassed to show it here. But I'm sure you all have mobile phones. So that was the presentation. I want to thank you for your attention. There are lots of questions. Congrats on your recent success. Just a quick question about scalability. You guys started real small and just kind of grew real fast. I'm always interested to know how how you handle the scaling of the team, the size, what did you leverage for that help and how did you know you wanted to be one of the biggest remote teams around? Yeah, thanks for the question. And to start with the last thing first, we never set out to be one of the biggest remote-only teams. One of our values is boring solutions and that means not dreaming up new management theories and stuff like that. So Dmitry was in Ukraine. I was in the Netherlands, so we weren't able to sit in the same office. And then in the Netherlands I had a desk and I hired someone and they'd come in for a few days and then after a while they'd feel comfortable working from home because everything was online by default anyway, like we're using GitHub issues, et cetera. So that worked for development. And when we, after my coordinator, I thought, okay, now we need a real sales team. We had great sales people that they worked from home but I thought, no, we need an office. We need to like high-five one another when we close the deal. And we got in place and it's now deserted. I'm there during the day. Our cat is there, my wife is there. Who doesn't work at GitHub? And tomorrow we're going to have a lunch there. But most of the time no one comes in. So people came in for a few days and then they stopped coming in. And I was like, okay, well, I should probably make them come in. And I was like, well, maybe not. Like, one of our values is results. So if they're doing well, if they're selling well, let's not make them come in. Let's say sell more instead of that. And that's what we did. And then we hired a CRO. So here I think, where are you? Chad, you want to, I'm going to tell it for you. You came in, you're like, for most sales people, well, okay. But that's never going to work for an SDR team, right? These people just out of college. And I was like, Chad, it might work, but I'm fine with it. I don't want to be innovative here. So it's fine. We'll get the SDRs here. For sure their first week of home boarding was like that. And we ended up hiring people in Utah that had a family life. And we didn't make them come in. And we're trying to judge them by results. And so far we feel it's working out for us. Skating a company, it's hard. We have lots of lessons. So if you go to aboutgitlab.com slash handbook slash leadership, you'll find some of the things. There are a lot of brands of me about matrix organizations. But one of the things I said to this to someone, it's normally if you grow a company, the culture kind of dilutes because it's passed on from generation to generation of people that joined. And in GitLab, it kind of gets stronger because so much is written down about how we work, how we operate, what our values are. And we add to that the entire time. So if you go to aboutgitlab.com slash culture, you'll find at the bottom, you'll find the feedback that people have that you'll also find the link to our one-on-ones. I don't think it's linked from there yet. But when you come to GitLab, there's a session called GitLab One-on-One. It's an introduction class. It's an hour. I did it today. But every time people ask questions, we write them down and we put them on the page. So the people that joined later have more information than the people that joined sooner. So what we see is that it just keeps... There's more information. It's better written down. It's better described about the why and the how. So we feel it's getting stronger. And apart from that, obviously we have scaling issues and we need to hire a lot of people to look at our jobs page. We have some big vacancies there. Pressing in the back. Okay, so I went to your site and I noticed that you have a lot of information on there. Of course we all know it's a super competitive world we live in technology but you have a lot of information about the company strategy, the metrics, the goals and so forth. What led to you feeling comfortable about doing that? Do you think there's any risk as you guys grow and get more competitive pressure having all that information publicly out there? Yeah, great question. If you go to aboutgitlab.com slash strategy, you'll find a lot of things that are normally very close in secret. And I think it's starting with our roadmap. So if you go to aboutgitlab.com slash direction, you'll find a roadmap what we had planned for the coming months. When we published that, we were like hmm, our competition is going to see this. And we did. And one time, one of our largest competitors launched something a day ahead of what we were launching it. Because they could see what we planned to launch it. But that's really the only negative thing that was really positive is that we now have customers that say I like where you're going with this. So I like your product right now but I like even more Redstone, so that's a reason for me to switch. And we've got people that are really excited. We've got all our feature requests or people in feature proposals. It's open source and you can make it yourself if you want. Thousands of them. They're online and if our sales people find someone that has a request they'll put it on a public issue track. They will not name the account. They'll put in a sales force link that only we can see. But the request is there and the type of company. And we find that those customers tend to join us there and together we can flesh out the feature. So it's our engineers these people working at large enterprises really passionate individuals that are running GitLab just for themselves all collaborating on a feature. So that works so well that we thought let's push it a bit further. Let's push it a bit further. If you look at the bottom of the strategy page there's something that says why is this open or something like that. There's a quote from Peter Drucker and it says strategy is a commodity execution is an art. We're not this decision that I presented. Everyone wants to get there. Everyone wants faster from idea to production. The problem is actually executing on it. So we think that is where we should do better than the rest. We shift every single month we shift on the 22nd and every single month there's a huge amount of really solid features in there and that's what we have to keep doing and it doesn't matter if they know that we're doing it what matters is that we actually execute well. Thanks for the question. I use your products every day and some of the things you wish on it My question is a lot of the stuff that you talk about you can use for the servers that we currently have but what's your mobile strategy? In our shop we run Unity builds through GitLab and we have OSX servers running and we have a whole mixture of stuff. Is there ever going to be a container solution to build that kind of stuff? Thanks for using GitLab first of all. There's some articles, some web posts that we gave about how to do iOS development and Android development with the help of GitLab CI. One of the advantages is that GitLab Brunner is just a simple Go program so you can easily install it on an OSX machine and add that to your CI file which is distributed by the full. We're thinking of making this a better experience for people that do GitLab.com by offering build minutes there not only on Linux but also on Windows and OSX that's something that might even take until next year before we deploy that. If you're self-hosted you should be able to do it today. We're very interested in making the experience better. One company that's a huge inspiration is Bodybuild. I think right now they have absolutely insanely great workflow for mobile development. We're working together on better support for GitLab there. Sorry, I should certainly check them out but they're also an inspiration to us so many of the things that they do to make it easier we might have in the future in GitLab. Mentor Fastlane, I just did. Oh, just by repeating you, sorry. We did this a little more about Git Host and where you see it going especially from the perspective of H&J and Jeevo. Git Host is our service where we run your GitLab instance for you. It's used by a couple of hundred people and nothing is written in stone yet right now our thinking is that the only reason people use Git Host is because GitLab.com is not fast enough and doesn't offer held up support. So we're working really hard this quarter to make sure GitLab.com is fast enough if I now lead a team as an interim infrastructure director I'm leading a team four teams to make sure that we make progress on that every week because we think GitLab.com doesn't accept it this well and we kind of use it's grown so fast it makes use but no more excuses we'll get it fixed and then the other thing that we think we have to do is make sure that you can use LDAP effectively on SaaS so we're starting to investigate where we can offer that on GitLab.com after that we hope that people will be able to migrate to GitLab.com which is highly available by default etc. We're not going to duplicate GitHouse but no decision has been taken and feel free to be angry at me for deprecating GitHouse during drinks. What gives you a mind mark? Actually just a quick question I'm pretty new to GitLab why did you hate the cloud at first or yeah why did you reject the cloud at first and then what made you change your mind? Great question so we were upset that GitLab.com was slow and we had some problems mostly Git is very IO intensive and we got troubled a lot and if you're in the cloud and you're a noisy neighbor you get shut down and it's not very transparent when that is happening and that both are production engineers in sync so we thought let's move to hardware by really fast hardware and solve it that way and then we did that well and everyone said that's not the right way forward you should just fix your application and we realized all of our customers are in the cloud too so if we fix it only for ourselves with hardware we're going to screw over all of our customers users so it's much better to fix it in the application so that's what we're doing we have a project now called to do GitHub I'm going to nerd out a bit get over RPC and get that IO load under control and we're very thankful for all the people that warned us like you can leave the cloud it's just going to create a lot more complexity for yourself and we still have a walk post to like all the lessons but it was so much that it's taking a bit longer than we wanted does that answer it? thanks for the question last question it's a sales person that didn't show up at the office the audience don't give up office it's him our first and one of the best sales people why did you take the mic man? everyone can contribute but I'm not sure team members should be used I've got three questions for the audience how many people in this rewrite code at the moment how many people use GitHub for some capacity for that code last question who knows what a continuous scheduler is? very proud of you so thanks so much for coming I hope you enjoyed please mingle there are there are beers here I think there are beer monks as well so be sure to get some and I hope you have a nice rest of the week thanks again