 So I'm going to talk a little bit today about the Open Wallet Foundation project proposal process. I guess, are people here familiar with contributing code to open source and everything? I know some people are, but we'll go over everything in some detail today. And please feel free to ask if you have questions. So let's get started. So before we really talk about the mechanics of contribution, I would like to emphasize why are we doing this in the first place? Why should you contribute to the Open Wallet Foundation? The OWF is a consortium of companies and organizations that are looking to drive adoption of open and secure digital wallet solutions. So the OWF is an open source foundation. It is not a single wallet. It is a wallet engine. It is a set of wallet components that you can use to build a digital wallet. And I want to emphasize that the Open Wallet is explicitly neutral. So one thing I always emphasize when I talk about Open Wallet or most Linux Foundation projects, for that matter, is the technical community is 100% open. So it's never pay to play within the Open Wallet Foundation. You can always participate as an individual, an employee of a company or a corporate member. But the technical side of participation is completely open. Anyone can contribute. Anyone can start a project. Anyone can lead a project. Everything is open. So when people ask, should I contribute, I usually provide the following fundamental question. Do you want to develop collaboratively in the open on wallets and wallet technology? And if the answer is yes, then I certainly think you should contribute to the Open Wallet Foundation. This fundamental question or fundamental problem is really what the Open Wallet Foundation was designed to solve. We get frequently a few questions from people asking about contributing to the Open Wallet Foundation. One of them is, what if I don't have any collaborators yet? What if I'm looking to work in the open and looking to work with other people, but I don't know who I want to work with yet? Or maybe I don't know who's interested. I often encourage people and say that contributing is a great way to find collaborators. If you show people what you're doing in the open, it's a fantastic way. People will often come out of the woodwork. You'll have people who you had no idea who are working on the same thing or something similar. And I will say our labs organization is specifically designed to be a place where companies or individuals or really anyone can contribute and show off code to others to try to kickstart full projects and find collaborators. Another question that sometimes gets asked is, do I lose control of my project if I contribute? And this is not the case at all. We ensure that projects starting in the OWF transition really seamlessly from their old homes into the Open Wallet Foundation. So the maintainers, the contributors, the governance start off essentially the same. And as more contributors can come along, these things can change. But if you have a huge influx of people working on your project, we think this is a great thing. And we also can ensure that when you contribute a project, you can write a project charter to make sure that your projects will remain focused on their original missions. So what kinds of code should be contributed? So we get all the time people ask, what is in scope of Open Wallet? There's a ton of things in scope of the Open Wallet Foundation. Here I've just listed some of the things that the Open Wallet Foundation architecture group has listed as things they're interested in. And this is really not an inclusive list. And what types of wallets? There are many different wallets people want to consider working on. Native wallets, web wallets, we have a ton of people who are very active in the digital identity community, some of whom I'm looking out right now. And this is another hot topic. And as we go forward, we expect that even things like NPC wallets or other wallets that use advanced cryptography will also become popular. So really, there's a very broad scope for the OWF. So let's get in now with this background in mind to how the project lifecycle process and how projects actually are proposed at the OWF. So projects begin with a proposal that must be accepted by the Technical Advisory Council. And this isn't usually a PhD defense or an interrogation. It's an opportunity, instead, usually to present your work to the community and hopefully encourage other people to contribute or join your effort. And we have three main stages of projects in the Open Wallet Foundation. There are labs, which are things that are starting off. So this is early or experimental code or people looking to start collaborative development, people who want to show their code, say, hey, I want to get started. I want to do open development. Here's what I've got. Come join me. Then we have the growth stage. And the growth stage is really for projects that are looking to, as the name indicates, grow. So this is for projects that really want to get more diverse contributors, add more maintainers, and really expand their footprint. And finally, we have a mature project lifecycle status called Impact. And this is for projects that are popular, have a big development community, have diverse maintainers, and long-term support. And then because not every project is successful. And we want to celebrate this. And we want people to be OK with this. And we do have a project status called Emeritus, which is for projects that are sort of finished or the maintainers feel are reaching the end of their life. And I do want to emphasize that this is a natural part of the open source lifecycle. As Jim Zemlin will tell you, there are really only one or two projects that have defied sort of gravity in open source. And this is a natural thing. So as I sort of sketched out earlier, the project acceptance process is really quite simple. It involves filling out some documentation and then presenting a proposal to the TAC. And the TAC presentation is really more about telling everyone in the community what you're doing and looking for contributors. And I will say also that the TAC will determine the appropriate initial stage of the project. But projects can ask the TAC. They can suggest which stage that they think they should begin in. So the proposal is really easy. This is everything you have to say, basically. It will take less than an hour if your project code is already open sourced. I'm not going to read through everything here, obviously. But I just want to put this up there to emphasize that it is very, very simple and quite straightforward to contribute a project. Going a little bit in more detail to some of the life cycles. So this is the life cycle stage for labs. So this is the most basic and simple project status. And it's really easy. You can contribute and submit a lab in a half an hour. And we really want people to contribute their experimental coding efforts to labs so that we can help foster collaboration. We don't necessarily encourage people to use labs in production, although certainly across the LF, we see people that maybe do do that. But labs are reviewed on an annual basis. And again, labs are explicitly for experimentation. So we don't necessarily provide CICD support, security, bug bounty programs, or audits for labs programs. So growth status means that a project really wants to grow and move forward. And the requirements are a little bit more explicit. I don't necessarily want to go through all of those, but you can see them for yourself. We do generally expect projects in the growth stage to move out to impact status within two years or perhaps move on to other projects and become emeritus. We recognize that this doesn't always happen. And depending on their plans, projects may move around in a number of different directions. And finally, there's the impact stage of the project lifecycle. We expect impact projects to have a big participation in the foundation, have a diverse membership. We expect these projects to be used. They are sort of the final form of open wallet software. And as such, we expect diverse contributors. We like to use the metric of if one company or one core individual went away, would the project continue seamlessly? This is really important and open source. And that's what we expect from the impact lifecycle stage. And finally, there's the emeritus stage. I don't want to emphasize that projects do end. It happens for many for good reasons. And it's also notable that emeritus projects can be reactivated. And this hasn't happened yet in the open wallet foundation, but we have seen this happen in other sister foundations in the Linux Foundation. Yeah, and I'll just put up some links in here. I'm sure you'll see these throughout the day. But we would certainly encourage people to get involved on mailing lists, on our Discord, which is extremely active, and check out our GitHub and everything else. So thanks. And I guess I'm out of time. So I will pause for any questions. Are they're in person or if possible, remote? Yes? Who are currently known for their young code, its identity, and the use of identity for many trust-oriented applications. And they are considering to find their home for their software and software project. What will be their best advice approach to the future? How do they handle it? So yeah, I mean, practically we encourage people to speak with members in the community. So if they know people in the community, to talk to people they know, if they don't know anyone, to ask. Personally, I think Discord is a great place to ask. That's where I would recommend people to go because I think you get the fastest time there. We seem to have people moving away from email lists, which is great. But so yeah, I'd say get involved in the community, come to the TAC meetings, come to the architecture meetings. You don't have to talk in the meetings. We're not going to interrogate you. Lurking is definitely OK. But I would encourage people to join the community and talk to people. And then if they're comfortable, to contribute. And I also think contributing is a great way to get involved in the community and to make a splash because it shows other people what you're doing. You say, hey, this is what we're doing. Is anyone else doing something similar? And then that's a great way to foster collaboration. Any other questions? All right, well, if not, thanks. And I'll turn it back over to Torsten.