 Hi, welcome to the general functional group update. My name is Sid and I want to discuss a few things. First of all, there's an initiative to make GitLab users download Enterprise Edition by default. Right now we have, we stare most of our users to download Community Edition because that's the only way to use Community Edition features without the license. But when talking to users, they say a few things like they're using CE, it's a great product and actually great startups like equipment shares say, look, I would love to buy EE, but I look into the documentation and it seems pretty hard. And also they know what they're getting, but a lot of CE users don't really know what they're getting. So we've got two problems. First of all, operating is hard, second of all, you don't know the features they would be getting. So what we're going to do is we're going to steer users towards downloading Enterprise Edition. And when you install that it will function just like Community Edition. So no next screens, no interstitials, no nothing, it just functions. But in the interface or in the settings and things like that we can expose EE features. Say like, hey, here would be an EE feature. If you want to try it for 30 days, click this link. So we'd have a way for people to easily try out EE features and therefore get more people exposed to that. If they don't want to use the EE features after 30 days, it just reverts to Community Edition. If they do want to use them, they fill out a form inside the product and they can instantly purchase their license. Another thing I wanted to highlight is a page of the whole software development lifecycle. So this talks a bit about the different stacks that are developing. And there's a, if you look at our Google Drive, there's a document called Conversational Development Stack, which details a few more from our partners. But I think these are the five main ones. So we got our stack, hopefully you're familiar with it all the way from MatterModes to Kubernetes. You got the GitHub stack, using Slack, GitHub Issues and Boards, Travis CI, Heroku and New Relic. You got the Atlassian stack, HipChat, DROT, Trello, Bitbucket, etc. You got the Amazon stack, which interestingly also uses DROT, CodeCommit, CodePipeline, CodeDeploy, CloudWatch and ECS. You can kind of have the legacy open source software. I received that mine, Kenboards, SVN, Jenkins and Nagyos. And what you're going to see in the marketplace is that more and more people are going to go towards an integrated stack. GitHub has a really hard time here, especially self-hosted, because they're not really selling the other products. They're now trying something with a marketplace, but it's still especially for self-hosted, that's not an optimal experience. I also think UX-wise it's never going to be a good experience, even with SaaS. We found out after we integrated GitLab CI that having it integrated in the product is so much better. So that's where we can make an impact. I said a quick question. Prometheus, does GitHub and Atlassian and Amazon have a built-in performance monitoring as well? No, they don't. So GitHub has no CI built-in, no deployment built-in, no measuring built-in, no chat built-in. So these are all separate products. So I put the most popular one on here. You can use multiple solutions with GitHub, but the thing is you'll have to configure it yourself and you won't see it in the merge request, et cetera, et cetera. So GitHub seems to be betting that there would be like best-in-class products developing. And I think the most obvious complementary product is CI. And as you recently saw with the blog post from Heroku, GitLab CI is now overtaking Travis CI in popularity. So I think it's a flawed idea that you can be a platform and then have best-of-breed, so-called best-of-breed tools. You see that when GitHub launched their marketplace recently, most of the stuff that's in that marketplace, you just get, with GitLab, you just get it by default. Like you don't have to do anything for it. You don't have to go to a marketplace and click anything. And it's integrated into the product, which makes it a lot easier to use. And where we don't have it, we or the rest of our community can add it. I think they're, I'm not sure what exactly they're thinking, obviously, but they kind of, I think they're, the DevOps lifecycle is so hard, or it's so complex. And it's so bothersome to set up. I think there should be a product that helps you with it. And I think now open source allows the best developers in the world to collaborate on one product and make that better. So I think that's a winning strategy. And Atlassian has all the products. So that's a win on their side. But except, by the way, except for measuring, you don't have a default measuring solution. But they don't have, they've not really integrated it, like HipJet, completely separate from JIRA. And then JIRA separate from Trello and Trello separate from Bitbucket and Bitbucket separate from testing, which would be bamboo. So for self hosted. So it's kind of, they're selling it. You can't even buy the licenses in one go, but also they're kind of separate products. So you got to pay reseller to set it up correctly for you. Any other questions? Cool. I wanted to highlight Mark's DevOps vision where he's looking at different things. First of all, we got to make idea to production a lot easier to adopt. I think we have too few people using it right now. That's fine. We always started like that, but then we've got to iterate our way to do something that is very easy to use. He's looking into cloud development, like the online IDE space, but also lots of ops features, which is like make it easier for teams to manage a Kubernetes cluster. And to a GitLab pass. This is like going straight after Hiroku. Hiroku is the way you push a repository and everything just works. And that's where we're going with GitLab. You push a repository or you start a new project and CI and CD and code quality metrics. They all are just metrics. It all just works. And we're doing work with an auto-generated CI file, so that you no longer have to add a GitLab.CI.jammel file, but it's just there. GitLab figures out the best configuration. We're doing work with CD. We already shipped Canary deploys, but we're looking at incremental rollouts. Dimitri is working on code quality metrics so that by default, you get not just CI, which tells you whether your code is broken, but you also get an indication if your code quality is going up or down, which I think is really useful and it's supposed to land in 9.3. To make a real alternative for Hiroku, there might be some other stuff to solve. What Hiroku, for example, does, it allows you to spin clusters down to like zero nodes. So while we can offer like auto-scaling, if you get more people using your application, we spin up more on Kubernetes. So we cannot spin down to zero nodes yet. To do that, you have to kind of, when there's a request coming in, when there's zero nodes, you have to sponge those up, wait a while, and then quickly spin up the container and then release the requests. That's maybe a bit far out there for us. And I think for now, it's already pretty great that we can, if we get it very usable to use auto-deploy. But you can imagine if you have like 300 merge requests in action and 300 review apps, it might get a bit expensive to have a complete cluster for all and spinning down to zero would be pretty awesome. Other things, feature flags is something that I think lots of companies have like homebrew solutions for. We can do better. The version checker, like checking for security vulnerabilities in your dependencies is a very obvious feature. And last but not least, artifact management. I think it's one of the missing pieces of our puzzle. I think Pivotal and other users, when they use GitLab, they always need GitLab and then an artifact management system. And artifact management means as much as you've got a way to push and pull your binaries. And we got that for Docker containers. So we come with a container registry, but we don't have it for all the programming languages. So you have the Java programming language and many others, and they are used to their own packaging system. So I think we want to do something there. The primary tool now that is used is Artifactory, and we want to have a look at that. And it's funny because it's supposed to be open source, but we have a really hard time locating the source code. So it's easy to download like the open source version, but it's very hard to find the source code of it. So I don't think they're getting a lot of contributions from the wider community. So for them, probably open source is more of a go-to market than a way to collaborate with the wider community. All these tools are written in Java, and I don't think we want to ship with a JVM attached. We might want to. We'll have a look at it, but it might be time to rewrite some of those artifact management systems in Go, just like the Docker container registry. And then the last thing I wanted to highlight is to get all features from a consistent source. Right now, if you look, we have a very high feature velocity every month. And if you look at our different pages, not all features are on there. On our comparison pages, not the newest features are not on there. On our product page, where you can compare different versions, not all features are on there. If you look at our feature page, not all features are on there. And one of the problems is that you kind of have to get a new feature. You have to add them to all those pages, and people forget. And there's no right flow for it. So I'm working with Connor who's done a really good job of trying to consolidate that. So we already consolidated the comparisons page. So that you list the feature once and then say which comparisons it has to appear on. And now we're going to try to simplify the product page so that you don't have these big matrices for people to work their way through. And then we hope to get to the features page itself so that we can also list them there. And this way, if we have a new feature, PMS added to this comparison. Jamal once and it shows up on all the different pages. Because it's a bit of a waste if we spend a lot of time making a feature, but then don't don't tell people about it. Yeah, these were some things I wanted to highlight, but I love to have questions and I'm going to see if I can find chat. Ask premium if you could elaborate because the context is now gone. I couldn't see the. Yeah, yeah, your first slide there where you talked about pushing by default people getting them to enterprise position right I just wanted to ensure that we're pushing them to premium right so out of the box of getting premium functionality right features and functionality as opposed to to starter edition. I just want to clearly understand that. Yeah, so so the thing is, we're pushing them to download enterprise edition, which is a code base. And we hooked them up without without any of the enterprise features. Because what we want is we can only make them download enterprise edition by default if it's a great experience. And that means no registrations screen or nothing. Now, you don't want you probably see the problem with us giving away all the enterprise edition features without someone registering without them even being aware that they're using the enterprise edition features per se. So when we're not going to do that also many of the enterprise features are not very useful. If you're just starting like if you just downloaded get lab, you don't need any of the enterprise features. As it says their their features that are more likely to be useful if you're using it with over 100 people. So day one, you're not going to have a need for them. So I'm not going to give them to them on day one. We're going to expose them in the interface at some point they'll be like hey why can't I turn on approvers. Oh, it's great out. They can set sign up for trial. And then they can sign up sign up for trial. And, and then they have to like can say which company they're from etc. And then we have a way to get in touch with them. And after the trial we asked them whether they want to want to get a subscription. So it's download enterprise edition by default. I got it features and then get a trial and the trial obviously will be the EP. I don't think we'll we'll even have an option there. Okay, now I get the flow. Thank you very much for elaborating that. Thank you. And I get that this is counterintuitive. And that's that's why I wanted to highlight it so I'm very happy with your question. That's when will this be implemented. We see that this is something really important. So I think we're talking 9.5 or something right now. Still got a bit of work to do. Obviously this will pay out over the longer term, because you get people downloading GitLab now so it's like it takes a year or two before that bubbles up. But we do think it's going to make a major difference in how many people choose to go to it might go from a currently that's about 2%. We can get that to 6% or something like that that would be really good for the company. Oh, and Mike is giving a more detailed answer. Thanks Mike 9.3 9.4 9.5. John asked, didn't Red Hat come out with a platform as well? They did. So if you go to, if you go to the Google Drive, you go to a conversational development stack. And I'll add the words Sdlc to the title so you can find them. You can, you can see the other stacks. Those are not on that web page because they many of these people at the same time partners of GitLab. So we don't want to highlight them as competitors at the same time, which makes it a bit awkward. But yeah, there's there's many, many other people trying the same thing. They said, quick question about redeveloping the way we communicate the features. Is the layout going to be different because right now we have it on the products page. We've got the pricing and then that matrix. Is that going to be like a standalone page? How's that workflow going to look on the website in the future? Sorry, I couldn't hear you just just one second. Can you repeat the question? Yeah, no problem. That issue where we're consolidating the features and, you know, reevaluating how we show it on the website. What is that workflow going to look like because right now we've got on the products page, you've got pricing and if you scroll down long enough you get to the other features. How will that workflow look like after you're done with that issue? Yeah, and the linked issue is an idea, but basically we're going to base it on what you see at the Salesforce website. We just have, we're going to have four boxes. The boxes are going to be a bit taller. Like they need to contain like the 3D features. Each feature will just be a single line. But we're going to have the action buttons both at the top and the bottom so that even if you don't scroll you can quickly go to them. And we're no longer going to have this enormous matrix, which is like too much. It's not very easy to parse that. Awesome, thank you. There's some people commenting and how hard it is to integrate all the Atlassian tools. Clement asks, would it ever make sense to combine the code bases into one? Obviously that would save us a lot of work. The problem is, is that then it's really hard to like separate out which features are proprietary or not. And some people don't want any proprietary code on their system. I think it's a minority of the market, but that minority is some people we want to keep happy as well. So I think they wouldn't like it. So therefore we have to stay two code bases. John May, can we have a report back to us that they tried the EP feature? Yes. So John, the ideas, if you want to try a feature, they just push a button to sign up for trial and in the product you fill out the trial form. So they got all the EP features at that point and we got the trial report. Yeah, just to add, we do record that people are using it so we can actually see that they are using particular features. So corner stats, a problem on the websites that the free trial buttons only started and not under premium. Yeah, that is bad. And I thought May 1 we would have a change so that EP was the standard trial thing. As far as I care, let's move that button. Andrew is a fan of Nexus. Why is that Andrew? The user interface is nicer and it supports more types. It's not just Maven Java artifacts. It supports NPM and power and a whole bunch of other things as well. And the source code is readily available on GitHub. It clips license. Cool. I think Artifaction has pretty universal support as well. I know for sure that they support NPM. And I think what we're going to do is just integrate it into GitLab, just like the Docker container registry. So that should be a super good user experience. Dower says, why not make the open source? Why make it not easy for us instead of for them? Note that that's in response to Jason's concern with my comment about Sugar CRM earlier up. Because I know that Sugar CRM had a similar model with a community edition and enterprise edition. They had a single code base where every EE only code, the proprietary license code, has like markers around it. And then they had a preprocessor script that strips everything inside those markers and left only the actual open source code. While the main code people were working in was still mixed license, which would, I mean, it's hard to set that up. But still, it would make our developer life a lot easier. It would only be that preprocessing step that we need for that loud minority that wants open source only code. But this is something that I've been talking about a little bit with, you know, Myron, Stan, Mike. Because I was talking to Myron a couple of weeks ago about how much time we are really wasting because we need to have separate code bases. And we have the merge back and forth and we have so many, you know, merge conflicts there that this would save us hundreds of man hours every month. If we just have something that was easier for us, if a little bit harder for those loud minority. Anyway, something to keep in mind. Yeah, I think that as long as you output a repository that has only like open source freely licensed code without any caveats, I think people would be fine with that. So cool. Thanks everyone for joining the call and all the questions and comments greatly appreciated. Have a good day.