 Okay, so in the last few weeks we had a visit with a client and executive who was really concerned about the administration and maintenance as it relates to GitLab. So his concerns were really about the upgrades, the installation, what happens if I've got an issue, I don't have anybody that knows Ruby to take a look at the logs and to help diagnose what's going on. Some of the upgrades are really difficult, but his last touch points were really more like a year ago where the upgrade was a lot more difficult than today. And it's been a monthly upgrade. So there's so many times we have to go through this process, I struggle to support it. And so ultimately, why would I pay for GitLab when I'm having these difficulties today? And that was the conversation. Yeah, I totally understand. Did you figure out how they're hosting GitLab today? Yeah, just a simple bare metal server hosting GitLab Community Edition. Okay, yeah, well, it's pretty clear that with the Enterprise Edition, obviously it comes with support, four-hour turnaround time, live upgrade assistance, and that would certainly help with some of their concerns. The other thing I noticed is that them being on some older lines, the 7.x or 8.x lines, we need to get them up to the 9 line because with the release of 9.1, we now have the ability to do no downtime upgrades, and that would certainly go a long way. So in your conversations, did you assess how big your organization is, and did you get a sense if they have an internal tool or admin team that supports their engineering teams? Yeah, they've got a couple hundred users. We've heard this in a couple of conversations, and it seems to be that 200 to 500 user range. And they do have a small team of people that is managing the tools. But again, they don't have any rubious experience, and so that was one of the core concerns that they have. Yeah, so what's interesting there is that, obviously the application is written in Ruby, but managing and maintaining GitLab doesn't require that experience necessarily, especially if you're using your Omnibus package, because that package is really wrapping up all the services and the tools required to run it so that you can essentially install it and not have to deal with any other configuration. Yeah, I think to piggyback on that, we also need a conversation to consider how they're hosting it today. Maybe we can simplify the management of their platform by using something like the Docker containers, right? It's just a different approach that may simplify things. Yeah. And in fact, with 10.1, deploy the complete Kubernetes cluster to GKE, right? The whole idea of deploying to the cloud becomes that much simpler. As we're moving to that cloud native world, perhaps at this point, they start thinking about a cloud deployment of GitLab, or eventually even moving to GitLab.com. It would be a good next step in reducing the overhead of them hosting all these solutions internally. Yeah, it'd be a good conversation to have with them around their infrastructure options going forward. But the final challenge we heard from them was just the frequency of upgrading, right? The associated fear of that process based on the past. But I feel like this could be pretty easy for us to address. Yeah, certainly. In my opinion, with the experience that I have with customers that I work with, DevShop this size, a few hundred folks, the installation should be relatively small. And the option to have no downtime upgrades, using the omnibus package, should enable them to keep up with that monthly release cycle. And it should be pretty straightforward. That said, when you start moving into sort of the larger multi-node, high availability setups, there's definitely some things you need to consider when orchestrating the upgrades. I recently had a conversation with our support team. And they mentioned that, depending on the customer's ability, it's a lot easier in these multi-node setups. Imagine 15 or 20 nodes that are out there. It's much easier if they can afford a little bit of downtime. Maybe an hour downtime. They can turn everything off, upgrade everything across the board, turn it back on. If a customer does not have that freedom, they can certainly go through and do a zero downtime upgrade. But it does take some managing and orchestrating to roll those things out. But again, back to our earlier conversation around Enterprise Edition, having that premium support, having live assistance, we can get our support folks on the call with them and help them, regardless of the size of their installation, we can get support to help them with those upgrades. And frankly, the last thing I want to talk about, or I would talk to them about is the frequency at which they have to do the upgrade to GitLab. Now, obviously we push out a release every month. Not everyone can adjust and or plan and take the time out to do an upgrade every month. And it's really a choice. So I have customers that are a couple of releases behind. And sometimes intentionally, sometimes just because they don't have the time that month. But what's really nice about the upgrade process is that you can just get the latest package. You can be a couple of releases behind. You can upgrade that next one up and move on forward. Right. So I think the next thing we'll do on the next call, obviously there's a lot of different possibilities. And it all comes down to what's the vision that you as a customer have going forward? Right. So what's the customer truly trying to do? Is there an initiative around cloud deployments and those kind of things? Is there a goal that we can support within the organization and help them simplify, help them save some money and make this whole process easier for them? Because there's so many different methodologies to it. So those will be our next steps. Absolutely. All right. Reach out if you have any questions after your next call. Thank you. Thanks.