 The other continuous integration tools, they're all open source software, which is great, but that sort of comes with some of the responsibilities of you need to really dig to figure out how to manage it correctly, how to set things up. So that was probably the biggest disadvantage of, you know, it's a collection of open source tools that didn't have the proper documentation that we needed to move forward. So once we started looking at you guys in GitLab, it really enabled us to consolidate those things, all the documentations in one place, the services that were available. It was really easy to figure out what we needed to do, and your guys support has been a big help as well, and later than us to, you know, rapidly deliver and stand up these environments. Our collective vision within LinkedIn and working with you guys and all these other companies is how do we automate and take out human error from the equation. So our goal is the moment code is checked in and has been reviewed, the testing life cycle, the deployment life cycle, the security vulnerability scanning life cycle should all be automated. So it's more of humans reviewing reports at the end versus people tapping to do the inspection of themselves, validate, you know, parts of the development life cycle, where we really vision that these tools can do a much better job than humans can. They should be used to aggregate these results and let humans make decisions. And, you know, take people out of that equation, you know, we're not trying to take you, you know, replace human jobs, but how can we repurpose people to do what people do best versus, you know, laborious efforts like pen testing mobile applications or pen testing web applications. A lot of that stuff can be automated through scripting tools like Amazon Device Farm, all which GitLab can automate and push out. So we're going to see what tools can we bring in to automate that process, tie them in to GitLab and, you know, automate everything, virtually everything. This was a good opportunity for us to go in and sort of do and all of this, what are our gaps in our development pipeline where we need to fill in of, you know, is it code scanning, fortify, or additional code scanning you guys might be able to offer to some of the tools that are embedded in your guys' product. But it's giving us, you know, we had a time on to migrating over simply because it was a good opportunity to improve processes while we're going through that migration. So it's not necessarily a bad thing. It's just, you know, we're looking at it as it's an opportunity to improve the outcome at the end. And looking at it as it's not only learning opportunity for our customers, but it's learning opportunity for us to what are the best practices that we can, you know, collectively share. And even with, you know, you guys have, you know, there might be things that we're all collectively learning that we can, you know, help the community together because, you know, this is, this isn't just a proprietary company effort on our end or your guys end or even our customers end. It's, I look at it as an experience for all of us to improve processes, security, compliance and everything that goes along with that.