 I remember like when I started my own journalism career which was like 13 or 14 years ago, I completed my course and the first job I got was with Linux for you magazine. So I had like for the day one, I had been an open source journalist. Back in those days, one of the challenge was that we had to go out and educate companies that why you should use open source, what are the benefits? But now almost everybody is using open source. The question is who is not using and why not? So the new challenge that we see is that these new users of open source don't actually understand how the open source process actually works. That why you should send your developers to events or why they should contribute in their office time. So since you have been involved with it for so long and you deal with a lot of customers and clients, do you see this pattern there where companies don't understand? Yeah, I think so. I mean, let me say that I mean, I think at the start you're absolutely right, which is that one of the good things that's happened with open source is that most enterprises now have an open source first strategy and so anytime they're doing a technical evaluation, they need to also look at what options available open source. And so that level of corporate sort of top down, sort of, hey, this is an important part of business strategy and should be considered. I think it's very good. I think that businesses are very good at taking care of themselves, right? And so, I mean, that's kind of the nature of a commercial entity at some level. And so I think that people are very much like they appreciate all of the benefits of open source, right? Because open source allows you to sort of, protect yourself against the lock-in, the ability to extend the product if you need to, the ability to just solve a problem if you can't get someone else to solve it for you because it's super important to your business. And so I think that a lot of people appreciate that part of open source when they're looking at it from a commercial organization perspective. I think that people don't really understand how it works. I think that at the end of the day is, I think there's two parts to that, right? First of all, realistically, if you look at most, well, I don't know if it's the most, a large number of Apache projects that have been started in the last five years or so are developed probably, maybe 70, 80% of the development time that goes into those projects is by one or more companies that are directly benefiting from the success of those open source technologies, right? And so it's a former source paid open source or a sponsored open source, right? And so the idea that all open source is done by people who, in their free time in the garage, it's not true for a lot of these projects, those super successful projects that have been a lot of options. Not to say that it does exist, there's definitely cases where it's been very successful. And so my perspective on it is that if you think that in that context, it's not gonna be realistic that every organization is gonna be able to invest developer time directly against adding new features to open source projects, but I actually think that the sort of easier win for most organizations is that they can contribute to the quality of open source projects, right? So making sure that you are reporting back things that you see and collaborating to fix them and probably helping out to fix them sometimes is I think what would be the goal I would first say should be a goal for most enterprises using open source software is is that if you're benefiting a lot from this, find the time to help with quality. I think that realistically, most organizations unless they have a really important feature that they need are not gonna be able to contribute the amount of time that it takes to build something from scratch, but they can definitely improve the product. And that is through both providing bug reports, but also more possible trying to allow people a little bit of time to help fix things. And so it's actually a funny situation that just happened very recently is we had a customer who found an issue with our product and then it turned out that it was actually an issue with an open source library that we were working on. And so the customer actually went and passed the open source library themselves because I think that the engineer was like, hey, I see what's going on here and I think I can fix this. And so I fixed it and then we were able to incorporate it faster and give it back to them. And so that's a nice thing when it happens. We as people driving open source, you can't expect that to happen very often, but it's really nice when it does and I think just try to raise that. Right, the way I've talked to a lot of people, the way some people submit as that, if you are consuming an open source, there are two ways you can contribute. One is either through currency or through code. And as you rightly mentioned, that not a lot of companies do have developers resources that they can actually invest. So either they sponsor a project or when they work with a vendor who is either maintaining or contributing to the upstream, so they are indirectly through currency supporting that work because you are working with a vendor, that vendor is, as you gave example, that he patched, the developer patched, so you are giving feedback to that vendor and that vendor is putting all those changes to upstream. So I really don't think that if you are touching open source in any way, unless and until you are just taking the whole code, forking it, running it your own fork, then you are creating a lot of technical debt, then you will not even survive, no point in you. But I think if you're consuming open source, you are going to help open source in one way or the other, there is no escape. You will be working with a vendor who will help, so I think that's a neat thing people don't understand, but it happens to give a very good example there, yeah. I think you're right. And I think the other thing that is interesting is one of the things that Apache really focuses on is community over code, which people who are not familiar with is probably a little bit strange when they hear it, but it's the idea that the successor project is driven more by the community that's working on the project and their collaboration consensus and driving towards sort of good solutions than it is about one piece of code. And so we actually talk about in many cases, there are PMC and or committers to projects that don't write code, right? They may provide documentation, packaging, they may just help out a lot of testing. And so I think it's very important to appreciate all of those things and that's actually something to go out to people who are using open source as well, is that even if you can't sit down and be a developer that's going to write the next feature or fix this bug, that doesn't mean you can't add value to open source and help those communities out. And in many cases, those things are actually sorely missed in those communities, is that you've got developers that are happy to write code but are in less comfortable writing documentation. And so if someone else could come in and say, hey, here's a couple of quick starts or a tutorial that can help out a project a lot. Right, so if there's a company, I mean, you did give example very nice, if there's a company who's using open source and working with a vendor or something like that, and the company itself, they don't have developed their small startup, a small company, they don't have enough developer, they can just, or I mean, when they don't have developer, they cannot even become part of the community to go in there. So how can they realistically contribute even a bit? What are the options? Since you have been in the community for so long, what are the kind of opportunities for them to participate without creating it as, oh, why should we even bother with that? Or we can just pay somebody and be done with it. But how can they get involved? Well, I think going back to what I was saying is that it doesn't have to be a developer that's writing code, right? If you have a person who's using your product, like use cases is a good example. So one of the challenges that open source people have is that they want to figure out ways to test their product. And so they can come up with all sorts of unit tests and synthetic data, and I work in data a lot, right? So you're always coming up with synthetic data sets or examples of potential problems. Customers can sometimes, depending on where they are, share their use case and share details of their use case. And that can help people, so that can help the customer because it means that the open source project can incorporate that set of use cases into the test suites that are run every time someone does a release. But it also, so that helps out the users, but it also helps out the community because the product can be better. The quality of the project can improve. And so that's one example, but there are many examples of, hey, come in and tell us what you're doing. Tell us what's good with the product, what's not good. Remember that many people are volunteering on the project. One of the key things, right, is that Apache, while there are many people who are paid to work on a Apache project, the relationship to the Apache project itself is something that is a person to the, chair of organization, right? So it's that relationship that actually defines what they can do. And so while they may be being paid by someone because that person is very interested in adding certain features or functionality to an open source project, the relationship is a personal one. And so that person at the end of the day is the one who's actually making that commitment. And so if you come into a community, appreciate those people for what they're doing, where they're giving their time and when they're spending their time and what they're caring about, because open source development, while maybe in many cases paid, is still something you have to be passionate about in order to do a good job in the community. And so coming into the community and saying, hey, these are the things that I've learned. These are the things that don't work well. These are all really good things to do. Say, hey, here's some documentation. I just wrote up a little, I wrote up a short thing about how we do our use case and how we use the product to do that use case. Do a little video. All of those things are very helpful to open source and can be done by anybody that doesn't have to be done by someone itself. Right, and it doesn't cost anything. You're just sharing your, but yeah, that's a very, I was talking to somebody a few weeks ago at DockerCon and when I asked, his thing was like, the biggest challenge for us is that because they are fully open source project and they're like, I mean, we wish that our customers will just tell their story. We don't want anything else. Just come out and tell that you're using our product, how you're using it, what problem you face, how you solve them. You go ahead download from a GitHub, we don't care, but at least tell us the story. That will help a lot in mind share and in our developers to get fit. Yeah, that's excellent point.