 All right, I think we'll get started. I don't understand too long between you and lunch, so thanks for coming. My name is Thierry Carras, for those who don't know me yet. I'm the general manager for the Open Infrastructure Foundation, which is the new name for the OpenStack Foundation, which you might have heard of before. I'm also the vice chair for the Open Source Initiative, so multiple foundations, and also a fellow at the Python Software Foundation as well. And today I wanted to talk to you about the role of Open Source foundations in helping produce today's Open Source software, what's the exact role of Open Source foundations in 2022 to help the production of Open Source software. And I wanted, since it's a relatively small group, just start with a traditional show of hands. Is anyone here working for an Open Source foundation? And is anyone working with an Open Source foundation? Good, so there will be plenty of time at the end for more open discussion if you all want to add to what I present, and I'm welcoming the diversity of viewpoints here. So there's been a lot of those foundations created over the last 25 years. Some of them are independent foundations. Some other are sub foundations within a larger organization. And there is a reason why those were created over the course of the last 25 years. They serve a number of basic functions. One of those basic functions is guidance, especially in the early days where Open Source was young. There was a lot of education that needed to be done to explain how this whole Open Source concept is working, especially towards companies that weren't very familiar with the concept. So one of the key functions of an Open Source foundation is to give that guidance and that education about free and open source software guidance on the type of licenses that you should be using. And that's still today a major function for Open Source foundations. The second big basic function of an Open Source foundation is to provide an asset log. It's a neutral place where to place assets for the project like trademarks or governance so that no specific organization is holding the keys to the kingdom. I remember when OpenStock was started in 2010, it was famously created by the reunion of a project at NASA and a project at Rockspace. But in reality, the trademarks, the governance, was fully owned by Rockspace. And that's really served as an impediment to getting more participation into the project. None of the big players, none of the major organizations would join and participate in the project while it was under the sole control of Rockspace. And that's why we created the OpenStock foundation in 2012 so that we got participation from IBM, Red Hat, HP, all of those companies that would never have joined if there wasn't this neutral ground for collaboration. The third basic function of an Open Source foundation is to give fiscal hosting, basically a legal standing for an Open Source project to receive and process money. And that's a key function once you start wanting to spend on continuous integration of resources or any kind of staff, you have to be able to receive and spend money. And finally, the last basic function of an Open Source foundation is to provide project infrastructure. Giving, running an Open Source project, you had to run hosting servers for the code repositories. You had to host servers for processing chain requests, mailing lists, hosting, continuous integration, all of those things that are unnecessary for an Open Source project to function, you would go to an Open Source foundation because they would have a package to let you host your project there. And so in summary, the basic function of an Open Source foundation is really to enable open collaboration, to just make it possible. And so can we really establish a topology of the myriad of foundations that exist? And what is the landscape looking like? How do you compare them? How do you look at them? One way to look at them is to look at the type of scope that they have. So for example, you have Open Source foundations around the programming language, as it became pretty clear that programming in a language that is owned by a specific company might not be the most technologically choice in the world. So there are a number of foundations, Open Source foundations around a specific language, like the Python Software Foundation, or the Rust Foundation, all of those are centered around a programming language, which give them a very nice scope and mission. Another popular way of scoping an Open Source project is around a defined project, like the GNOME foundation, for example. It's also how the Apache Foundation started, or the Linux Foundation started, or the OpenStack Foundation started, obviously. And then the scope is really to sustain the development of a specific project and make sure that it's successful. Then you have domain-centric foundations, like the Open Source Geospatial Foundation, which you might not have heard of yet. It's around serving a very specific population of users. And actually, the Open Infrastructure Foundation is a domain-centric foundation. We're trying to serve the people that provide infrastructure, so you are targeting a specific group of people and try to make sure that they have Open Source tools to fulfill their missions. And finally, there is the generalist foundations, like software in the public interest, or the Linux Foundation of today, or the Apache Foundation of today, where there is no very specific scope. They could tackle a variety of Open Source projects. It doesn't have a domain. It doesn't have a specific project around which to collaborate. Another very popular way of looking at Open Source foundations is to look at the fiscal regime they have, especially the US distinction between 501C3s and 501C6. So I don't know how many people in the room are familiar with the difference. Probably a lot of you. I'll just summarize it. Basically, the 501C3 is in service of the public interest and is funded through sponsorships, whereas the 501C6 is in service of its members. It's more like a trade association. And it's funded by membership dues. So on the surface, it sounds pretty simple, right? The 501C3 are the good guys in service of the general public, whereas the 501C6 are the evil corporation groups that tried to undermine Open Source. But obviously, things are not that simple, especially today, since the IRS has stopped giving Open Source foundations for the last 15 years now, 501C3 status. They do not recognize anymore the production of Open Source software to be in the general public interest. So for example, the Python Software Foundation was created in 2001 and is a 501C3, whereas the Rust Foundation, which is extremely similar in its mission and goals, is a 501C6. So it's really, and they have a lot in common, right? So this evil, good distinction might be too simplistic, especially in both cases, those are nonprofits. And they are both raising funds toward a mission. And the mission is studied in their bylaws. The way they do that is slightly different. In C6, you would have organizations that pay membership dues because they align with your mission. But they have a more direct control on the way the organization is spending the money. Usually, they have representation on the board and can fire the executive director, approve budget, et cetera. Whereas on a C3, organizations pay sponsorship fees because they align with your mission. So in theory, they don't have that direct control of how the money is spent. But in reality, obviously, they have indirect control because if you displease your sponsors too much or if the mission that your activities are not in line with their interpretation of your mission, obviously, they will stop paying sponsorship money and then you will be in a difficult position. So clearly, there is direct and indirect control over how the nonprofit will spend its money. And you can totally have a C3 that serves its sponsors. I mean, I won't name names, but it exists. Like it can be indistinguishable from a C6 that serves its mission. Like you can also have a C6 that is primarily focused towards its mission and not necessarily towards maximizing membership money. So details matter. You have to look slightly beyond that simplistic distinction into you have to read the bylaws. You have to look at the mission. You have to look at how the foundation is governed. Like who has representation on the board of directors, for example? Is it only corporations that give money? Is there a fair representation for individual users that may or may not have to pay? It's like, for example, at the Open Infra Foundation, we have one third of our directors that is actually elected from individual members and the individual membership is free. So basically, any member of the community can get representation on the board. And it's a C6. So it doesn't necessarily, the distinction is interesting there. You have to look at the track record. Basically, look at the mission, look at the activities, look at the annual report from those foundations, and look at whether they seem to serve their mission or they seem to serve more of their membership. And finally, they're all different. So it's really difficult to build a clear topology or say, well, those are good, those are bad. Which one should I choose? I've been personally using a framework to try to look at those various foundations. And it's about considering the why, the who, the what, and the how. So the why is the dimension where why is this foundation existing? Like what's its mission? And how strongly does it adhere to its mission? For example, the Free Software Foundation is a good example of a foundation that is extremely strong on the why. They will reject sponsorship money if it doesn't fit their view of the world. So it's extremely strong on the why. If you look at the what, it's like what's the scope of the foundation? Is it tailored towards a specific project, programming language, domain, or be more of a generalist foundation? How strongly does it define its scope? And for example, the Python Software Foundation is clearly a foundation that is very strong on the what. The who is, whether the foundation is centered around this very specific community, established community. Is it more community-centric or product-centric? And so what is the primary definition is the primary definition of the foundation? Is it more around a group of people and trying to bring solutions to them or more around a piece of technology and trying to make it widely adopted? And finally, the how? The how is how strongly the foundation has like prescriptive principles? How are they mandating the usage of free and open-source software tools? Are they mandating use of a neutral governance body for technical governance of the projects? Or is it like more open? How prescriptive are them in how open-source projects should be operated if they are hosted under your foundation? And the Apache Foundation clearly has like the Apache way that describes how projects under the Apache Foundation should be run. So it's a pretty generalist foundation. You can have a variety of projects below it, but if you host at the Apache Foundation, you have to follow the rules on how those projects should be governed. And what type of tools they should be using. So as a quick example for the Apache Infra Foundation, in terms of the why, the mission is to make key technology accessible to everyone. Like when we started this foundation, basically the infrastructure was only proprietary software and proprietary companies. And so we're on a mission to make sure that there is open-source solutions for providing infrastructure, those role-based infrastructures so that everywhere around the world you can build and potentially develop interesting applications on top of it. In terms of the what, it's clearly centered around infrastructure software for the same reason. It's not about like developer tools or anything. It's really giving every country around the world or every specific use case an open-source solution for providing infrastructure. And the reason for that is the who, because we actually attracted around OpenStack a bunch of people that are interested in using open-source software for providing infrastructure. And so that's where our audience is. That's where our family is. So obviously that's why we extended beyond OpenStack to continue providing open-source solutions to that same group. And finally in terms of the what, we have a set of principles, so open-source, open-design, open-development and open-community that we found our key to enabling successful open collaborations. And so we are trying to encourage every project under us to follow the same set of principles not just because we think they need to, but more because we think it's the way for them to be successful. And so you can look at foundations through that lens and see how strong they are in those various dimensions. For example, you can just look at the what and the how and try to graph foundations based on are they more permissive on the how, very flexible, or are they a bit more prescriptive on how open-source projects should be operated? Or in terms of the what, are they very specific, covering a very specific corner so your project might not fit? Or they are like very open, very generalist on the type of project that you can bring to them. And so for example, the Apache Foundation is a very prescriptive foundation but also a very generalist foundation. The Linux Foundation is much more permissive, they are extremely flexible in how you, the type of project that they will take and also very generalist. That's why they're actually very successful is because they can actually accept basically any open-source project. The Open Infra Foundation is a mix where we are a bit specific on the scope because it has to be infrastructure software. We also are a bit less prescriptive than the Apache Foundation but quite up there in terms of how we, the type of project that we would, we would, for example, we are not interested in hosting like open core project or a single company because we think we do not provide value if like there is not a large collaboration across a lot of organizations. There's just no point in establishing a neutral ground for collaboration if it's only one company playing in it. And the Eclipse Foundation is quite in the middle. They started at the very specific foundation slowly moving towards a lot more generalist foundation and they have like a set of principles they also apply for governance of their projects and I'm happy to be corrected there if people think this graph is not representing their foundations correctly. So back to the main topic, who needs foundations in 2022 because now that Open Source is one we've seen services like GitHub or GitLab that provide a lot of the functions, the basic functions that I mentioned earlier. Like for example, providing those infrastructures that's basic project infrastructure service. You used to have to go to a foundation well, you all spin up your own but it was more convenient to go to a foundation just to have access to that project infrastructure. And now it's basically really available on the shelf at through GitHub or GitLab or all of the other software forges. And in terms of guidance, those services also provide a lot more guidance. Well, there's a lot more education or open source and it's much less mysterious for the companies that are involved in Open Source. So there is less of a need for guidance but we're also seeing more and more of that guidance being given on the sites themselves. Like GitHub has a licensing choice website that helps you pick the right Open Source license for your project. So you don't need to go to an Open Source foundation for that expertise on how to set up an Open Source project anymore. That leaves more complex things like the asset log for trademarks but we're seeing more and more hosting as a service. Fiscal hosting, yeah. Open Collective is one service that also provides fiscal hosting, GitHub sponsors. There are other ways for projects to accept money. They don't necessarily need to go to a foundation to have legal standing to receive money anymore. It's not perfect yet. It's clearly progressing in that direction. And finally, that leaves trademark but you also have very simple foundations like the Open Usage Commons that provides a trademark asset log. Just that for a project. So the only thing you need is a box where to put your trademark so that nobody says it's a given company that owns it. There are solutions out there for that as well. So basically most of the basic functions are covered by other services today and I don't expect that trend to reverse anytime soon. I expect actually GitHub to do more and more to enable Open Source projects to be created directly without the need for an Open Source foundation. So why should an Open Source project use a foundation today in the age of GitHub? And truly, we've seen a lot of projects that are not going through foundations, prefer to avoid it. So in order to be relevant, Open Source foundations need to evolve. They need to go beyond those basic functions that are more and more covered by other services. They need to go from beyond barely making open collaboration possible to delivering advanced services to make open collaboration successful. Like the key role of an Open Source foundation 20 years ago was really just to make that Open Source projects possible. Now you don't need a foundation today. But you might need a foundation, and that's optional, you might need a foundation to reach a certain level of success or to get help in getting to a successful project. So let's cover what are the advanced functions of modern Open Source foundations. So first there is this function around pooling resources, going beyond merely fiscal hosting and providing a framework for enabling a lot of different organizations to pool their resources together and have means to establish a budget and spend the whole thing. That's what directed funds are all about and Linux Foundation has perfected that model really well. Another advanced function of an Open Source foundation which might not be obvious at first is to cultivate audiences. After a while you basically attract a number of people towards your various properties. Could be social media accounts, could be events, could be online publications, could be podcasts. You basically created an asset which is the audience that you can reach out to and you basically going through that foundation gives you access to those assets. For example, the CNCF has a network of events around KubeCon, Kube Days, all of those things that are relevant for any project in the cloud native space. So it's extremely attractive for those projects to be exposed to that audience that KubeCon's created. And the third advanced function of an Open Source foundation is to balance and develop what we call the three forces. We think that for an Open Source project to be successful, it needs to cultivate and balance those three components. Developers, obviously, they write the code so you have to make sure that you deliver services so that they can do their job correctly. Users, because obviously the software is not consumed or is not well known or is not well explained or not well documented, that's not very useful to write it. And finally, you also need to cultivate an ecosystem around it because otherwise you are lacking the funding to get those developers that are building the project hired and paid for. So you basically need to have services. Well, you need to balance and develop those three forces for your Open Source project to be successful and that means a foundation needs to have advanced services that cultivate and develop those three forces. So the first category is developer support services. So that's where you can rely on expertise for community management, for onboarding, for mentoring, for project infrastructure support because sometimes those project infrastructure services like GitHub are not enough or need to be configured or need to use other resources or in that case you need people to still work on project infrastructure support. Can be organizing specific events around developers meetings so that they get to work together more closely, build trust. At the Open Infra Foundation we have a specific event called the Project Teams Gathering where it's only project teams that are working together to get to common understanding and share trust and get work done in a very productive setting that's not like a wide conference. Release management is another and I learned from the Rust Foundation yesterday or was it Tuesday around like grant money, like specific features that you can get grants for so that they get added to the project. That's why this list is clearly not extensive. If you look at the user support services, well you can run big events with keynote and breakout sessions that contain a lot of information for users, education for users and how to use the software, what it does, et cetera. You can have user-centric, you can support, have people share user-centric special interest groups so that encourage users to share their experience which is not natural necessarily for them so having someone that works actively to make sure that they come out and share their experience for others. For example, we have what we call the large scale SIG on OpenStack and it's one that I share personally that is about making sure that the people that have very large deployments of OpenStack share how they got there for others to benefit from. What else? Local events support and industry event participation. That's making sure that we support local groups that wanna like meetups or OpenStack days. Those things are very important so that people can find a place near where not everyone has the opportunity to travel to Dublin so making sure you support all of those groups, international groups that are building those local events but also just participate like I'm doing today to other industry events so that you spread the world out. And also make sure that every event, every everything you organize has a good feedback loop between operators and developers of the software. And finally, ecosystem support services. Those are more so that you can have successful companies built around the successful businesses built around the software. So that includes brand building, trademark protection, trademark management, certification programs who gets to use the world, the protected world, produce market insights like running a user survey to make sure that you give your ecosystem of companies a good data on how the software is used. That's also the bottom space of this event like the booth space so that they can market their wares. And also you can also have a website that lists all the companies that are involved in that ecosystem so that if you're looking for services you can actually find it here. So in conclusion, beyond the asset lock and enabling a basic open collaboration ground the value add of modern foundations is to allow to transparently pull resources providing a range of services and a set of established assets to make open collaboration around a project not just possible but successful. All foundations are different. I encourage you to compare them. Don't just look at the fiscal code article, look at the mission, look at the governance, look at the track record, look at the how, look at the who, look at the why, look at what. Look at the expertise, look at the established assets. And finally, I think foundations are still needed in 2022 but not every project needs a foundation to reach its full potential. It really depends on the level of impact you actually need to have with your project. If it's just a small library and like five maintainers you don't really need a foundation to make it successful. And let's be honest, those services, those advanced services that I just mentioned are costly. So not every project will be able to afford it. Not every project will gather sufficient ecosystem interest that money will be spent on a foundation that will help all of those advanced services to make the project successful. So I really expect that there will be more and more of a split between projects that don't need foundations and will just use the services that are packaged in software forges and all of those services and those who will use foundation because the impact or the potential is bigger. And that's how I think it's able to go but I'm open to discussion now. So thank you for joining and thanks. So questions, remarks, comments. I think we'll need the mic maybe. So the question is, are there differences in approaches between US and the EU in foundations? I don't think so. Like most of those are very international organizations but there is this perception, especially in today's world where people are much more like looking into where the money is going. And so I don't think there are a lot of differences between the way EU based foundation and a US based foundation would function but for a number of reasons, digital sovereignty and other trade wars. It's easier if a foundation has like local representation. For example, in the EU, if you wanna get grant money it has to be a EU based organization. There's just nowhere around it. They will not pay directly an open source foundation in the US or in China or wherever to with EU grant money. So I would say the difference is more like in how to be very close to the group of organizations that want to put their resources together and if there is a geopolitical component into it then they will prefer European subsidiary or others. It's interesting to see that the 501C3, 501C6 type distinction is not necessarily relevant in Europe, so a very popular form for European based foundations is the Belgian AISPL. And it's actually a trade association. They don't really have a model for international associations in the public good. It's actually like the same type of organizations can serve both types of they're much more flexible than the US organizations. So I would say some of the distinction is not necessarily pertinent but in terms of operation type of services I think it's very comparable. Sometimes with the more generalist foundations the scope or mission tends to can potentially overlap and align with other foundations. Do you have any insights about lining up and collaborating with across foundations? It's a good point. Like for example we work closely with the CNCF because basically infrastructure is provided up to a certain layer and that layer today is basically Kubernetes and so we're working closely because the same group of people that would deploy OpenStack would also deploy Kubernetes on top of it. And so clearly there is like overlap between the type of audience that the CNCF is built around Kubernetes and the audience that we're targeting. They are much more about like cloud native development on top of Kubernetes. So it's I guess where the difference lies but clearly when you talk about Kubernetes it's either you're deploying it and you're an infrastructure provider or you're using it and you're a developer. And so there is on this Kubernetes infrastructure provider group there is clear overlap and we're actually collaborating across we're encouraging the collaboration between the technical groups that working on OpenStack and working on Kubernetes. There are like regular sessions between the Kubernetes steering committee and the OpenStack technical committee to make sure that the technical collaboration is working but also to share the experience that we have on a lifecycle of a very large project like past the hype, how does it go? They're basically encountering the same type of issues that OpenStack has went through so we want the next people to go to learn from history and not necessarily repeat the same patterns. So that's why we're trying to share as much as we can. We work very closely with the Ansible community as well. Like every time there is adjacent communities we're trying to make sure that at the lowest level the developers, the technical groups working on the open source software are communicating, participating, joining the other conferences making sure that that overlap is not a problem but it's true that there is some competition between the foundations that are targeting the same scope, obviously. That's why it's important to have a framework to see what the differences are and to be clear, I'm not when I did this quadrant thing I'm not saying that the top right is better than the bottom left. It's all different, it depends on what you're looking for. It's just that saying that they're all the same and you should just pick the biggest is might not be the main answer. It's just like you need to look at them because depending on what you want those strengths are different. Any other comment, anything that was wrong that I should fix? It's a very new presentation. And I realized the irony of presenting it here. Yep, go ahead. I work for OpenSource Collective which puts me in a weird state because I'm like okay, we should offer all of these things because we already do fiscal hosting which is one of the main stuff that you do. What strikes me is that it seems like more and more it's just specializing in events and branding and marketing and holding that space. Trademarks are things that you can offload to a service. I'm wondering what you think the future is 10 years from now for where we're going with foundations especially as we're seeing a proliferation of foundations. How do you think it's gonna change? I know it's a weird question, I'm just really curious. So I've been looking lately at the future of OpenCollaboration because there are a number of, here it's a bit of an echo chamber, it's all about OpenSource but if you look slightly beyond there is technological shifts that are affecting potentially the way we can use OpenSource tomorrow like AI generated code that is generated by machines so at least in the US cannot be copyrighted so OpenSource licenses cannot be used on it. We'll see more and more of complete pieces of software being generated by AI in the future and how does that affect like how we will openly collaborate in the future? My position, personal position is that OpenSource foundations should be about OpenCollaboration more than they should be about OpenSource. A value add is really enabling this neutral ground for various organizations to cooperate and not reinventing the wheel, everyone reinventing the wheel in their corner. The tool of choice to do that today is OpenSource. Is it going to be OpenSource tomorrow? I'm not sure and so be a bit forward looking and making sure that those foundations also serve those future ways of doing OpenCollaboration that might not include OpenSource licenses or might use some other form of systems. So 10 years from now, I think we'll see a difference between foundations that really took that turn early and realize that centering on OpenCollaboration will give them an edge on the next wave of how we do this because OpenSource is not perfect. Like there is clearly a sustainability issue. There is systemic and that is really difficult to fix. So we might come up with new ways of openly collaborating that are more fair and more sustainable for the production of the software. And so I expect some foundation will be very OpenSource centric, will stay around OpenSource and become less relevant over time and some others will focus more on OpenCollaboration and be slightly ahead when those other forms of collaboration will come. We don't know. Could you say a few words on the life cycle of foundations? Can because we've gone through it. So if you do a foundation around a project, clearly at one point, the project doesn't need the level of support that it needs to reach mainstream. So for example, for OpenStack, clearly at one point, it's like 10,000 people at the conference and it's like everyone wants to be a part of it, et cetera. And then there's this phase where the project finds its users, finds its niche, and the more it actually has a defined scope the better because if you have these major platforms that go in every direction, at some point it just crumbles under its own weight. So doing an OpenSource foundation around a project is, I mean, there is a reason why the Apache Foundation, the Linux Foundation, the OpenStack Foundation found a scope that is beyond their original project, purely their original project. It's because the only way to continue the existence of the organization and employing the staff you have is through diversification in the projects you take so that new projects can take over past projects. So I would say there are two approaches. You can just be fine with it and let's just let the foundation become less relevant over time and finally it doesn't have any staff or gets absorbed in some other larger foundation. Or you can try to find your position in that landscape and if you think the mission is still relevant, then continue. For me, I think the mission we have is still relevant. I don't really want a future where everyone is using Kyle's services for providing infrastructure over all over the world. So I want people to have options. I'm perfectly fine that they are successful, but I want all of the world workloads to run on Amazon and Microsoft and Google. I want a world where it's still possible to experiment and do things in the corner for various use cases, for weird compliance reasons, whatever. So that's why I think the mission is still relevant, even if the software is basically done now and still massively used, but it doesn't require as much development of the three forces as I described. So it depends on where you are and where you want to go. Terry, so that's quite interesting when you were saying there about maybe there'll be evolution of the foundations and integration of the foundations. So what I find interesting at the moment is we go back to the OpenStack days and that was primarily for OpenStack and then you moved into Open Infra. And you look at the Linux Foundation and the CNCF has gone under the Linux Foundation. Whereas in a way, I wonder, does the CNCF is that giving us a broader foundation around cloud computing itself in the sense that I suppose it's concentrating more around cloud-native computing and all the different projects that come in under that, so it's not under a specific project as opposed to how the Linux Foundation and the OpenStack Foundation started. So maybe is that how we look at it or is that just too simplistic an idea that we can have a more generic foundation that covers the different projects? I think it's simpler to have a foundation when you connect it with an audience. And so the problem with generalist foundations is that you either start from scratch or you have an audience of corporations that can fund. But you don't necessarily have the audience of people that are interested in the software. And so what the OpenStack Foundation built or what the CNCF built is an audience that is relevant to a number of projects, and that's valuable. Whereas what the Foundation brings is just like a full address book of all the companies that might join your project fund if you start it, it's sure it's a very important financial component in the success of the project. But at the same time, you still have to build that value from the ground up. You still have to attract enough people that are committed to the project or interested in using that category of projects. So in my view, the most successful will be the ones that have a better sense of their audience and capitalise around it. That's why the who is actually more important than it looks in that list. It's like, did you build an audience? And when we're talking about life cycle, when we are looking at the future of the OpenStack Foundation, really it's like, take a step back and take stock of what you built. And what we built in the end, what will remain, is more like this family of people that are used to sharing their production use cases, are happy operators able to, interested in sharing how they operate things and providing infrastructure, and interested in using open source solutions to do that. They could use proprietary solutions, they are choosing to use open source solutions probably for a reason. And so that group is realising that OpenStack doesn't matter as much as serving that population, making sure that we find or we enable open source project that are relevant to the same group. So to me, it's much more valuable to do it around an audience. And like I said, the CNCF has done very well around clean native applications and all the tool kits you need to run those. I think we're successful at targeting that very specific group of infrastructure providers using open source solutions. But you will see that in other areas, like the Eclipse Foundation has also some success around AIoT and the people that are more serving in this real use cases, it's just that sometimes it's by accident. It's like those foundations do not necessarily realise how important it is to identify that audience. And it took us a while, like it took me eight years to realise that was the asset we had, was that the group that we assembled, because you're focused on software and you just produce the software, and I mean, I'm an open source developer, I just, I thought that, you know, writing good software is enough, but if you don't have the audience, or if you don't connect, then just worthless. I think we've passed the time. Okay, well, thanks again.