WEBVTT 00:00.000 --> 00:13.400 Welcome, welcome. So I'll try to drive the discussion. First, before we start, who of you 00:13.400 --> 00:19.000 are involved in maintaining open source software? Raise your hand. Oh, that's wonderful. 00:19.000 --> 00:24.440 We really have a majority in the room. So hopefully we'll find a way for you to avoid 00:24.440 --> 00:32.880 committing suicide by dealing this call. Let me introduce open list first and foremost, 00:32.880 --> 00:40.360 Piotr Carwash. Piotr is somebody you've been talking to talking about in every single 00:40.360 --> 00:47.400 presentation. You've given or you've received the box software supply chain security is the 00:47.400 --> 00:54.840 lead maintainer for look for a project with a battery that produce wonderful bugs. That's 00:54.840 --> 01:01.840 we love to love. Actually, he's not the one responsible for the bugs. Piotr? So I mean, I take 01:01.840 --> 01:08.040 this one service for the bugs. Well, for fixing them that is welcome there. Yes, so there's 01:08.040 --> 01:13.320 also a maintenance of look for a wonderful. This guys actually came to look for a in a assist 01:13.320 --> 01:19.320 and really to support and take over the project to fix the bugs. Then we have Michael. 01:19.320 --> 01:26.920 Michael, you want to introduce yourself. Is it? Yeah. Hello everybody. I work at a German government 01:26.920 --> 01:35.440 for the PSI. And there I'm one part of the market surveillance, which is in a few months 01:35.440 --> 01:40.960 responsible for so waiting a lot of the stuff and a lot of the products with digital 01:40.960 --> 01:49.040 elements. Just make sure you don't scare us. When you say surveillance, you mean surveilling 01:49.040 --> 01:56.720 the markets, not surveilling us, right? If you're nice enough. No. You're not watching what 01:56.720 --> 02:02.880 we're talking about. All right. Damn, colleagues in the room, they'll do that for me. Okay, 02:02.880 --> 02:11.760 good, good, good. And next up, we have Liz. Liz maintains. She's from the Pearl and Raku Foundation 02:11.760 --> 02:20.400 and maintains Raku, which is formerly known as Pearl Six. Yeah, I would say the other way around 02:20.400 --> 02:29.520 nowadays, so we prefer not to do that named things. But I guess I'm here because I'm a maintainer 02:29.600 --> 02:38.720 of a lot of open source modules and programming language as well. So how does this CRA effect 02:38.720 --> 02:47.760 us in that moment? Great. So we want to discuss how the CRA is going to impact up and 02:47.760 --> 02:56.480 so-so for maintainers. You want to start Liz, what you take? Well, I guess if you are a maintainer 02:56.480 --> 03:02.960 of a module and you don't want to be bothered by all of this, then don't be bothered. That's a 03:02.960 --> 03:10.720 really the simple solution for you. If that means that some entity will actually fork your 03:10.720 --> 03:19.200 module and do changes to it, they are actually obliged to provide you with those patches. So 03:19.200 --> 03:24.960 you might actually just profit from it that way. But if you want to actually be more involved 03:24.960 --> 03:30.960 in the whole process and actually want to get some support for it, then you might actually 03:30.960 --> 03:36.000 want to get involved with the CRA and everything around it, specifically with software stewards 03:36.000 --> 03:42.720 and getting adaptations to actually pay you for the work that you do. So, but you're saying that 03:42.720 --> 03:49.840 if you don't want to do anything, there's nothing to do? Exactly. Okay, talk his over. No, 03:49.920 --> 03:57.920 just kidding. Michael, what do you think? As mentioned, the main part is a manufacturer 03:57.920 --> 04:04.960 is responsible for his product and for everything he puts in there, including all the free and 04:04.960 --> 04:13.360 open source stuff. So, he needs to think about what he can do with those components and you don't 04:13.360 --> 04:18.640 have to do anything if you're just coding stuff and you like doing that and you don't want to 04:18.720 --> 04:24.400 manage anything. They have to take care of it either. They do it on their own. If they can. 04:25.360 --> 04:31.200 If they don't, then maybe they have to find someone who can and then pay them 04:32.240 --> 04:39.200 doing the stuff or maybe it's a good idea to talk to the people and gauge with the people doing the 04:39.200 --> 04:46.320 great stuff and try to support them in any way. They can. So, that their products, again, 04:46.320 --> 04:51.680 because they're responsible for their first applications. So, basically you're saying 04:52.480 --> 04:57.200 the authors are going away with get out of jail cards and it's all on the users. 04:58.400 --> 05:02.960 No, it's on the main, it's on the ones integrating stuff into the products. 05:02.960 --> 05:09.280 So, commercial users then. The commercial users of the software that are integrating 05:09.360 --> 05:14.480 or brings those package in the product. Good, good, good. What's your take, Piotch? 05:15.760 --> 05:25.920 Please, as has said a lot. So, yeah, if we want, we can adapt. If we don't want, we don't need to. 05:27.120 --> 05:36.080 Personally, I see it more as an opportunity to get our actors involved in funding. So, it's 05:36.080 --> 05:43.200 certainly cheaper for a manufacturer to delegate work upstream than to do it itself several times. 05:44.000 --> 05:50.480 So, I see this as an opportunity to get more manufacturing involved in helping workers' projects. 05:50.480 --> 05:54.400 And you don't even need to have luck for shell to get their attention. 05:55.120 --> 06:02.480 Well, you're kind of a top dog in the pyramid of vulnerable package because you're very well known 06:02.560 --> 06:12.880 to that helps. But at your scale, do you see actually a rush of software or of company that 06:12.880 --> 06:18.880 could digital products on the European market that are rushing to you to say, let us help you and 06:18.880 --> 06:24.720 so on? Do you see something happening or is just you hope it's going to be something? 06:24.720 --> 06:31.600 That's something that I hope. So, as you say, since we have a big vulnerability, we don't know if it's 06:31.680 --> 06:41.120 because of that or because of CRA that we had some funding like a big SDF project to improve 06:41.120 --> 06:48.960 the security posture, the documentation and everything for LaForgia. But that was, we don't know if 06:48.960 --> 06:56.960 that was CRA or LaForgia. Okay, you're also in a big foundation. So, what for other smaller products? 06:57.040 --> 07:02.800 Maybe a smaller project. Even though Blackpool is also part of the profondition, the Black 07:02.800 --> 07:07.520 Foundation, which is foundation, it's probably smaller in scale than what Apache does. 07:09.280 --> 07:17.280 Well, that's interesting question. Okay. So, at the moment, we are considering setting up a 07:17.360 --> 07:25.040 rack of foundation. Oh, okay. Well, hold that little thing in the software Stuart situation. 07:25.040 --> 07:36.000 Okay. So, yeah, it's really an open question in our case. I guess for Pearl, it's a similar situation 07:36.000 --> 07:43.440 because there is a foundation, but the foundation is not really involved with any coding or anything 07:43.440 --> 07:49.520 like that. So, and I'm not sure how it is with other foundations, but this is an open, 07:49.520 --> 07:53.520 this is a difficult question to answer at this point, I think. Michael, what you're thinking 07:53.520 --> 08:02.160 about about foundation versus non-fondition-based projects? Well, foundations or they might 08:02.160 --> 08:10.000 be capable to do more stuff and in case of an open source Stuart. So, the Stuart is intended to 08:10.720 --> 08:18.160 manage open source components which are intended to be integrated into products. So, they might 08:18.160 --> 08:24.720 be capable to fulfill the Stuart's obligations like reporting vulnerabilities working together 08:24.720 --> 08:33.200 with the market surveillance, then small maintainers and we did a questionnaire last year where we 08:33.200 --> 08:39.280 asked maintainers what their main worry is. And once in one comment, which came out was like, 08:39.360 --> 08:47.360 I like to code, I don't want to manage. So, they just want to do stuff and they might not want 08:47.360 --> 08:56.240 to interact in the way like Stuart's can. And one thing we see or we also see is right now 08:56.240 --> 09:02.640 not everything is great and we got to the CIA. So, we talked to Daniel from Pearl, 09:02.880 --> 09:11.520 what he is seeing that manufacturers in that case, not from Europe, approached him, sent him an 09:11.520 --> 09:18.480 extra sheet and gave him a two-week timeline and for the CIA, we need all those informations 09:18.480 --> 09:25.840 please provide it to us. And what can go wrong with that? Definitely what we don't want to see. 09:25.840 --> 09:33.760 So, we have to find ways that those things don't happen but the ones who can provide it and they 09:33.760 --> 09:39.760 want to provide it that they come get something out of it and that they can be part of the process. 09:40.720 --> 09:45.840 But again, they need to have something out of it. Nobody wants to do it for free. 09:46.560 --> 09:53.440 And we don't want to be to have the pressure on open source that they're providing the open source 09:54.400 --> 10:00.720 now everybody wants that all the services around it are also free. That's not what needs to be there. 10:03.600 --> 10:09.600 I think that manufacturers should see open source more as a resource rather than something 10:09.600 --> 10:18.880 that they can plunder at will. And the resource that needs to be cultivated and that's a change 10:18.880 --> 10:23.600 that we need to strive for, I think. Yeah. So, I have a question for the audience because 10:23.600 --> 10:28.560 several of you are seeing with your phone or your computer, you should be listening to what we're 10:28.560 --> 10:37.280 saying. One of you is actually a mentor of a project working integrated in a larger 10:37.280 --> 10:44.480 foundation or is a solo mentor. So, solo mentor raise your hand. Okay, it's actually a good 10:44.560 --> 10:50.800 part and projects incorporated in foundations maybe in properties, not the right term, but go ahead. 10:52.000 --> 10:58.080 Okay. So, probably a bit of representation of both. My understanding is that 10:58.800 --> 11:04.160 there was an article made by a guy called Josh Brescher, is a sizzle at Omkore. This point was 11:04.160 --> 11:10.960 open source is an army of one where basically the large majority of projects are single mentors. 11:11.920 --> 11:18.640 Last year there was a guy mentioning a Python package called Chrome Ether and he says, 11:19.920 --> 11:22.640 I'm stopping maintaining this project which is used everywhere. 11:23.440 --> 11:29.360 Series killing me, I don't want to be part of it, bye-bye. So, what do you see? What can you tell 11:29.360 --> 11:34.400 about that? What do we do for the project of ones that are scared and want to run away? 11:35.920 --> 11:39.760 Well, in our case, we have something called Racco Community Modules. 11:39.760 --> 11:46.960 Basically, what? It basically means that the original author has decided to not be bothered by it anymore 11:47.680 --> 11:52.640 and people still use it and people want to maintain it. So, we make it a community model, 11:52.640 --> 11:57.840 basically means that we have a set of people that have rights to the community modules repo 11:57.840 --> 12:02.320 and they can do the maintenance and then all of the pull requests and all the stuff around it. 12:03.120 --> 12:07.600 So, it becomes really becomes a community effort. Okay, but how would you 12:08.560 --> 12:14.960 How could we avoid that people get scared and stop supporting and maintaining their projects? 12:15.760 --> 12:23.840 Because of the series. Is it rational? I mean, people have to make a decision. I don't think you can 12:23.840 --> 12:28.000 actually prevent them from being scared because it is the EU doing these things and 12:29.040 --> 12:31.840 you know, we have surveillance here as well. So people might 12:32.240 --> 12:38.400 get scared. But that's not a surveillance. You need to be scared about it. I think it's actually an opportunity 12:38.400 --> 12:42.800 for you to continue doing the things that you'd like to do, which is coding. 12:43.520 --> 12:48.240 Okay, I'd like to go more on that terrain. So, how can we do more? 12:49.040 --> 12:54.400 And what can we do if we want to help with our project? Given an army of one, we're 12:54.400 --> 12:58.800 everything related to the series. You said it's an opportunity. I'd like you guys to to expand on that 12:59.760 --> 13:05.200 First, I want to say something. Please don't be scared. Market surveillance is not coming 13:05.200 --> 13:12.160 after free and open source of them. So, we have products on the European market and that's 13:12.160 --> 13:20.880 what the CRAs for, which doesn't comply to a lot of the requirements from the CRA and those are 13:20.880 --> 13:25.680 the things we don't want it or we don't want here. And we need to so well, 13:26.560 --> 13:29.280 won't be the free and open source of stuff. 13:31.840 --> 13:39.040 I wanted to develop a little bit more the chronic situation. So, the maintainer got scared. 13:39.040 --> 13:47.200 He wanted to delete his GitHub repo and just go away. So, I know a little bit more because the 13:47.200 --> 13:55.280 help came from the participation from Apache Airflow. So, in the end, what happened is he gave 13:55.280 --> 14:05.200 the project to two downstream containers that are continuing the project. So, don't be scared. 14:05.200 --> 14:15.200 Don't drop everything and as the mostly mostly don't close delete GitHub repos, reach out to 14:15.200 --> 14:21.440 downstream users. If your project is used, they will be happy to help you. Okay. So, in this case, if 14:21.440 --> 14:28.640 I recall correctly, as you said, the quality was a dependency for Apache Airflow. 14:30.640 --> 14:37.840 In this, the dependency of Apache Airflow, Yarek Pothuk, talk with the maintainer, talk to you 14:37.840 --> 14:45.200 into, he wanted to talk to him into not being scared that was not possible. So, of course, 14:45.280 --> 14:53.040 everybody decides for himself. In the end, he talked to him into giving the project to another 14:53.040 --> 14:58.000 foundation, not the same, but another foundation and Yarek and another Airflow 14:58.000 --> 15:03.280 maintainer took the ranks. Yeah, it became part of the jazz band kind of group of project, 15:03.280 --> 15:09.520 right, something like that. So, if you want to give up because of the CRA, basically the word is 15:09.520 --> 15:14.480 reached to your downstream users and eventually they'll take care of this for you because they need 15:14.560 --> 15:23.040 your code, right? So, we don't have to be scared, we can do nothing. What's the upside with 15:23.040 --> 15:32.080 all this? Is there any upside? Well, I think one of the upside is that even if you don't do 15:32.080 --> 15:38.800 anything about this, anybody doing patches for you on the stuff that they fork from you, 15:39.680 --> 15:44.480 they have to deliver the patches up to you. Even if the license doesn't say so, 15:45.200 --> 15:51.840 which I think, if you really think about this, it could be mean that you, for free, get people 15:51.840 --> 15:57.120 actually maintainer your module. I mean, that's one way of thinking about it, although that's a very 15:57.120 --> 16:05.760 minimal way and if you really want to get more involved with this, again, making sure that 16:06.080 --> 16:10.480 you are providing stuff for it and not just saying, I'm going to have to do a lot of work, 16:10.480 --> 16:19.440 but I'm going to get some kind of remuneration for it. It's a good thing and a positive thing 16:19.440 --> 16:26.240 and builds on the resource aspect of open source. What do you think the upside could be, Michael? 16:27.280 --> 16:35.040 Yeah, one thing mentioned and Toby had a whole presentation without slides on it, but he made it very 16:36.000 --> 16:43.840 good. The opportunity for the open source adaptation and there are a lot of discussions on that. 16:43.840 --> 16:50.640 We as PSI and the Free Software Foundation Europe published and surveyed today, there is also 16:50.640 --> 16:57.840 and surveyed from the Eclipse Foundation and there are a lot of discussions from the Eclipse Foundation 16:57.840 --> 17:04.080 and whatever is doing that and there will be a talk on that tomorrow in the other policy, EU policy 17:05.040 --> 17:13.280 if we get that right, that could be something where manufacturers get the adaptation, pay for that 17:13.280 --> 17:19.360 and then developers and if we get it right, even single developers might profit from and then 17:20.480 --> 17:25.040 they can provide more time for their stuff they're doing, 17:26.720 --> 17:33.360 this projects might get better because they can put more attention on it and then even the manufacturers 17:33.440 --> 17:40.000 might or will have something out of it because they get better open source components to put 17:40.000 --> 17:47.120 in their products. So you see attestations about security in an open source project, 17:47.120 --> 17:54.320 eventually as a new currency, can a new token where we sell as open source project 17:54.320 --> 18:00.480 that stations to users commercial users that won them? I see that as a chance because 18:00.560 --> 18:04.960 manufacturers are responsible for everything and if they have something, 18:05.920 --> 18:10.960 they can show that they've done their due diligence and they pay for the commitments 18:10.960 --> 18:17.360 the open source maintainers put into their projects, then if we get it right, I see the 18:17.360 --> 18:23.040 big chance to get some money flow towards open source. What about this, do you see Plot? 18:23.440 --> 18:35.040 Yeah, I do so also something that we said that probably there will be some professionalized 18:35.040 --> 18:46.400 maintainers, I think that's a reality that's a very strong possibility for such a thing to happen. 18:47.040 --> 18:59.920 Personally, I'm living from open source since 2023, so that's so ice, well, when I 18:59.920 --> 19:06.880 when I reach three years of 100% professional independent of the source maintainers, 19:06.880 --> 19:13.360 let you know, but I think that's something that we can count on. Is there a risk that they are 19:13.440 --> 19:20.400 commercial, middle man, that would establish themselves as, you know, attestation paddlers, 19:20.400 --> 19:27.440 and that we'll just annihilate any opportunity for you to ever sell any of these services, 19:27.440 --> 19:35.120 because they will aggregate and be an easier worker to deal with. There's already a few companies 19:35.120 --> 19:41.280 like that. There is a possibility, but I know also a couple of nonprofits that 19:41.920 --> 19:48.480 support to do that and well, since the lowest price drives, so I come in shell 19:48.480 --> 19:52.960 actor needs to have a higher price. Please, you want to say something there? 19:53.680 --> 20:01.520 Yeah, I think we need to try to stay away from the paper adaptation idea, because that becomes a 20:01.520 --> 20:06.560 commodity that becomes economically viable for some company to actually start providing. 20:07.520 --> 20:12.800 I'd rather see a situation where a software steward would actually offer 20:13.920 --> 20:23.120 attestations on demand at a certain subscription price for sponsoring for the steward. 20:25.920 --> 20:33.120 Could we, from a regulation or government point of view, help this process to, 20:33.200 --> 20:40.000 maybe, say, attestations should come from the origin of the stream when available first, 20:40.720 --> 20:47.280 and only from other downstream repackagers, if not available for the upstream, 20:48.000 --> 20:49.520 to get the middle man. 20:56.160 --> 20:57.600 That's an interesting point of view. 21:03.520 --> 21:09.440 So, the question was, is someone made a business out of deadly attestations that they would 21:09.440 --> 21:16.400 become manufacturer themselves? That's a question. Is that the case, you think? 21:18.720 --> 21:22.640 You have to look at it in detail, but that could very well be the case. 21:22.640 --> 21:31.920 And the thing is, good. Right now, first, it's not clear what the adaptation itself is, 21:32.000 --> 21:39.280 what's, you say, if it's commercial, it's going to become a support service, 21:39.280 --> 21:44.800 like any other support service. But you're saying, also, maybe, that if I'm a 21:44.800 --> 21:52.480 solvent and irrevervenous was project, and you're building something, you ask me for an attestation, 21:52.480 --> 21:56.080 I sell you this attestation, all of a sudden, I become a manufacturer. 22:01.920 --> 22:06.800 How much of this is acceptable. If you are just covering your costs, including your time, 22:06.800 --> 22:12.800 that is not necessarily commercialization. There will be a limit, and we need that limit, 22:12.800 --> 22:18.640 you're fine. If you're still not rocket, I mean, clear, so there's going to be some interesting 22:18.640 --> 22:25.040 things to do. Go ahead, please. I'm just envisioning that some commercial entity decides 22:25.040 --> 22:29.280 to fork everything and decides, okay, this is our fork, and we go providing attestations for it. 22:32.400 --> 22:39.440 No, because they would be forking, they will be working off the fork and devise claiming, 22:39.440 --> 22:44.080 this is our resource, right? So, they would be claiming that this is our fork, 22:44.080 --> 22:45.760 we provide attestations for it. 22:45.760 --> 22:50.720 I do, it's on our list for it. Or, it's commercial entity, can you give them any questions? 22:50.720 --> 22:57.520 Okay, I think there's going to be, I'm sure there's going to be interesting case to discuss, 22:58.480 --> 23:07.440 talking about that. There's an obligation to CRA for manufacturers to somehow eventually 23:08.160 --> 23:16.240 report upstream security issues that they found. What will you do with this? If you receive 23:17.120 --> 23:24.320 security patch from company X, Y, Z, for lock for J, security issues. 23:28.320 --> 23:32.640 They need to send a patch. I don't know, I know exactly what the obligation will have to send a 23:32.640 --> 23:39.440 patch or just report the fact that discovered an issue. But how do you see this process? Do you see? 23:39.440 --> 23:45.520 So, if we receive a patch, it's like every average security issue, we just handle them. 23:46.240 --> 23:49.840 And it's better because we have to have a patch that we can compare against. 23:51.120 --> 23:55.920 Please, you have an option, a piano on that? Any patch is a patch? 23:55.920 --> 24:01.200 Okay, can I just sit on it and ignore it entirely? Or do I have any obligation on this, CRA? 24:01.840 --> 24:04.560 No, you are cementer, I'm not going to just take it or leave it. 24:04.560 --> 24:07.040 Okay, so you're not seeing the minute for that. 24:07.040 --> 24:13.040 Now, I have to report and to provide a patch if we made a patch. So, he has to do both. 24:13.120 --> 24:17.840 Okay, we've talked about the fact that I can do nothing. I can ignore patches. So, basically, business 24:17.840 --> 24:23.920 is usual for me as a man-tener. We have a potential upside with attestations. There's some 24:23.920 --> 24:31.360 Graria, maybe with middleman's. What are other things if I want to be more proactive as a man-tener 24:32.240 --> 24:34.720 that I can do? What do you think, Michael? 24:35.680 --> 24:44.000 Well, I see a lot of open sources already doing. So, they're taking a lot of them are taking 24:44.000 --> 24:50.320 the principles of security, by design, security, by default, into account and do it like that 24:51.600 --> 24:58.240 because it's open source, the point with S-bombs. So, if the tooling is there, that's one thing which 24:58.320 --> 25:08.240 can be covered and they can use tools like open S-bombs provides a lot of tools if they want to 25:08.240 --> 25:13.600 use it to make their products more secure, so there's a lot of stuff out there. Great, but they can 25:13.600 --> 25:18.800 decide what they want to do and how they want to do. Thank you. Liz, what do you think? What are you doing? 25:19.760 --> 25:33.280 I lost my train of Sautia, sorry. I think that we, we should really try to see open source as a resource. 25:34.240 --> 25:40.560 That's really the most important thing here and the other thing is, if I kind of back to the 25:40.560 --> 25:46.080 module maintainers, there's a very nice new standard in development, I can understand that about 25:46.240 --> 25:51.360 how a maintainer of a module can describe what they want to do with the module, what kind of 25:51.360 --> 25:59.360 support they want to have and give the contributing dot-yamel. Oh, that's plethora. And Sautia. 25:59.360 --> 26:05.200 Yes, Sautia. Okay, great. And basically, as a module maintainer, look at that standard and make 26:05.200 --> 26:09.920 sure that you provide the right data and that sends us also garbage in garbage out if you don't 26:09.920 --> 26:14.480 provide it and nobody knows what about what to do with your module and if you do provide it, 26:14.560 --> 26:18.720 they have some more information to handle it. Okay, things to search for. 26:18.720 --> 26:26.400 Sautia, it's contributing dot-yamel. Good. Yeah, yeah, yeah, it's a 26:26.400 --> 26:35.360 acmatici, tg4, contributing yam, recommend found a nice, nice name, yet Dugnak was one of the 26:36.320 --> 26:47.360 that's terrible. Tc54, yes, tell out to our key for make now. It's a task group, tg something 26:47.360 --> 26:56.720 under tc54. Tg, tg4. Tg4, yeah. Okay, from my perspective, the projects have to have to 26:56.800 --> 27:03.680 two choices under this area. And then do nothing and then maybe receive, receive help from 27:06.080 --> 27:11.440 companies or they can choose to be proactive, introduce a lot of 27:12.320 --> 27:18.480 standards for a fuller project that that's what we chose. So we chose to go forward 27:18.560 --> 27:30.240 to help companies first and then hope that they will help us back. So we are almost a salsa source 27:30.240 --> 27:35.760 level for compliant. Well, she means that we have two reviewers for each PR, which is 27:35.760 --> 27:43.520 actually a bit difficult because we have two active commuters, but whenever I make a PR, I think 27:43.520 --> 27:51.200 you've all come whenever he does a PR, he thinks me, but yeah. And I think you've experimented 27:51.200 --> 27:57.440 also to producing vex documents. Can you tell us a bit about your experience, is there? 27:58.880 --> 28:10.320 Yes. So we chose as bombs in 2023. Well, as a moment was quite, quite easy because the 28:10.320 --> 28:17.920 tooling was there. I'll introduce the videos almost immediately as fuller projects just the 28:17.920 --> 28:25.600 list of vulnerabilities that we have. And now I'm experimenting with vexes with Monowar with 28:25.600 --> 28:31.680 open refactory. We have a tooling that generates vexes for a patch of solar that has 28:31.680 --> 28:38.240 400, first-party dependencies. Once that works, we will of course use it in a forge 28:38.240 --> 28:49.600 that are far less dependencies. No. Okay, so other questions should you, I'll shoot a 28:49.600 --> 28:54.240 maintenance or a filament and I'll become parts of the foundation because of the series. 28:55.440 --> 29:02.320 And should I become a steward? What's the up, what's the pose, what's the calm? Is there any 29:02.800 --> 29:07.920 restrictions or additional work for me if I become a so-called steward? 29:09.600 --> 29:12.320 And you, Michael, maybe you have a word on that? 29:14.080 --> 29:19.600 A steward has certain obligations under the CIA. So again, the reporting obligations 29:20.960 --> 29:29.920 working together with market surveillance and we need to have in place vulnerability policy. 29:30.000 --> 29:37.440 Okay, but there's the trick they don't get any fines if they don't follow those 29:37.440 --> 29:42.640 obligations. That's something which fines are only there for manufacturers. 29:44.240 --> 29:48.800 I think it's the decision of the maintainer if he wants to become a steward. 29:49.440 --> 29:56.960 Again, I was surveyed last year, the ones who answered it. I think two thirds of the ones who 29:57.040 --> 30:04.320 answered said they don't want to become a steward and they don't want to have any other entity 30:04.320 --> 30:11.440 than themselves to be a steward for them. So the projects who answered were in favor of just 30:11.440 --> 30:19.200 being a project in maintaining. Okay, and okay, you can, you can talk to that, please, 30:19.200 --> 30:23.040 otherwise I think we're reaching the time limit, so I want you to make sure that you just 30:23.040 --> 30:31.680 give a less word as a maintainer to the other maintainers. Few words. Yeah, also, so if you are 30:31.680 --> 30:37.120 thinking about joining the patches of the foundation that could be difficult because you need to 30:37.120 --> 30:46.320 first ramp up on your community to have at least three commuters, but then when projects are 30:46.400 --> 30:52.720 all there and there is only one active maintainer, the fact that the steward helps you with 30:52.720 --> 31:01.280 the foundation of those people. Okay, but so final words to maintainers when it comes to 31:01.280 --> 31:09.120 the theory. Keep doing what you're doing. Okay, Michael, and you have time while doing it. 31:09.120 --> 31:17.920 Great, pure, and don't panic. Okay, great. Thank you.