 coming to the general functional group update. My name is Sid, and I'm going to try to share my screen. I'm at some place else today than my office. So forgive me if there's any technical difficulties. I want to clarify one thing. Sometimes I talk about our top priorities and .com availability and the number of leads we generate. And I stress that it's those are like the two top things in the company that have to improve that I'm focused on. And some people took that as meaning the people that are working on that are doing a bad job. That is not the case. It means that improvements in those things have the biggest impact on our growth. Like in a fast growing company, you continually have things that are kind of the throttle on the rest of the company. We could grow faster if. And whatever is after that, if you have more leads, if .com is more available, that will be a thing I focus on. That will be a thing I call out. And that is going to be something that we have to improve. So those are the areas where we can have the biggest impact. It doesn't necessarily mean that the quality there is bad or that the people are not doing a good job or there's no good plan in place. Generally, you might have great people working with a great plan. And still it's a problem on our growth. And still it will get called out. Number two, a decision we made at the executive offside is that we'll stop the early adopter program for ultimate as soon as possible. As soon as possible and we'll make guest users free in the ultimate addition. By making guest users free, we take away one of the things that our customers said is that they don't want to pay for someone that's only just commenting on things. I can't see my chat at the same time. So I want to ask if there's any questions at this point. Don't see anything yet. If we could speak up. Another thing I wanted to highlight, because it's obvious to me, but I learned to, I'm trying to repeat things that are obvious to me, but not might not be for everyone else, is that we're very well positioned to win in this market. We're the only ones kind of crazy enough maybe to make a single product for the whole DevOps lifecycle. And that's very, very ambitious. I don't think any other companies even dare to do that. And the only reason we're able to do it is because there's a lot of open source software out there. So instead of us trying to make everything, we're leveraging open source. We're leveraging Prometheus and technologies like Yeager and Elasticsearch and all the other great things and Kubernetes to build something. And it's kind of turning the disadvantage in this market on its head. When we started GitHub, lots of investors said, yeah, DevOps tooling, yeah, it's a really bad market because everything is open source. We're turning that on its head. It's a really great market because everything is open source. So we can just take all the components, leverage that open source. And then the problem is integrating all of that open source. You need at least 10 different components for a DevOps lifecycle if you're not using GitHub. And that means 24 different integrations. With GitHub, we don't do those integrations. We don't make the components as much as we focus on making them well integrated with our UX team with a single database. And that's unique. No one else is doing it. And it's an amazing value for customers because every customer you talk to is like, yeah, maintaining our tool chain, it's really hard. And everyone in the company has it organized differently and it's hurting us. A fourth thing, starting to a potential customer yesterday and look, they're not buying GitHub. They don't want another tool. They don't want LDAP sync or things like that. They want what we sell has to do with job. And it has to get them to a 200% faster DevOps cycle. And we say, if you buy GitHub, your DevOps cycle is three times as fast. That's what they're buying. And we should even, I made a proposal today. And if you look at our Slack channels, I won't name it, but there's a Slack channel that we can maybe even change our pricing so that we get paid when their DevOps cycle gets faster. And I think that's an amazing opportunity because I think if we go into a company and we look at the DevOps cycle of the different projects, I'm sure that the more of GitHub you adopt, the faster your DevOps cycle can be with the integrated security testing, with the review apps, et cetera. So if we can show that there's a correlation there, we can help the customer improve their DevOps cycle just by having more teams adopt all of GitHub. And maybe in the future, we get even paid by that. We get paid if we make it faster, not so much for seats or for licenses but just helping with a business outcome. The fifth thing is about multi-threading. There was a trend on Hacker News about GitT and it's an alternative to GitLab that's written in Go. It's amazingly fast, it's multi-threaded and it doesn't use a lot of memory. And GitLab does. And right now it's using four gigabytes. Some people even say GitLab's using eight gigabytes. A lot of that is from our application server that has multiple processes. Now that that's no longer the latest in Ruby on Rails land, like Puma and multi-threading was introduced years ago. We tried it, it didn't work at that time. But I think we should have another stab at it and try to make GitLab multi-threaded. The first thing to implement would be the Rubikop rules for preventing common mistakes that can cause problems in multi-threaded apps like global variables. And I think we should work towards that. I don't think we'll get GitLab down to half a gigabyte but a lot of people have instances on sites like DigitalOcean and most cloud providers, they charge for memory. So the more memory we use, the more expensive it will be to run GitLab. The last thing I'd love to talk about more is go beyond SaaS apps. Right now with GitLab, we assume you develop a SaaS app. There's some great, great sites out there, like bodybuild and lots of others that make it easier to develop for mobile. Visual Studio, for example, is also having some great features for that. There's people working on data and they have different requirements. They have something similar to a DevOps lifecycle with them for data engineering. And then there's machine learning. Not Jupiter, but TensorFlow and technologies like that. And there's a lifecycle to that too. Yesterday, we talked to someone from Google who was working on Kubeflow. And Kubeflow is making it easier to kind of do machine learning through the machine learning lifecycle. And I think it's really important that we make GitLab work, not just for run-of-the-mill Ruby on Rails applications but also for these scenarios. One of the projects we have is BizOps. It's for data engineering, making it easier to ingest data and to clean it up and to analyze it. The other big thing is what Dimitri is working on, our co-founder CTO, he's working on making it very easy to deploy Jupiter Hub from GitLab to make sure that when you deploy JupiterLab, it ties back to GitLab. And Jupiter comes up not just in data but also in machine learning. It's becoming the lengua franca of how to do analysis. And if you don't know Jupiter, it's based on iPython notebooks. It's similar to Mathematica or Maple. And if you don't know any of those, it's kind of an interactive Word document. So you have a document, you make a calculation, you press enter and it gets executed. Brandon, here's to the crazy ones. Yeah, that might be an Apple commercial. So thanks for that. Michael asked, is there any place in the handbook that goes over the other open source tools that GitLab is leveraging within GitLab? I don't think there is. But if you're interested in the BizOps section of our handbook, there is, it's front and center of what other technologies we're leveraging. And I'm sharing my screen so I can even show you quickly. So BizOps is leveraging Singer, DBT, Postgres, GitLab, CI and more DBT, Jupiter Hub and possibly D3 or SuperSat. That's Slack channel. Yeah, I guess that people could see my tab anyway. Our normal pricing is charging $99 per user per month. And you can't go out and do this tomorrow because I'm still arguing, arguing, having a constructive conversation with Chad in the Slack channel. You could imagine a pricing channel where we say, oh, it's half the price. And if every percentage points we make your DevOps life cycle faster, we charge a quarter. And if we improve it 200%, you end up paying the same. We make it even faster, we get more money. James says it might start up slower. I'm not aware of that, that might be, I don't think people care too much about our startup time. What happened when we tried Puma before is that we just had a lot of quote that wasn't multi-treaded in libraries in our own code everywhere. And we just got horrible errors the whole time. But that was around GitLab, like 4.05.0. So long, long time ago. So I think we should revisit that. Yeah, I was just saying, it might be that turning on multi-threading makes it the memory consumption worse to start with. And I think it was something to do with because each process accessing the memory, but I think there are workarounds. So yeah, setting the vision, I think we can get there. Yeah, we also got probably some horrible memory leaks. So that might even lead to everything getting worse. I think we have to buy to it. Patrick asks, is it possible that the requirements are too different for S&B and enterprise? Might be possible, but I think we can just go down a lot more. And there's always going to be some people that want to run it on 100 megabytes. Well, they should probably download, they should use GitWeb, the thing all based on. It comes with Git. And you can run a small web server to look at your GitWeb posts. But the further we can lower the requirements, the entry requirements, the less space there is below us for a competitive solution to develop. And there's this theory. It's called the innovators dilemma. And it kind of says most of the times you get displaced not by someone that makes something that's better. You get displaced by someone that makes something that's worse but more affordable or lower requirements. So we're not gonna lose to GitHub in the last week. We have a better product, we have better pricing. It doesn't, we're gonna win. However, very far in the future, 2030, we're gonna get displaced from something that looked like a toy that was doing a worse job but it was more affordable. And right now, that thing is looking like it's those things in that Hacker News article. So we should make sure that there's as little space below us as we can. So yeah, we can make everyone happy but we can probably reduce our memory requirements from four to eight gigabytes to one or two. So we should do that. Yeah, Chad says, yeah, faster DevOps cycle makes a lot of sense. It's not on our homepage. Yeah, I agree. So maybe it's on our homepage instead of saying concurrent DevOps, which nobody knows yet, we should call out a 200% faster DevOps cycle. And that would link you to a page like, hey, we can make it faster. How do we do that? We do that with concurrent DevOps. So if a sheesh is on the call, she might be an experiment worthy to run and Cortland plus wants that. Andrew, you wanna talk about Gitterly and removing the rocket code? Sure, it was on your point of going to multi-threaded Ruby. And so this is like a really wasteful thing that is the way it is at the moment because obviously we've been trying to build Gitterly and keep the application going. And so we've got a lot of struts that we've put, imagine we're building a bridge over a highway and we didn't wanna stop the highway. One of those struts is that we vendor code from the main application into Gitterly Ruby. And so when the GitLab application runs, we have the same code running in two places. And only once we get to Gitterly v 1.1, what would be able to remove that strut? And at the moment, obviously the Gitterly team are, many of them are working on other things. So this has been deep prioritized and will be a big win for memory consumption. I just wanted to make that point. Cool, yeah. I think everyone's looking forward to Gitterly 1.0 where we can turn off NFS and then Gitterly 1.1 where we can get rid of the rugged code in memory. So, but thanks for calling that out. I forgot that. I forgot to mention that on Hacker News on Sunday. Thanks, Jayce, for the Jupyter Hub link. And yeah, if you haven't watched the video about Jupyter or something like that already and you don't understand what it is, I encourage you to look at it. It is the way that data science and machine learning is being done. Ralph plus one's chance point about calling out our benefit to the customer instead of concurrent DevOps. William is in the call. William, feel free to speak up. John may ask about conversational development. So John, we're remaining a renaming conversational development to their DevOps score. And the DevOps score is going to be based on how much of GitLab you've adopted. So are you just using the version control or also the CI? Are you doing CD? Are you using the monitoring, et cetera? The more you use the higher your DevOps score. What we want for every customer is a graph. On one axis is the DevOps score of the different projects in the company. The other axis is their cycle time. And now what we hope is that there will be a line like this and I'm probably drawing the graph in the mirror image or something. But the more of GitLab you adopt on in general, the lower your cycle time. That's what we're hoping for. And we're going to build that into the product. So not only we can see it, but all the users are using that instance on GitLab 11. All those statistics should move out of the admin area and into an area where all the users can see it. Now we can have a conversation around that like, hey, you're seeing this trend. So would you like a 200% faster DevOps cycle? Yes, okay. Well, the way to get there is obvious. You can see it here, adopt more of GitLab. So how can we help your teams adopt more of GitLab? I want to ask, ending the early adopter program. I think so as she's just coordinating this, I think we'll have a cutoff date for like, this is the last date. If you're not in touch with us before this date, you cannot take advantage of the early adopter program, say end of next week with a ceaseless on it. So I'm not sure what the date will be, but they'll determine that. And then you have to actually order from us, for example, end of this quarter. I'm copying Chad's comments. Cool. I don't see anything else actionable. And I got to be on my way.