 Hello everyone. So the study that I will be presenting to you today is basically circles around the question that you see on the screen, what makes an open source project critical to a democratic group. This is part of a broader study on critical digital infrastructure that we conducted at the digital civil society lab at Stanford University with my collaborators at UC here, Jessica Feldman and Lucy Bernholz. In this presentation, I will give you an overview of this study and the methodology and focus on the two parts that you see on your screens, what is critical digital infrastructure. And the key here is what is critical infrastructure and according to whom. We basically noticed that this really matters. And then this part mostly looks at, this part is mostly based on a regulatory and case law analysis, and then we're going into the ethnographic study. This is what Jessica Feldman mostly conducted, where we reached developers, open software developers and teams to see what they think is critical. And spoiler alert, there was a mismatch between what the regulation thinks is critical and what laws around different jurisdictions that we looked at define as critical or imply as critical and what groups that are democratically governed and or are democratic groups considered as critical. So, the idea behind this methodology and the mixing of methods, making a scholarly analysis of regular case law legal analysis, regulatory case law analysis, looking into the market. And finally, realizing that there's a third space that of civil society that is under searched is what really drove the methodology. I'll be covering the first two. These are what I'm mostly sort of an expert on and and will be presenting also the findings on the ethnographic and civil society, and I apologize in advance for my lack of expertise in in this part. So the elephant in the room what is infrastructure that was the first difficult question that we had to encounter, because we could see that a lot of policy documents scholarship legislation was basically implying that infrastructure is one invisible. However, we know it when we see it. This is a famous phrase from a from a Supreme Court justice in the case of the 60s and that infrastructure is critical. And we know that when it breaks down. So this was kind of the concurrent thing in in trying to define infrastructure and try to define also criticality. Looking deeper into our sources, we have, we propose a little bit more slightly richer picture of what is infrastructure. Besides the fact that it sometimes is invisible and becomes visible upon breakdown infrastructure or infrastructures are have value their value is usually defined by the resources that they. Help communicate. infrastructure has public goods and sometimes also natural monopoly attributes this was mostly. There's a consensus in economics scholarship there. And then, I think that it is important also when we think about the repercussions that this will have an open source to understand that infrastructure is usually built on any style base. So there's an element of dependency. Link to that but not identical is the fact that infrastructure is relational. So it might enable infrastructures might enable some people, but not necessarily all of them the classic example of staircase where the staircase is an infrastructure that is useful for me, because I can walk. In the future, it would not be as useful. And then very ample scholarship and ample evidence on on infrastructures, political nature. Infrastructure is not a political. We're developing into legislation and regulation, mostly looking at the European Union and the US. The report that we produce for the fourth foundation is quite US centric. We use different jurisdictions to compare. We started identifying very benchmarks of criticality, first from the perspective of the legislation, the regulation therefore from the perspective of the nation state. In the future, we see a dominant presence of the of security and lately cybersecurity as as perhaps the number one benchmark for criticality, public health and safety come immediately after that also reliability and resilience which are mostly requirements for rather than off criticality. The interesting part is that we could see analyzing the development of a slow particulars in the cybersecurity sector in the Western world. This this emphasis on security and then on cybersecurity is evident is evident in the rules is also evident in the language that all these rules use. I will give some examples here, the critical infrastructure protection act of 2001, which gives the definition of critical infrastructure that is always cited in later regulations as well in the US so it's still the the authoritative legislative definition infrastructure critical infrastructure is systems assets physical or virtual that are so vital for the country that their construction capacity in capacity will have a significant impact to national security national economic security and national public health and safety. The comparison with the equivalent definitions that we see in the European Union usually add a social element where the destruction is not only on the secure national security and economic security but also on social affairs. Interestingly, in the 2000 and two Homeland Security Act, you can see another definition this time of critical infrastructure information, which I think is also important for our discussion here since we're we a lot of you already touched upon the difference between our discussion intellectual property rules. So interestingly there, the term critical infrastructure information means is defined by this act as information not customarily in public domain so the the assumption is that this is not appropriate their information related again to security of critical infrastructure or protected systems. These are just snippets of of rules that we looked at we looked at a number of in in the US we looked at various rules on public utilities and both intangible intangible mostly intangible I would say so that we understand whether the kind of rules that we've seen for critical digital for critical infrastructures and for critical infrastructure information of the federal level match the state level and it does. I'm very happy to talk more about the kind of state level regulation which revealed very sort of interesting spaces and regulatory spaces, but they're not linked to software as much. So I decided to not bother you with all these details. Now, since we're talking here with a crowd that that is mostly also focused in on the European Union. I wanted to add this jump notice this transition that we are expecting from this one to needs to and see what is the European Union legislator adding to this discussion are the benchmarks of the legislator similar is the focus on security again dominant. Just to add more more terms into our terminology tools. The nice one talks about our graders of essential services and that's what I'm using as the equivalent of critical infrastructure and defines these are entities that provide services that are essential for the maintenance of critical social and economic activities. Of course the interplay with words everywhere doesn't help. Doesn't help us much but more or less when the Union talks about essential services, it means what the equivalent US rules define as critical infrastructures. And the interesting thing I think for the way in which the European Union is going and is thinking about criticality of these infrastructures. One is that more and more it the critical infrastructure and critical digital infrastructure becomes the same they come together which also happened. If you look at the progression of the US rules every legislation the same space, but also needs to introduces yet another distinction, creating sort of ranking of criticality which I find very interesting. And it might be worth our attention especially now that needs to is not yet law. So this new distinction is between essential and important entities so essential is the highest in the highest spot in the pyramid and the examples of critical or essential services this critical sectors are on your screens. Again, very similar to the sectors that are defined and regulated as critical in the United States and in Canada, and I'm starting to look at now. So, I've also highlighted point seven, which is how needs to defines and this one defines digital infrastructure. And just to connect a little bit also with the immediately previous presentations, the infrastructures of public administration which are also increasingly become digital are included in the list of needs to now as an important as essential entities so the highest of ranking of criticality. And for the for the purpose of our study we continued looking at more legislation and regulation also try to link cybersecurity with a different sectors that also touch upon infrastructure, not only directly but but also indirectly so we started looking at rules on public access and accessibility to critical infrastructures, and then rules of the market, which brought about more benchmarks of criticality, in addition to the three first that you saw also earlier national security cybersecurity public health and safety reliability resilience. So we add this element of access or accessibility competitiveness and interoperability interoperability especially with regard to public infrastructures. And here is when we shift towards the the novel part of our study where we wonder where is participation why isn't participation critical in the ways in which either the market or the nation state think about critical infrastructure. And we, we're still, I would love to hear your feedback on that. We think that we need to sort of identify each each sector with at least one benchmark of criticality that looks to that is the most dominant. And I think that for nation state security is is clearly the dominant benchmark for the market we were thinking about sort of the whether it's it's necessary to point one benchmark of criticality seemed that that this notion of profit making or exclusivity and taking from intellectual property rights could be the most identifying the mostly identifiable benchmark but I more and more especially reading recent case law on antitrust and intellectual property and the sort of software battles that are prominent in both sides of the Atlantic. I think that competitiveness seems to be the most appropriate term if we want to highlight or discern one critical one benchmark of criticality for the market, although it doesn't necessarily need to be one. And there we come in with our ethnography, wanting to ask democratic groups and mostly open source developers that either that first of all want to govern their own community democratically and also want to build tools for democracy. What do they think about criticality and are they in alignment with the way in which our rules and regulations and our nation states defined criticality in infrastructure and in digital infrastructure. Are they in alignment with the way in which markets define criticality that's pretty, that's perhaps the easy part, as we always thought of the open source community in thinking of it in antithesis with the market. And there are findings confirmed the hypothesis that was basically that participation is critical for communities of builders of open source and our initial effort within the or hope that we will find more benchmarks when asking in our ethnographic study when asking our interviewees, what do they define as critical in their work was, I think was misguided. What we found is that it was difficult for our interviewees to pinpoint elements of criticality. And this is a quote here from one of our interviewees saying that pretty much everything is critical in the sense that projects fall apart, not necessarily because of lack of expertise or or knowledge. But they might fall apart technically and politically mostly because of lack of participation. And that was very critical to that. Now I'm entering the results of the ethnographic study and I will be presenting the part that my colleague is most responsible for so I'm trying to do my best here to not misrepresent it. So apologies for any mistakes. The basic three clusters or chunks of challenges to participation that we discern from the ethnographic studies are social cultural economic and technical and organization. The social cultural aspect of the challenges. Here are some representative quotes from our interviewees pointing to this categorization that we decided the social cultural technical and economic one. So the complexity of introducing new people into the community was emphasized by one of the, by a lot of our interviewees actually. This is probably the most interesting one for me. These, there's a big discussion that I think Sivan also mentioned a little bit earlier about the difficulty of sustaining an open source project, especially because behind the scenes. The project might really rely upon very few people or one person that and this famous sort of anecdote that this person is hit by a bus, then then the project is is up in the air. Well, the, one of our interviewees said that, well, that really has not happened, and the real problem is bosses, not buses. Usually, the person that would be devoting their time into an open source project might just become extremely busy because the priorities of their, their work and the priorities that was where, and then the kind of new direction that that their bosses gave made them lose time completely and need to abandon the project. So, I think this, this might be tying very well to discussions that we had and that we will have on on ways in which we need to not only fun but make space and time available for open source builders. And finally the technical and organizational complexities and challenges. The computer scientists that you see quoted here said that open source is a new way of developing. There's a new sense. There are new scientific issues there to develop quality software, because it's different from the traditional way of doing this. This notion of participation comes into the very definition only of critical but open source, which I think is, is important to remember. I was recently listening to another discussion on on the future of open source, and I will, I will still this this quote. I'm, I'm terrible because I cannot remember who to properly attribute this to but the, the just was basically that even the term open source is not an open source definition right. And with that, I would like to conclude and thank you very much. I haven't prepared a questionnaire. I think that what I would have asked is, is your take on our more normative part. Once we identified this mismatch between the prioritization that the market and the nation states give when it comes to criticality and also a mismatch between our understanding and approach of criticality of public infrastructures, which rely on private digital systems quite a bit. What is what is the bottom line? What do we want to do going forward? First of all, to what extent do we need to address this mismatch across the board and how and I think that the term prioritization is for me important here. And another another issue that I think that we are mostly concerned about with that with our port at the end is whether the tackling and giving answers with regard to software as infrastructure in and in order to address this mismatch is enough. We are moving further away from this division of software and hardware. A good example that really accelerated this discussion in the US was the attack the cyber attack in the pipeline colonial in the colonial pipeline in May 2021. And so policy from policy perspective, it might be it might be advisable or it might be the timing might be good to stop talking only about software, but open up the discussion on the bundle of the cyber and the physical part of our infrastructures. And with that, I thank you very much. I think I stopped sharing. Great. Thank you, Aguirre. It's very interesting and I already have a few questions myself. So let's see if I get those in when we have a discussion in a little bit. But well, next up. I invite to come on to the stage here now to talk about the export project slash the export product that they are maintaining. I can see better coming on. Hello. Hopefully you can hear me now. Yes, we can hear you. A lot of people having a bit of fun with the whiteboard that I don't quite know how to turn off anyway. So go ahead, have some fun. Yeah, if you would like to, you can share your presentation. Yeah, I'm about to do it. Now it should be shared. Can you see it? Yes, it's coming on. Yes, great. Okay. Thank you. And hello, everyone. My name is Petteri Kivimaki. I'm the CTO of Nordic Institute for Interoperability Solutions. Needs for short. My topic today is joint open source development in cross-border context. And my approach to the topic is very, very practical. So I'm going to approach the topic through X-Route data exchange layer. First, a couple of words about X-Route so that you know what it is and what it does. But then my main focus is on the development model of X-Route and needs as the core development organization. So first, let's start from X-Route, what it is and what it does. So X-Route is an open source software and ecosystem solution that provides unified and secure way to exchange data between organizations. X-Route is also a digital public good verified by the Digital Public Goods Alliance and it's released under the MIT open source license. From technical perspective, X-Route is based on distributed architecture and it's also based on so called four corner model. And the main idea of the model is that organizations, when they exchange data, their information systems, they are not connected directly, but instead they are connected through unified access points. And in the X-Route architecture, those access points, they are called security servers. And X-Route, it creates kind of a secure peer to peer network when organizations exchange data directly with each other. So there's no centralized message brokers or any central components that would process the data that is exchanged. However, some central components are present in the X-Route architecture and they are needed for creating the trust between the members. So we have the central components of X-Route and then external trust services. But they don't play active role in the actual data exchange. And the most typical way how X-Route is implemented is at the national level. Like you have maybe heard about the X-Route implementation in Estonia. So X-Route is used there as a national data exchange layer. It's operated by the public administration, but all kinds of organizations can join and exchange data with each other. So the actual data exchange, it's not only for the public sector, but also for the private sector. And also Finland and Iceland have similar implementations. And in addition to technology, X-Route also provides an organizational framework. So it defines a set of different roles and their responsibilities. X-Route operator is the organization who runs the X-Route ecosystem, defines the rules, sets the policies, decides who can join. And then we have different kind of organizations as service consumers and service providers that exchange data with each other. And to become members of this ecosystem, they must go through an onboarding process during which their identity is verified by the X-Route operator and also by external trust service providers. And like I mentioned today in Europe, X-Route is used in Estonia, in Finland and in Iceland. But in addition to that, X-Route is used all around the world. There are several implementations in South America and Asia. I think also something in Africa. So today X-Route really is a global solution. But originally it was developed in Estonia and the first version was released 20 years ago in 2001. However back then X-Route wasn't an open source solution. And it really became an open source solution years ago in 2013. Everything started in 2013 when Estonia had the source code of X-Route to Finland. And Finland started its own X-Route implementation project in 2014. Originally the idea was that Finland wanted to just take the software, implement it and build their own ecosystem. Finland didn't have any intention to develop it further or do any changes to the source code. Just an off-the-shelf deployment without any changes. However during the implementation project Finland realized that some changes were needed. And therefore they started to develop X-Route on their own. And Estonia was developing the software at the same time. And in this kind of a situation if different parties were developing the software, they don't coordinate development activities in any way. There is a pretty big risk that a fork is created and then the two different development branches, they are not compatible with each other anymore. And this was a situation that both Finland and Estonia wanted to avoid from the beginning. So they both wanted that they are using the same software. And in cases changes are needed, they develop it together. And in the beginning both countries had their own development resources, development teams, development environments, own backlogs and so on. And the development activities were coordinated by a so-called working group that was meeting once in a month basis or so. But this kind of model it had a pretty much overhead. And the idea that the shared organization that would be responsible for the development would be a lot more efficient way of doing things. And eventually this led to the establishment of MIS in 2017. And a summary of the ex-road development responsibilities before MIS was established and well, then once MIS was established and the development responsibilities were handed over to MIS. So MIS was established in 2017, then we needed some time to ramp up the organization and the development activities were handed over to us in 2018. But as you can see here before MIS, well, everything had to be done twice in Finland and in Estonia. And once MIS was formed, we took the responsibilities and after that there are no overlapping responsibilities anymore. And overall you can say that MIS is the software vendor of ex-road. Ex-road is open source, so we are not actually selling anything, but you get the point. Also an open source software needs to have an organization who is responsible for the development, managing the backlog, the documentation and so on, running all the development activities. And that's exactly what MIS is doing. And our development model works so that our own core organization is very small. We are only five people working at MIS and then we are using development partners to actually do the development. So we organize procurements and then we use commercial companies providing development services. And our working model works so that when we organize procurements we don't do requirements and we don't define a set of features that we want to be developed. But instead we define a set of skills that we are looking for, kind of developer profiles. And then we look for a specific number of developers with those skills. And then we work on day-to-day basis with the development teams using agile development methods. In that way our development model is very flexible in a sense that we don't need to know six months in advance. For example now we don't need to know exactly what we want to develop next April or so. Since we have the developers available all the time we can just update the backlog and change the priorities according to the needs and requests of our members. But then in addition to the actual development activities we also provide second-lined support for our members. So for example Finland and Estonia they have their own X-Route ecosystems. Both ecosystems have hundreds of members. Sometimes those members they need support. So when that happens Estonia and Finland they both have their own organizations that are responsible for operating ecosystems providing support. And then in case their own support organization is not able to help the members they contact us. So the end users of X-Route in Estonia and Finland it's rare that they contact us. But they first contact their local support organization in case they are not able to help they contact us. But at the same time of course X-Route has a wide open source community and through the community we receive support requests as well. So it's not so black and white. And then in general we also do lots of different kind of international cooperation. And when it comes to needs as an organization we are a non-profit association registered in Estonia. Currently we have three members Estonia Finland and Iceland and our funding comes directly from our members. The decision-making model of NEES works so that the highest decision-making body is the general meeting. They approve and monitor our strategy, budget and action plan. And the general meeting it has representatives from all NEES members. Then we have an advisory group that doesn't have real decision-making power. But the role of the advisory group is to support us in operational questions. Then we have our management board where we have the CEO of NEES who is in charge of the day-to-day management of NEES. And finally we have the X-Route working group that is responsible for the technical decisions, technical discussions. And I actually mentioned the working group already earlier. So when Finland and Estonia started the joint development in 2015 the working group was established back then. And it has existed since then through all these years. And its role it has remained more or more or less the same. And if we think about the roles of X-Route working group and X-Route advisory group on a very practical level. If we need to decide whether we are going to implement some new feature that requires significant amount of time and money. Then we first discuss it at the working group. If the working group thinks that it is a good idea then we take it to the advisory group and the advisory group needs to approve it too. But then when we start to implement that new feature and we need to make decision regarding technical details how something is implemented. Then those discussions will take place at the working group level. So the working group is a very, very hands on level technical group. And then actually we are also we are about to establish a new working working group. Well not new working group but a new collaboration group that's targeted to the X-Route community. Because all these groups that you see here general meeting advisory group X-Route working group. They are only for these members and these partners. We don't have representatives from the community in these groups. And therefore we are about to establish a new X-Route community third group that will consist of the open source community members. And the idea is that we want to involve the community more in the development process. And also here their feedback, here their thoughts and give them more opportunities to affect the X-Route development. And here the X-Route development model in one slide. But the main idea here is that since X-Route is almost one can contribute. And contributing means submit enhancement requests, submitting source code contributions, providing feedback. Well almost any kind of interaction. And it doesn't matter who submits the contribution. It's always evaluated using the same criteria. So it really doesn't matter if it's someone from the community or one of the new members. All the contributions they are evaluated. And then if they are approved, if they are a feature or enhancement requests. When they are approved they are added to backlog and prioritized. And like I mentioned before we use agile development methods in our development. Which means that we do development in sprints and every sprint we implement tickets from the top of the backlog. And we do two or three new X-Route releases per year. And the releases they are always available to everyone at the same time. So when a new X-Route person is released both these members and the X-Route community will get access to it exactly at the same time. And also our backlog source code repositories they are open to everyone. So everyone can follow what we are doing in real time. And at this point you might be wondering that so if everything is open everything is available for free of charge. Why someone would like to become a member of NEES? Because there is the annual membership fee to pay. And that's a good question. And the reason for that is that the community yes they get everything for free at the same time with the members. But when it comes to the decision making when we discuss the X-Route roadmap we prioritize the backlog. What items should be implemented now? Which ones can wait and they will be implemented next year? Something will never be implemented and so on. In that case NEES members make the decisions. So since they are responsible for funding the development activities then of course they are also responsible for deciding what is being implemented and when. So just using X-Route anyone can do it is available to everyone. But in case you feel that it's important to be able to participate in the decision making then the NEES membership is the way to do it. And of course there are also other benefits. We also facilitate cross-border collaboration between our members. And also when it comes to the X-Route development sometimes we do these collaboration projects with our members. So sometimes one of our members they need a feature that is not so interesting to the others. But that one member they have extra funds to pay for the development. Then they pay the development but the development project it is run in collaboration with us. In practice it means that they provide the developers who do the work. But the developers are allowed to use our development tools, our development environments, our development processes. And we at NEES we facilitate and supervise the development work. But the member who wants to have the feature they pay for it and of course they own the deliverables. But we help them in the implementation. And we have done a couple of projects like this with our members and so far they have been pretty successful. So it's a very good way of collaborating. And then very quickly about the X-Route community. This picture was taken in 2015 in the Estonian meeting. When we took over the X-Route development we took over the facilitation of the community. And we have tried to increase the number of the community members. And since 2017 it has increased from 50 members to over 1,000 members. And it cannot be seen when looking at the community event in 2019, our latest based community before COVID. So the community has been installed but unfortunately the number of active contributors isn't still too high. Maybe we have had 10 contributors from the community during the last year. So pretty long number. That's definitely something that we need to develop in the future. There is a huge potential in the community but we need to have good ways to act more. Finally, here's the world map of X-Route. You can see the three members and the purple X-Route logos are implemented. Implemented X-Route and the rest are countries where X-Route is in a consultation phase or X-Route is being considered but not implemented yet. That's it. Thank you for listening. Great. Thanks, Petri. I'm coming online. I'm a little bit conscious of time but let's see if we can get maybe one or two questions in. Also, Agiri, if you want to come back on, you're very welcome to. Maybe I can check if Jessica has also made it. So it'll just be the three of us. One thing that I was wondering is, Agiri, a photo is quite interesting that in this one directive always used the operator terminology. Of course, it's in an open source context quite relevant because software is often not provided by the operator but it's provided as is. And essentially somebody maintains it in the best, in a good scenario, somebody maintains it. Even that is always of course the situation in reality. So I'm wondering, has this evolved in this two directive? Because that might be a way of looking at things that might not be 100% up to date. And then I'm wondering a little bit, how do you see this? How could you see this evolve? Should responsibility always be on the operator? I'm sure that's a discussion on that area. Thank you. That's a fair question. Also, a small sort of clarification when I was talking about the niche regulations than the previous ones. The steps is from defining critical infrastructure to critical infrastructure to critical digital infrastructure and software. So you're right to point that. I think that there is, I should look back into where we are right now with niche two to see if this is set in stone. I don't think that the definition and the use of the term of a central operator will change because this comes from niche one, but still there are differentiations that might. So I could look again into that. Whether that's helpful for the purposes of niche perhaps because it's talking about liability of cybersecurity in cybersecurity context for maintenance and for non crisis sort of management, not situations of hacking attacks. I think that we probably I agree with what I think you're pointing out that it's not about operators, right? Yeah, I think there's more to consider than just the operator, right? I agree. And I think this also is this limitation the mismatch that when we talk about critical infrastructure in from perspective of nation states only focusing on security will also lead us to focus on incidents of cyber security vulnerability. And then on specific players and lead completely out of sight. The actual work and I think that the coming with listening to be there coming immediately after the importance of self governance, especially if I understood it well towards within your presentation of your own. Group which is an NGO know oh it's not a it's not a an operator under the directive for good. For instance, this would be under our under civil society right are not captured well from the definitions of our regulations in the US and I don't want to over generalize because we did not really look at too many jurisdictions beyond that. Yeah, yeah, I just wanted to add that it's I think it's also important to understand in context of context of X road but probably this applies to many other solutions as well that yeah I used the word operator. But in the context of X road operator is the organization who is responsible for running and operating the X road instance. And then we have to separate the software vendor that in this case is us me is the NGO. And I think that both both roles are important and they should be recognized and not mixed. Yeah, from from from this one to nice. Yeah, and I think you know this also kind of points to what the kind of the hyper and interdependent system that forms because of course there's different dependencies that existing there and that also speaks I think to kind of our general model world and something that hasn't been kind of I think captured in the in the legislation. There's also the red directive which you know the radio equipment directive which is being updated right now. And there's a little bit the same the focus is very much on on on on on a model that you know has been working for a very long time but might not always be still the way things work as a manufacturer and then they put out a product. In the red directive that's kind of the thinking they put out the product and then they they have certain. The product needs to work on the day they put it out. And then it's kind of out of our hands a little bit they say or that's kind of the thinking. Well of course today the situation is very different you want to have updates you might want to have some applications possibly on continued updates etc. So it's quite it's quite interesting how this how kind of the regulatory framework reacts to this. One question actually to Petri from my side is of course very interesting and really kind of fantastic way of and also in some sense the provide pragmatic way. Nice that is to work together and across waterway you talked about in the concerns that Finland had and the concerns that it's only I had and why they come up with the solution. But I guess, as you said, there's currently nice develops X road. There's some community contribution to it but it's relatively limited. So if these goes away, let's just imagine then what happens if these go these goes away. Can somebody else take this over it's open source of course but. Yeah. Yeah, that's a very good question. So X road is open source and anyone anyone would take it over and there are many companies that that are already working with X road. So we know that there is there is the required knowledge in the market. But if we think about how X road is used it's it's a part of the critical digital infrastructure in in several countries in these member countries and other countries as well. So I would say that the first case scenario is that we would need to go back to the model that we had before 2018. Meaning that every X road user country would have their own development team on their own backlogs their own development teams and so on. And then in the worst case they would do the development working in silos or or they would have to have to coordinate it like like it was done in the past. But the main point is that since it's so critical component in many countries you can just quit the development and and leave it there because well all the software it needs updates regularly. And if that is ignored then then you have a big problem in your hands sooner or later usually rather sooner than later.