 Welcome, everybody, to the functional group of dates of product. Today, I'm going to discuss, oh, this is not working. Wait, yeah, there we go. Latest product news, 10.5, and I'm going to talk a little bit about product values. Now, I'll try to keep it within five minutes, maybe. Stretching it a little bit, and then there's plenty of time for questions. So, latest news, not a lot, but very important. Jeremy joined. He's the product manager for GitLab.com now. He's just getting started, incredibly overwhelmed with all the new things, but now you know who to find for anything related to GitLab.com, the subscriptions, and things that are specific to it. Welcome, Jeremy. All right, let's talk about 10.5. So this Thursday, we are releasing 10.5, and it's an incredible release. It truly is the best release we've ever done. It's so incredibly full of good stuff that I wanted to just, I'm going to highlight a few, but these are not easy, even all the main features. The list is incredibly long, of big, deal-all features. So I'm very proud of everyone, of all having worked very hard to make this happen. Let me highlight some of the ones that I'm very excited about. So to start off, in Libra, we're shipping Let's Encrypt for GitLab. And I wanted to mention this, because when you read this, you might think to yourself, oh, what is that thing? It sounds very technical. But what this is, is that this is for everyone that installs GitLab. So you're installing GitLab. It's very simple. Now you get, out of the box, HTTPS. So you get an encrypted connection to the GitLab instance that you set up yourself. Now you may ask, why is this a big deal? Well, I'll tell you. A few years ago, this was an incredible pain to do. It cost money to get a certificate. You would have to install it. You would have to maintain it. You would have to renew it. You have to make sure that it's all done. Now, GitLab does all of this for you. And it's made possible by Let's Encrypt, which is this large initiative which you can Google about. But this is so cool. I remember when Let's Encrypt was announced as a project. We said to each other, oh, one day we can have this GitLab. But today is the day. So well, Thursday. But still, super exciting, very nice feature. And I'm happy that we're putting it in Libra. Next one, external files in CI YAML. So CI YAML is where you define what CI does for you. Most important file in any repository in GitLab, basically. So if you have premium, what you will be able to do now is you'll be able to include external files. So that means that if you have an external definition that you want to use, for instance, you have a number of steps that you always want to do for every single project, you can simply now have one line that says, oh, I want to include this file. And as long as CI can reach that file, so it has access to that, it will include it. Then you can even make modifications to what you actually want to do. This is very useful for almost everybody. Very cool feature. And I know a lot of people are excited about this. And then already in 10.5, so as you know, we acquired Jemnasium, which was a very cool startup that does dependency checks. And in 10.5, we have integrated that into GitLab. So that means that if you're running GitLab Ultimate, you'll be able to have your dependencies checked for any vulnerabilities. So as you know, all software is built out of a million vulnerabilities, a million dependencies. And you want to be sure that none of them are vulnerable, or you want to know when to update which. So Jemnasium tells you that. And it's already part of AutoDevOps. So it means if you have an AutoDevOps project set up, it will just work. And you just get notifications about your dependencies. All right, next one. Oh, this is a picture of it, where you see here on top high directory traversal vulnerability in RubyZip. So RubyZip would be one of those dependencies. You see the rest of the one are checked off. But this is one that is vulnerable. And then you know it right in a virtual quest where everything happens. Super cool thing. I'm super excited about this. All right, and then the last one I wanted to highlight. And I'm already at four minutes. It's hard. It's road maps and epic search. I'm kind of cheated because I put two here, both in Ultima. So we finally released road maps. And this is a very first, very simple iteration. But it's already very nice. It basically gives you a few of all your epics when they start and when they end them where we are now. And we also allowed you to search over epics. Here's a picture of it. This is actually a picture I took today of the epics that we have in the GitLab org group. So you can actually see it there if you squint your eyes. And you see all the ongoing epics. And you also see that all the epics are basically happening today. So probably we have to change our planning here a little bit. This is the first start. We want to do a million other things here. But I'm very excited with this already because it makes you want to use epics. And that's very important. All right, so far for the features in 10.5, there's much more coming. You can check out the MerchantQuest and order review app if you want to early preview. You can wait until Thursday if you're very patient. You can also ask me in person. I wanted to talk about product value. So usually I talk about what was in the current version or upcoming and what we're doing in the next one. Considering I have a release coming Thursday or in the middle of working on one and because all this information is easily accessible, I figured why not talk about something else for a change. So this is going to be short, three minutes max. But I think it's interesting to give you an idea of how we think about building a product, how we think about building new features and what are those values that we try to stick to. So this is all in a product handbook with a lot more detail. But I wanted to walk you through it to give you an idea of why do we release road maps as it is, why don't we build it out as a big feature. The first thing is we always want to shift the minimally viable change. This is a strange sounding, an MVC, strange sounding acronym made up by me, but the idea is that we look for the smallest possible change that we can possibly ship in a particular release. And there's really nice comment that essentially explains what that means, but it means that you have something that can stand on its own, so we can release. It's not broken, doesn't break anything else. But in all other ways, it's the smallest possible thing that we can possibly do. And the reason for this is that we don't spend a lot of time engineering something which we might not need. If we release something very small, we can immediately get feedback on how people use it, whether they like it, but also whether it's stable, where it's performant. It's very hard to predict what you will need in the future. So if you rather spend your efforts into quickly releasing something, you quickly get that feedback rather than having to try to predict what happens in the future because you will always be wrong if you do it that way. And this way, we can really build products based on feedback, really build products that people want. This is very important to the way we do things at GitLab. So it's very easy to get this wrong and very easy to over engineer things. So this is one that's very important to us. Other one, convention of configuration. This is very simple. If we have the choice, should we make something configurable or should we make something work in a particular way out of the box? We go for that convention for something that works out of the box, even if it is a little bit opinionated. It reduces complexity and overall makes products much easier to use. If you end up making everything configurable from the start, you get a very complex product that's also very hard to iterate on. All right, next one. Ambitiousness. Now, this XKCD doesn't match very well. If you have a better one, please suggest it to me or make a merge request to the product handbook. So apologies for that. Ambitiousness is simply exactly what it is. We want to be ambitious. We started out as just a place to put your repos stories. And you all know that today we do so much more. Everything that differentiates GitLab is more than just those repos stories. Only by being ambitious can we win the market and can we change something about the way developers work today, because that's essentially what we're at the business in. So, very important. And lastly, and this XKCD is actually better at explaining what this actually means. So simplicity is, of course you want to have a simple product and I could call it Steve Jobs or whomever else. But what this really is about is that we create a product that just works that doesn't put anything in the way. If we introduce a new feature, it should help you with something, not make existing things or things that are easy harder to do. It shouldn't require like, in a product handbook I wrote something about human CPU cycles. Whenever we introduce something new, it shouldn't require you to run more human CPU cycles. It shouldn't be harder to do things. We should try to keep things simple. This is easier said than done. It's very easy to say, well, let's just add this button here and then we have solved this problem. And this also goes back to conventional configuration. I think these kind of things, this XKCD is a perfect explanation of this where all these mobile sites nowadays have become horrible. If you open like a newspaper, there's like a bar on top and there's a thing in the screen and it's not a good experience. And I really don't want GitLab to ever become like that. But it creeps in. So we have to be very careful about keeping a product simple to use and keeping it very clean. So that's for simplicity. So those are some of the values. There's a few more in the product handbook that are maybe less important or more specific to some situations. I'd love it if you would have a look, if you would have a read. Suggest any changes. And that's it. Any questions about this release, future releases, products, anything. You can also throw them in the chat but I prefer if you just pick up. Hey, Yop. So I think that a lot of these values are essentially translation of our company values to how we build the products. Or am I seeing this the wrong way? Yeah, I always like to think that those two grew together a little bit. It's not intentional, right? I think this is something that just came to be. Those product values I established very early and I named them slightly different at first. But yeah, I think it aligns very closely with the way of how we think about things. I think we're trying to very much avoid things that are very process heavy, things that are very complex. No one is helped by complexity. Complexity in itself is not a good value to have. So if we try to go the other way in our product, it also makes sense to go the other way in our company. Right, right. I'm not saying in a bad way like, oh, we should not have these values and always refer to the company values. I think it's really nice that we naturally align to these product values and also that we show a product, have a product perspective on our company values naturally, basically. Thank you. I also don't know where that red line came from. Everybody, I saw it as well. I thought it was on my screen or it was too busy talking to get it off. I think I did accidentally with Zoom or something or I don't know, some markup. It's not the app that I used to make the slides. There are no questions about all of our product, the way we think about KitLab, what we're going to build in the future. I left this time for a reason, everybody. It's now's your chance. So, Yob, I have a question. Go on. So you showed the roadmap view with everything, for Epic's, for 10.5 or whatever, any of the day. Do you intend to drink that champagne a little bit more with product and try to use those roadmaps? Because that's not necessarily the way you've thought about it in the past. So I'm just curious if the product team is going to try and drink that champagne or it's just kind of a nice to have. Now, we're starting to adopt Epic's as a start. I think that's the first real step that we are taking right now. And there's something standing in a way of fully adopting them, like comments on Epic's, which will come next release, I think. That's the first start. The goal, eventually, is that we can fulfill all our own needs with Epic's and roadmaps and our issue management tools. What I want to be able to do is to have powerful capacity planning, for instance, that if you say, well, if we do this and this at the same time, then we won't have time for that. So all of these kind of things, yes, absolutely want to eat our own dog food, drink our own champagne. That goes for almost all of your GitLab features. On the short term, we're trying to adopt Epic's, at least in the product team. Don't know how we are going to use roadmaps at this point, but it certainly does look nice. So yeah, suggest a way to use it and we're happy to give it a shot. Great, thanks. Anything else? The one question in chat was about the red line on my slide. Yo, I have another question. The gymnasium dependency checks, I don't know how the gymnasium product was priced before it was acquired. What is the relationship between their previous pricing and our ultimate level? There's no specific relationship, it's just part of ultimate. But is it equivalent? So it's kind of the same price so customers can switch to... Of course it's not the same price because it includes GitLab basically, but I'm saying in terms of value proposition, switching to GitLab to have to continue using gymnasium features, what did we think in that regard? As with everything, this is a first iteration, right? So if you think about what is the intrinsic value that it brings, it brings the core value of gymnasium, but not everything they offered. So that's something for future iterations and things to come. Yeah, in terms of pricing, yeah, as you said, we haven't changed, like we had established this pricing and the pricing for ultimate before we even acquired gymnasium. So there's no intentional correlation between the two. I do think that it's an interesting offer, right? Otherwise we wouldn't price it this way and otherwise we wouldn't have this complete package. What is always a good indicator is when I hear people say, oh, so much cool stuff in ultimate, that's a pretty good indication that we're doing something right and that there's a lot of value there. Like people that say, ultimate, oh, I really want it, but it's on the high side. We want to provide enough value that people are like, okay, I'm just gonna pay for that. And that's a very tricky balance. There's a pricing channel on Slack which you're free to join. Brad Walker says, ambition is good, but isn't there the possibility of overextending and not doing our core very well? Yes, there is. And that's a really, really great question. I think it's very important that we drive our vision and we drive what we work on by usage of feedback and those two will go hand in hand, right? So if a lot of people are using a particular thing, we're more likely to invest in that. And that's a virtuous cycle that strengthens the parts, the core parts of the product and gives less attention to the lesser parts of the product. And this is why we ship the minimal viable change so that the first iteration of monitoring was almost nothing, right? But if we see that people are using it, we see that it's useful and people are giving us feedback about it, it incentivizes us to invest more in it and it becomes more used and it slowly becomes part of our core offering. And if you want to think about rough numbers, like the majority of the work that we spend in engineering, we still spend on repositories and core CI. So that's a real-world fact to replying that. Let's see. Clement says, I recently saw an issue about GitLab 11. Can you share a bit about it? So excited, yes. So GitLab tries to follow semantic versioning, which means that there's a major, minor patch. So you have two dots. The first number right now, it's 10, is the major version. The second one is 10.5. The five is the minor and then point something. The last one is the patch. Patch releases, you don't change major features. You can always upgrade to any patch release without having to worry. Minor versions, they might change significant parts of the product, but they don't deprecate necessarily things. Like if you upgrade from one minor to another minor release, your integrations are not going to break. Major releases are opportunities to remove parts of the product that people might be using. So in other words, we can break things. We can break your integration or change something about the API. Of course we let you know, but that's the way to think about it. So the point of GitLab 11 is two-fold. One, it's to deprecate things, to take things out of the product that we have been wanting to take out, but we couldn't because we were just going from one minor release to the next minor release. And the other one is to say, hey, look at this. We did a big upgrade over the past months in a product and it's time to basically say to the world, wow, what a new version. So that is the point of GitLab 11. I created an issue. It's public, of course, discussing the date of GitLab 11. I don't have it at hand, but maybe Clement can link it in the chat. It's important to establish this ahead of time so we can plan what we can deprecate so we can make a marketing plan to basically say, hey, there's this new version of GitLab and it's a big deal. And that's it so far, right? So I'm just planning, what are we going to deprecate? What are we going to put in there? What is it going to be the message around the release? And I hope to do it before the summit. Like the real best thing would be on the summit but then everyone is on the summit or on the way to the summit on August 22nd was my idea. Also my daughter is born around that time which it would make a perfect thing but it's probably not the best way to prioritize release. So I hope to do it in June or July. All right, William, there's probably a difference between migration path for gymnasium users and any cool gymnasium stuff to GitLab for GitLab users. I think 10.5 is the letter. Yeah, so 10.5 is more cool gymnasium stuff to GitLab for GitLab users, not necessarily migration path for gymnasium users. Although I would say they should all be using GitLab. Okay, is there a separate security products update? Brandon asks, and that is tomorrow by Flip. Gabrielle, are we planning GDPR specific features? And if so, which plan will that be? No, nothing specific, Gabrielle. Luckily, we already do a bunch of auditing things and you can control your data very easily in GitLab. We will be, we posted a blog about it and we're doing some further review of the product. So maybe we make some changes here and there but suggestions are very welcome. Please open an issue and bring the product channel. And Philippe proposes to organize something specific around the gymnasium functionality in GitLab and what else? All right, no worries, Philippe. That's very welcome actually. Any more questions? I'm gonna give you three seconds. One, two, three. All right, thanks everybody. I hope you enjoyed a new view from my new webcam and I'll see you all at the deep call.