 I got a lot of credit for the work that happened on the CRA but nobody changed the law because I asked them to. People changed the law because we had an awful lot of people putting an awful lot of time into this and I did some organisation work and sometimes I was very visible but there was a lot of people putting in the work. One of the reasons people, I think, agreed to work together was because when we're doing calls I'm pretty strict on timing and make sure that everyone gets their time so we're a little bit over time already. I am going to be keeping my usual style when you're at your five minutes, I'll give you a hand signal and we'll have time to cover everything we're trying to cover. So the policy side of the CRA, it's a lot of work but you, at the end of it, the text is agreed and you can be satisfied with it or not but you kind of get to walk away and then somebody else is left when the dust settles having to actually comply with this legislation. So this panel is about putting the focus on those organisations that are going to be dealing with the CRA in the next three years while we think about compliance but also in the possibly five, possibly ten, who knows how many years we're going to be working on CRA compliance. We could talk, like we could have an all day conference about the CRA, we've only got 40 minutes so I'm going to go straight to the panelist. Maybe if you want to just quickly say because for people online they probably don't see the names on the slide above you. If you want to just quickly say your name and your organisation without going to details but... Hello, I'm Muka Bruma with Linux Foundation in Europe. Hi, I'm Chirk. I am one of the board member of the Python Software Foundation. Dirk van Grilijk for the Apartje Software Foundation. And I am Enzo for the Eclipse Foundation. So to give, we've got a very mixed level of involvement and awareness on the CRA but a very educated in general crowd on the topic of policy. But, Dirk, can you start off five minutes on what the CRA is and then what is this OSS steward top idea that defines you? Right, yes, yes, so little elephant in the room. Right, so basically we have this, the Cyber Resilience Act, the CRA coming up as a piece of legislation. And just to be clear, I mean, the document is finished, it's essentially waiting for translation and adoption and then basically it goes into force in the years coming. It applies to essentially everything with digital elements, basically everything with software in it that is placed on the market that basically is somehow on the European market. And essentially what it says, really, really simple is please take security serious. Which I think absolutely everyone here will agree is a very welcome thing. So essentially this is software regulation. It's not the only piece of regulation, there are many other pieces of regulations. One which is particularly important to intend them to this one is the PLD, the Product Liability Directives, because it basically makes software a dead normal product. So that means all our waivers and liability and all sorts of other disclaimers simply go out of the window and software just become something like a cordless drill or a phone charger or a piece of cutlery. We basically get regulated the same way. Now, if you sort of like read through the CRA quickly, it actually for most people in the open source community is totally not exciting. It just basically talks about common industry good practice, basically the stuff we've been doing for over 20 years and nothing of it actually is that special. It's basically considered security. Do your testing, do your triage, basically do that of course risk-based or not blindly. Make sure you've got your updates, patch your stuff, do responsible disclosure, be transparent about it. I mean, none of that is special in the open source world and we do this routinely, I mean in the ASF, we do this almost daily basically on projects. So nothing very special there. It also introduces transparency. Now, in the open source world that's normal in the industry, that's a bit of a different sort of like case. And it does a lot of this by essentially saying that you need to sort of like have a certain level show as a manufacturer a certain level of conformity and you typically sort of like that results in a CE mark just like you find on your phone charge or something like that. Now, it's important to stress here that this is applies to basically manufacturers people who put things on the market for a payment, for money, commercially, but also free of charge. So basically whatever sort of like enters up in sort of like consumers their hands if you may, if I sort of like be very loose about it. So this is obviously sort of like also applies to open source. But what I first and foremost want to stress is that this rule is for the entire software industry. This basically means the software industry from now on is essentially regulated. And that is a massive, massive change. Now, of course, the elephant in the room is that 90% of what the software company sells or provides is based on open source. So we our communities are just as affected at the ASF. Everyone is a volunteer. There's nothing corporate about this. But each and every one of us works typically for a software company. And so basically, their employers are affected. And that means we as a community are just as affected. Now, the good news there is that that there was this concept created called an open source stewards. And these are basically what the software foundations are the open source software foundations are today because these are organizations which are in a sustained in a sustained way. So over longer periods of time systematically manage free and open source software that is intended for the commercial market for use. So it's not a group of people collaborating privately on a piece of software which they may share on GitHub, which is not intended for others to use. It's basically for sustained effort where you maintain a piece of software where you're fully expecting others to use it. And that's of course what open source is, right? Because the number of open source developers is really small compared to what you're using. It was like four billion in software development for eight trillion in actual use value. And then of course, like the CRA then contains all sorts of definitions of a manufacturing of what open source is and so on and so on. Now, so far the good news. I mean, there are a few little gotchas. First of all, it's a bit of a blank check. The CRA is filled with references to standards which have yet not been written. So we have no idea what's in them. And worse, they're going to be written by communities, by organizations like a sense and so on, which we as the open source or even the IT industry have really no relation of working with or are sometimes not welcome or sometimes not even allowed to work with. So this is not the ITF. This is not NIST. This is not the W3C organization we've worked with very long. This is an entirely new group of entities which are effectively going to sort of like write or fill in what is on that blank check of this regulation. So that is really sort of like something which is complex. As the open source initiative will tell you, the definition of open source is not really a very good one, but I'll leave it to expert Simon Phipps to explain you why that is because that's a... And then there is another very large element in the room. And that is that conformity is at the core about assessing whether something is fit for purpose. But that means you need to know what the purpose is. Is it for a nuclear power plant or is it for a toy? Because that determines the level of fitness because you have a different requirement on a piece of software that is going to let's say operate on a human. Then let's say that does that ring your doorbell. In open source, we have no control over our downstream. We have a typical commercial license, usually at the bottom is somewhere a little clause which says like, oh, you can't use it in a nuclear power plant. You can't use it in equipment which is life saving for humans. Our open source licenses can't have that. So the downstream control which is implicitly sort of like, yeah, assumed is not something we as an open source community have. The open source steward concept helps a lot with that, but it doesn't help our community because in our community ultimately we make software that is going to be used. So basically sort of like that means there's sort of like enormous amount of work still to be done. And I mean, capacity is really sort of like an issue there as well. That time we'll have to come out of your next question. Chaik, so one of the issues for foundations is going to be that foundations might have a lighter regime, but you will probably feel the need to do compliance or to assist the compliance of all your member projects in the communities and even the business ecosystem. Could you tell us what do you think this is going to look like? Or how do you think the obligations in the CRE will be implementable by these communities which are gathering such different entities? Yes, so for those of you who may not know that in Python communities we do have a lot of projects that they are maintained by volunteers, maintained by the community. Basically the Python Software Foundation doesn't really have to say of what they are doing in the project. So these projects they may actually be available in our PyPI, the Python repository that we have maintained. So it's very interesting because like in Python, the Python Software Foundation, we do have very strict security because just recently we have, thankfully, have full-time staff that's working on the C-Python, which is the Python standard distribution itself and the installer, the PIP installer. However, all those projects on the repository is very hard to like, because there's the long tail of, it could be ranged from like a project that like everybody have to use if they're using Python to a project that is like maybe someone like five years ago makes something fun and then upload it and never touch it again. So it's like the profile is very diverse. So what we can do is like we try to help those projects that is like quite important, that is like for people who, you know, a lot of companies or like a lot of Python users are using, we can kind of help those to maybe to be, well, we can't really put a seal of approval on there, but what we can do is I maybe identify those that like we have worked with, that maybe like that's more fit for some kind of more serious use, like identify them from those hobby project that maybe hasn't been maintained or some old project that hasn't been maintained. So it's kind of a thing that we still haven't figured out yet, because like what you just heard that like CR is like, it's just have been, you know, there's still a lot of emptiness that's helped to be filled in, we will have to figure it out like for those what criteria we can do, we can help the community to work with. And so by then we'll have a clear picture, especially for developers who doesn't want to read the whole CRA, we can help them to know what to do next and how to improve, like, yeah, we do want to help the community, but yeah, we just can't really, you know, ensure and put a seal of approval there, because, you know, we have foundation, we only have a small number of staff and we really can't be like having a huge department to make sure, you know, check all the bills and sign off everything. So yeah. So the issue of standards is raised, we're going to leave the last 10 minutes for standards and we'll definitely reserve 10 minutes for that. But first, could I ask you what you think at this stage compliance will look like for your foundations? And maybe Mirko, if you'd like to go first. So as we heard, the the text for the cyber resilience act is now known, and there are some relatively concrete obligations that the open source software stewards have to fulfill. And these fall to the legal entity that is formed to support the projects. And that means, of course, depending on the structure of the foundation that we're looking at, for example, the Linux Foundation, most of our projects are actually hosted under the legal entity of the Linux Foundation. So the foundation is the open source software steward. And the obligations are explicitly listed in this area, for example, to establish a cybersecurity policy that communicates internally and externally, how consumers of the software can inquire about vulnerabilities, and can report vulnerabilities back. And that is something as a foundation, we now have to implement for all the projects that we're hosting under that legal entity. I think that's a reasonable request. It includes, for example, having a single point of contact that is also publicized. So I think we probably need to hire somebody for that role, who will manage that professionally. So in the end, it's not necessarily a massive overhead for every single project. The foundations have to implement such organizations, organizational structure. But the projects and the communities under our foundations also have to adjust to that, because they have to act according to that policy. And we heard, you know, developers are participating on a voluntary basis. So implementing such rules for the playing field is something that has to be done with a bit of a gentle touch and steering the community in the right way. But that's one obligation we have to fulfill. And I think that's mostly in the first place. That's what we have to do immediately. That's now in the text. And the rest then comes down to kind of the implementation details in the harmonized standards that the text refers to, and that are yet to be written. So I think that's where I can then give back to Kieran and say, we shall see. Same question to Enzo for how you think in Eclipse Foundation compliance would look. Yeah. Honestly, I'm with Dirk and what Mirko just said as well, I think, and what you just said as well before. We think that we already have it in a sense that those are processes that we've had before. We have, as Mirko says, a cybersecurity policy as well. We have procedures for vulnerabilities handling and reporting as well and how to tell the community when we have a vulnerability, et cetera. But your question was what compliance will look like. And the text is, as you say, there are quite of a blank check sometimes. I wouldn't have said blank check, but it's vague sometimes. And so I think compliance would look like what the regulators and the authorities are telling us that it should look like. And that's a bit the problem that we have right now because there is some vagueness within the text. And then we have to see, check with them, be sure, 100% sure that what we have is okay with them. The problem is for certain foundations taking the time to do that. And as Mirko just said, for instance, we're going to have to hire someone to do that. We're going to have to figure out a way to do it. But I don't think that the overall open source community and open source foundation is just the four of us here in the panel. The question is, how is everybody is going to do it? And how are we going to get all that compliance? So I could go in details within, you know, Eclipse Foundation has this in its policy and maybe we should do that, et cetera, et cetera. But right now, I can't even tell you exactly, okay, the regulators are going to say, this is 100% right. And this sort of legal uncertainty, that's what create the struggle for our compliance. And therefore the answer, I'm sorry, it's a bit vague. This is going to be what the regulators are telling us, and we better speak to them. Similar question to Jake, and we were talking earlier, and you mentioned the GDPR. When GDPR came into force, there was a panic. And how do we avoid that? And so, you know, as we'll discuss a little bit later, the standards aren't yet available. But it would be useful to prepare the community and to try and figure out already how to make compliance easier. Do you think that's, what do you think can be done in the three years that we have before the CRA comes into force? Yeah, I think that's the problem with like, because the developers, mainly their job will be reading documentation, but not like text like CRA, which is like a very different from what they're used to. So what we can do is like really do more outreach and work and like kind of figure out maybe something more like a kind of instruction or checklist that what developers or maintainers are more used to. And then we can kind of like help them to get up to standard, like not like GDPR, which is like, you know, nobody talked about it until like one or two months before. It's like, it's the hot deadline. And suddenly all the website have those like, you know, little windows saying like, oh, do you have cookies and stuff. So we want to avoid that. We want to have like, give people room to plan ahead. And because like security is not that easy as like just put something on your website is you have to really make sure that everything is working properly, follow good practice and all this. So, yeah, so that's something I think that's why we need to do now, like start our reaching to the like, especially like for us, we will try to work with project at a high volume, but maintained by volunteers. Yeah, we have to really because they are volunteers, we can't just like tell them, OK, can you get it done by, you know, the end of next month? You can't. So you have to start early. So, yeah, you're cool. Maybe if we change the question a little bit, not just what will compliance look like, because we don't fully know that yet. But maybe what can we already say that the communities and individual developers and also businesses investing into open source will need to do in the future. Then I think we can give a few more concrete answers. One is the topic of the panelist is this role of open source software steward. I think an initial like request to every group involved is figure out if you are a manufacturer or a steward on individual developers. These are the three roles in the CRA and they come with very different obligations. An individual developer contributing to a project under somebody else's responsibility is not covered by the CRA. Very important. If you are a volunteer developer and you're not responsible for the project, you're contributing to something, you're good. And but the next, the next level, you need to know, am I steward or a manufacturer? Manufacturers characterized by commercial activities, monetization. A foundation, for example, as a non-profit entity does not monetize and therefore falls into the class of steward. As a steward, you will have the light touch regulatory regime that we heard about. But you will have to implement, for example, that policy requirement and the points of contact and things like that. As a manufacturer, you have to do a lot more. You have to put the like go through certification. You have to put the CE mark on your product. After you've certified, you have to, you don't have to publish SBOMs, but you have to make them available at the request of market authorities, which means you have to have them. So the one of first question is, which of the role are you? And make sure you know and then act at least according to what we know today. And this leads to a couple of really interesting questions, because our projects go very dynamically. Like an individual developer has a great idea, starts to work on something on the weekend, it has legs, it starts to grow, and three people start pitching and they start making regular releases. At what point does this group now become a steward? Also, they start selling maybe support contracts. They will become a business. And these transitions from a hobbyist, I contribute to somebody else's project, to I become maybe a small community, maybe I put that community under the umbrella of a foundation, or I will start a business. These transitions in the future, we will need to make it very explicitly. And clearly announced them in a way, so that it's clear which will you play at a certain time. I was going to jump to Dirk, but if you've got a quick comment. Yeah, so I think sort of refined also some things Merck was saying there. So we largely in the existing open source organization, we have most of those processes already there and often fairly documented and so on. However, we are a community of developers, even though everyone is a volunteer, everyone works for companies who are absolutely certainly under the CRA manufacturers and will have to place a CE mark on what they're doing. And we're doing this work together at the Apache Software Foundation or the other foundations. And typically because doing it together is more efficient, is easier and gives us better codes quicker. So that actually means that that community which certainly needs the CE mark, for example, I mean, it's much easier to do that work together because you can do it better and quicker and so on. So I'm expecting that as we implement this, we're actually going to find that some of the open steward sites are going to be relatively easy. But the challenge for us as an industry as a whole to certainly sort of like go to being a regulated industry, that's going to be much, much harder because we'll have to develop the sort of just like we have release notes today and we have responsible disclosure guides and CVEs. We will now also have to sort of like collectively maintain the artifacts for conformity assessments for the CE mark. So basically the basic lists and things like that and the S-bombs and so on. So I think I'm sort of expecting a massive amount of work. And if you have take a very quick look at for example the MDD, MDR regulation, which is the basically equivalent to CRA but for medical software, you see that basically means about like 30% more engineering works to just get that done. So effectively that's what we're looking at as an industry and a large part of course we'll do together at open source organizations. So I'm expecting that that will be one of the largest places of like footprints of where this happens. I want to just at one point that like I think for identifying like whether you're a steward or you're a manufacturer, I feel like there may be a lot of companies that end up founding that they of course they are a manufacturer but they also have a part of the steward part that maybe is the part of you know within the architecture like you know organization structure whatever. So yeah that's a very good point of like how to kind of figure it out and also maybe like if there's some good practice in the manufacturer part can it be extend the steward part that like benefit the community a little bit more as well that would be something I think we may discover. Indeed. Just yeah I just want to add one point because I think it's really important and something we didn't mention which sort of link to several conversations that happened today and I think it somehow gives a picture that is interesting. Manufacturers under the CRA also have a due diligence obligation. It means that foundation will have to do whatever they have to do as we just discussed but also when you are a manufacturer of a closed source whatever you want to leverage an open source component you have to do your due diligence to be sure that these open source components comply with the CRA. If the manufacturer single vendor let's say open source did not comply correctly with the CRA you'd have to make sure that it comply with the CRA instead of the original manufacturer of the open source component. If the open source steward did not adopt the right policy for instance etc etc we'd have to make sure that now this open source component that you leverage within your product with digital elements now comply with it. So the importance of you know this morning competitive advantage all these sort of elements which is to say okay Europe can now leverage open source and there's going to be a competitive advantage for Europe etc etc all those arguments that I'm not going to repeat today. If all of a sudden we don't do our job properly then the whole European industry and the organization that are leveraging open source software and the whole reason why open source matters that we have discussed and try to prove the whole morning and the panel before and probably the panel after I'm sure this sort of flies away. So the importance of doing this is really lying in these specific elements. If we don't do this correctly and that's true for stewards and that's true for manufacturers and you said it very well Dirk at the very beginning and that's why I think it was a great summary. If we don't do this correctly then we sort of all failing together. So it's really a question about how can we ensure that our compliance throughout Europe and throughout our organization kind of look the same enough so that every manufacturer can keep on trusting and every compliance department of a company can keep on trusting the fact that now they can leverage open source component and do the due diligence without being scared all the time. And that really matters for a whole software supply chain but all digital product with digital elements supply chain across Europe. Yeah, I just think this was important in terms of perspective. Michael, quick comment. Yeah, on that note, I think there are a couple of like soft requirements that will come towards those foundations that are employed in this area. So for example, there is a mandatory support period which is normally five years now under this area. That means a manufacturer will have to in the future provide security updates for products for a period of five years or even longer if the product can reasonably expect it to work longer than that. Now naturally, if all those manufacturers are incorporating components from our communities, then we will have to have a way to work with them for that support period to update the software. And if you were there yesterday, we heard from the car industry that this period can also be 20 years. So we have to find ways to work with our communities or the consumers are our community to find ways that they are able to fulfill those maintenance requirements. And that will raise the bar, I would say, to in terms of governance of our software projects, of our long term perspective, but also I think for the quality and maintainability of the software itself because maintaining software for such a long time is very difficult. There's also a documentation requirement for the manufacturers saying you need to provide the consumer with a template of information. What is in here? What kind of potential security attack services does this provide? And where can you inform yourself about vulnerabilities? And naturally, if you look from a practical perspective, our manufacturers will consume thousands of components from our communities. And that means we will need to be you need to give them this information so that they're able to, from a practical point of view, aggregate it and give that to the consumers. So this is of course something that will evolve, develop in collaboration, in cooperation with the people that are consuming the software hosted by the communities. And it means it's a practical requirement, really, for the manufacturers to engage with the open source foundations because as a manufacturer you will only be able to fulfill those requirements if you are engaged and you make sure that we maintain the software for as long as you need it or you can replace it. I kept the last 10 minutes for standards. I'll just quickly introduce the topic. A lot of us think of standards in terms of data format standards but this is not what we're talking about here. There's another type of standard which is a procedure and so in the CRA there are 44 obligations that apply to the different categories and for each of those obligations a standard will be developed to suggest how you could comply. And then the CRA, article 11 says that if you follow the standard you get a legal presumption of compliance with the CRA. So the raw way to comply with the CRA is read it yourself and make a procedure. This standard should be an easier way. It should be more detailed, more practical. The standards will be developed by bodies in which free and open source software is not well represented and the procedure doesn't really suit us. If those standards are not implementable in free and open source software then the result will be that we have to comply the difficult way and other entities will get the easy route. So we're going to have to get involved in these 44 standards that are going to be written. Which is not what we expect to do in 2024, 2025 and 2026. That's the timetable. Mirko, would you like to talk about how you think we can get involved and what's possible? Well, if you ask me I totally plan to be involved in standards development in 24, 25 and 26 because just recently the European Union renewed the multi-stakeholder panel on ICT standardisation and we are represented there now. The first time that an open source foundation is in this group which is maybe if you're here in this room and you've never heard about this a very obscure group but it's really influential at the European Commission and at the Parliament because it advises on how ICT standardisation should be done. And so, yes, I totally intend to be deeply involved there and we'll use that because there's one very innocent sounding paragraph in the COA that says when these standards are developed the standards of urban organisation is supposed to include relevant stakeholders. So I think the first thing I'm going to do is send a very nice letter saying I think I'm a relevant stakeholder. So are you and so are you and we should totally be at the table. And so, yeah, the problem with all of this is how do we get there? How do we get inside? And that's what Mirko was saying when he was saying I'm going to write letters saying I'm a relevant stakeholders. If you need any want to sign a letter for you and if you can sign my letter and we can all each other sign each other's letters I think is going to be useful so that we can finally get there. The problem is a conversation that we've had yesterday is those bodies that build standards they're not made for us. They're not made for our communities. We haven't really been there so far. That's the struggle and also we are so spread. We are so distributed and it's a good thing. It's our strengths, right? But when you have to bring the whole open source community into something that was not shaped around the open source community then how do we open the door? How do we actually make sure that we represent it? At the moment, I don't have an answer to be fair because it costs money but you hire people into those standards making body, you have the largest companies in the world and there are moments where in two standards we're not going to agree. If you have and there is an obligation within the CRA to say that you have to design products with digital elements including open source software in a certain way. Well, the way we design open source software if we do sometimes and the way you design closed source software can be different. There are processes that we do that they don't do in closed software. There are processes that they do in closed software that we don't do sometimes. So what if that standard is made and it doesn't fit what we do? Then we can't use the standards anymore? Then we end up into the original question that we actually all raised before which is what do we do if we don't have a standard? What do we do if we don't know how to all comply the same way? Then we go back to the very first question and we don't have an answer. So now we have to figure out a way as a community who do we want to be in those standards into the standards making places? How do we get the money so that we can pay professionals to go into those standards body and fight for the interest of the open source community because that's what standards negotiation that's what standards technical conversations are about you negotiate all the companies and all the organization fight for their piece of bread. So how do we make sure that we're there? We've had a conversation yesterday with different institutions and it's possible to get funding but it's also not sure that we will get funding and I've heard yesterday a testimony from someone from the open source community that says, well, I applied five times I never got it. So why would this time be different than the others? Okay, now we have a regulation with our names on it open source is inside, open source stewards are inside but if we don't get this if we don't enter into this door then we end up into this legal uncertainty that is not in the advantage of anyone on the European market. So that's really the struggle that we have at the moment. I don't want to be too long because I think everyone has something to say about this because that's really the key element of that thing is that we make sure we actually build a standards that look like us. I've got five minutes left maybe if we can do closing comments while replying to what Enzo said, Dirk would you like 90 seconds? Yeah, right. So open source, it's while successful and it's essentially one of the key tricks is that it's based on self interest. Everyone is there because they get more out of it than it costs them. It's basically self interest. Now, while there is a lot of professional pride around security, reliability and stability that isn't necessarily true for engaging in standards organizations all sorts of other things with our current crop of people. However, I mean open source is now a core part of society and as we say basically everyone should sort of like come to us to scratch your own itch and fairly enough we don't really have many people who want to scratch the itch of good conformance good standardization be involved with those organizations. So a very traditional solution to this problem in the open source world is to basically find, basically broaden our community to also include those who really feel that security is important that conformance is important. To also basically find, basically have participants from the public sector, from academia and other places to actually become part of our community and actually work within those standards community they're used to work to sort of like help set those standards because the current crop of people, I mean in many ways a lot of individuals say like well we don't owe you anything. So we'll really sort of like have to find ways of broadening our community to find people having those itches. I'm going to go to Mirko and then Che, Mirko. Okay. I think in regard to this decentralized nature of open source, one thing we have to like realize when we read the text of the series that it will unfortunately require a little bit of centralization from us because a small organization, non-profit developers for fun with five people will not be able to send a representative to a standard development organization to participate in a working group because that's what really is required here. So only organizations will be the ones that you see here on the stage will be in a position to do that. So this will lead to a certain trend of centralization in the open source community which is an impact on governance of the community by regulation and we need to manage this. Maybe I want to close by saying on the other hand, I do believe that the series really also a chance. There are clauses in there that are clearly improvements for consumers like the mandatory support periods. You will never again buy a phone that will not be updated a year later. There are significant reasonable and hopefully effective measures in there that will raise the level of cybersecurity and that's why I absolutely support what we heard earlier that we will step up and work in this field and work together with the regulators to implement this. But it will be effort and the community needs to come together to review and update our governance and it's not going to be completely easy. Yeah, so I think in open source, well, we kind of come a long way at the beginning. You know, nobody know about what is open source until now people are now starting to care about open source and I think now we have a new term, like open source steward, we have to figure it out and also like CRA again, I agree that it's a good chance that as developers, we always develop all this new standard that people follow and then it just got adopted kind of as a standard and now we have CRA and hopefully there will be good practice that all these developers and maintainer adopt and then we will develop some standard that kind of meets these criteria that would benefit everybody who are using the software. So yeah. We have 30 seconds, Enzo, do you want to say anything or did you? Yeah, let's do it. Let's try to make it happen. I mean, we just discussed on the fact that we need to figure out something. I don't know if the solution is to centralize it. Maybe the open source community is going to come up with something that has never been done before and then we're going to figure it out a way to decentralize the way that now the centralized standards, the processes, we're going to completely change them. Maybe we do something insane. I don't know, but at least we know that we have to do something so let's do it.