 Hi everybody, and thank you for joining me on this presentation about finding a foundation for your open-source project. Let's start with a little context. First of all, why this topic? Well, it turns out that I've been focusing on governance questions and open-source foundations in my consulting practice a lot over the course of the last two years. I've been consulting for the AMP project to bring it to the OpenJS Foundation. I've advised the Coil Company on setting up its Intelligent Foundation. I've done pro bono analysis work to see if it made sense to set W3C's headquarters in Geneva, Switzerland. I'm currently working also pro bono on creating another software foundation in Geneva. I've been sitting on the OpenJS Projects Advisory Council and the OpenJS Foundation Cross-Project Council. So with this sort of background, let's get started. The first question that comes up to mind is, well, what is a foundation and what is it for? And it turns out that a foundation essentially provides a legal entity for open-source projects. And it can do a lot of things that a project by itself is not legally entitled to do. It can receive and spend money. So this is great for, for example, travel expenses, infrastructure costs, et cetera. It can acquire its own assets, which is important to hold trademarks. It can grant and receive licenses, which is great for copywriting and patents. It can hire people, for example, for coaching or for security audit. It can host events, et cetera, et cetera. So essentially a foundation is there to give to an open source project the kind of legal structure that empowers it to do the kind of things that normally either a person or a corporation are able to do. And, you know, if your instinctive reaction to this description of what a foundation is, is to wonder, wait, do I really need this? It's probable that you actually don't, right? And so, you know, if that's the case, I think now is just like the right time to leave on the room and go maybe find another session. No, I'm joking. Of course, you're welcome to stay here. But I think it's really important to remember when you're talking about moving a project to a foundation that the timing is critical, right? And why am I saying that? Because essentially you are always better off moving a project to a foundation too late than too early. And so what you essentially want to do is wait until you start experiencing the growing pains and to be sure that these can be solved by a foundation. So what are good examples of issues that can be solved by a foundation? Well, there are multiple, right? I think the first one, the very common one is an operational issues. And when we decided to move the AMP project to the OpenJS Foundation to start looking for a foundation that would host it, these were operational issues were critical to how we were thinking about this. And for example, we were having problems covering travel expenses of members of the advisory committee and the technical steering committee. Also, data protection requirements, GDPR and for those that are familiar with it, added hurdles to organize the community driven contributor summit, right? And another example was, well, the CLA asked contributors to assign their license to Google. And this was a detriment for many AMP contributors, for understandable reasons. Another common reason to move to a foundation is when you really start to have trust issues. Someone that holds too much power in the project owns the copyright, owns the trademark, and other players are starting to question the motivation, and as a result, not engaging fully or even taking a step back. Desiring community ownership, sorry, is also a common reason to, and a sound reason to decide to move to a project. And so is in the multi-stakeholder situation creating a level playing field, right? It's very difficult to get other players involved again, if there is a clear competitive advantage of owning the copyright of a project or owning its trademarks. So all of those are really good reasons to move a project to a foundation. But you might ask, why would you want to move as late as possible? Well, the thing is like a foundation isn't free, right? It adds a bunch of overhead. There's a lot of things that you could do before really easily that suddenly you have to go through more process to do. And there's actual things that you have to do that you didn't before, right? If you have a legal entity, you suddenly start to have to pay taxes or at least like, you know, get tax reports ready. Secondly is a foundation costs money, right? It's not, depending on what option you choose and we'll look into this shortly, it can be a lot of money and not a lot of money, but it's still costly, right? And lastly, you can actually start on that road to a foundation without needing to create a legal entity. For example, if your issues are mainly centered around an open governance model, well, you can totally have an open governance model without moving the project to a foundation. And that's actually what we started doing for the AM project, right? So we launched in September 2018 an open governance model for the AM project was the goal of moving the project to a foundation at a later stage. But we already had the governance model out and implemented by the end of that year. Moving the project to a foundation took a whole other year, essentially. All right. So you've actually determined that this like moving to a foundation is actually in fact for you. And now you're like trying to figure out in that sea of option, what exactly what exactly you should move towards what's the right option for you. Right. And as you will quickly see, there are plenty of options and there are plenty of different foundations and different solutions that are adapted to a widely different set of needs. Just to give you some sort of like idea of the lay of the land. Foundations come in all shapes and forms, right? Just pulling out the yearly revenue of some of the key software open source foundations in the software space. You'll see, for example, the Apache software foundation is a 501c3. So from that's considered a charity and that's in two and a half million functions on two and a half million dollars of revenue. Whereas the Linux foundation, for example, has close to a hundred million dollar annual budget. And is actually a 501c6, which is more of a member consortium type of structure. And that's in the US only, right? Most jurisdiction have equivalent legal structures. And so there are a lot of standard bodies, for example, that are located in Switzerland. I actually think that Switzerland's jurisdiction structures, foundation structures are both lightweight and super flexible. So they're good to create like your local chess club, but they're also you can use the same structure to create something like FIFA, right? So really highly flexible solution. And there's a lot of software foundations that are located in different parts of the world. And so when you decide to make that move, you'll see that foundations come, as I said, in all shapes and form. There are sort of like four main category of structures that you can form kind of like main things that you can do. The first is to join an existing foundation. The second is to create a foundation within a foundation. The third is to rely on foundation as a service. So essentially create a foundation but outsource all of like the operating the operations to a third party. And lastly, you can essentially roll your own either in the US or elsewhere. So joining an existing foundation is like a really lightweight option. And, you know, an example of that would be just joining the Apache software foundation and the software Freedom Conservancy becoming an OSS project to joining the OpenJS Foundation. The benefits are that this is super lightweight. It's cheap, fast to set up, there's little to no maintenance overhead. If you have a government governance in place, it's essentially going to add a bit of formality around it with super lightweight. And generally, there are no membership fees for joining a foundation like this. It's the operations are covered through sponsorship. So the cons are that this is not really flexible. Either the foundation system, culture, tooling infrastructure is what you want, or it's not. And if it's not, you're out of luck. It's also often a limited solution in terms of what services the foundation offers very often really focused around IP. And there is a lack of independence, right? So essentially, you have to follow the rules. A second option here is having a foundation within a foundation. So this is something that the Linux Foundation has been driving quite a bit. It's one of the models favored by it. And it essentially creates projects of the Linux Foundation, which are cold foundations, but from a legal perspective aren't really a separate legal entity. The benefits is that it's actually quite customizable. You can really do a custom structure for your foundation. It's also still cheap and fast to set up because you don't have to create the legal herd. There's no legal herd all around it. On the other hand, some of the key issues is, well, first of all, it requires members of the foundation to pay membership fees to both the parent and the child foundations in the structure. So if a lot of you would be members or already member of the host of the parent foundation, that's fine. But if that's not the case, then it creates a substantial extra fee because your members will need to become members of both foundations at the same time. And then the other con is that it's actually still very dependent from the parent foundation. So you can't just take this foundation elsewhere if you need it to. So foundation as a service is essentially you build your own foundation and you outsource everything to a provider. This is something that, for example, the OpenJS Foundation is doing. So the OpenJS Foundation is technically, from a legal perspective, a completely separate entity from the Linux Foundation, but it is outsourcing all of its operations to the Linux Foundation. The benefits of this is your legal structure is completely customizable. You're super independent. You can actually even purchase services from different service providers. And you benefit from the economies of scale of the service provider. So this is probably less costly for you than it would be to hire the same people because you can have, for example, someone that's doing PR on a 20%, but it would be really difficult for you to get otherwise. And you're free to set up your own membership solution. So you're no longer dependent on whatever solution your parent foundation has created. And of course, like the cons, you're really getting into the territory of rolling your own. And so it's complex to set up. You actually create the legal structure. There's significant maintenance overhead, et cetera. And lastly, while you can essentially roll your own and hire for your own organization, and so the benefit here is you can essentially build whatever it is that you want that falls in, you know, that is legal, right? And in terms of how you can structure it, how membership is organized, et cetera, there's a huge variety of solutions that you can build and really pick from. And so if you want something really, really special tailored, that's your option. And of course, the cons are super expensive, complex to set up, no economies of scale, high maintenance cost. All right. So we can sort of like place our different options on a, you know, a quadrants graph where we have on the white axis, essentially a costly and complex solutions at the bottom, cheap and easy solutions at the top, and on the x-axis moving from rigid on the left to flexible on the right. So the first quadrant top right quadrant would be ideal quadrant. That's our nice house, right size does exactly what we want it to do isn't too costly is quite flexible. Fits our purpose. Great. Going to the second quadrant. So a bottom right, you're in very flexible but expensive and complicated. So sort of like your own private island. It's great, but you have to fly there was a plane. It's expensive. You have to have people maintaining it. It's complicated. Third quadrant, your bottom left solution is prohibitively prohibitively expensive, super rigid, like you bought this castle and you have to now maintain it. It's horrible. You never want to be in this area. And lastly, the fourth quadrant is cheap and easy but fairly rigid. It's a tent. A tent is great. It's cheap, but you know, if it's cold, you can't really go if it's wet, it starts getting difficult really quickly. You have to go camp in certain areas, etc. So this is kind of like the lay of the land and if we start if we position our four options on this, we essentially get joining an existing foundation on the foundation within the foundation of the castle and sort of like the cheap but fairly rigid area and then in the expensive and complicated but flexible area we have the done for your model and roll your own. Right. And so what we can see here is that there is no perfect solution. It's always an issue of trade off. Are you going to favor more flexibility or are you going to try to be cost effective, essentially, or cost or both actual, the actual cost that you will put into it in terms of like paying money for it, but also in terms of like human resources and how much time you spend working on the foundation rather than on your project. Right. And so the question being, well, which one is a good fit for you? Well, it's going to depend on what your needs are. And so in order to have a better sense of this, like the next step if you're serious about this, moving your project to a foundation phase is why you actually have to define what your goals and requirements are. And so what's really important here is to have goals and representatives of the needs of your stakeholders. And those goals also have to be reasonable. Like you can't aim for CNCF like structure if you're not expecting to have more than 50,000 US dollars as a yearly budget. Then the next step is going to be to turn those goals into requirements. And those requirements will steer you towards a type of solution, you know, from joining an existing solution to completely rolling your own. And they will also really quickly help reduce the size of your option pool. For example, the Apache software foundation was not an option for AMP because of its requirements around tooling. The second thing that you have to really pay attention to when you're in that process is change. We sort of see the foundation, the software foundation space as rigid and fixed in time. And that is actually a pretty big misconceptions. It's evolving all the time fairly quickly because there are new structures that are being created as new languages, projects, verticals, gain traction, right? And existing structures change all the time. For example, when we're first looking at moving AMP, the Apache software foundation could have been an option. We didn't choose it because it was really rigid in terms of tooling requirements, and it's now loosening its requirements around this. So maybe for an upcoming project that would have had similar requirements, the ASF could be a good option. And then the second thing that you have to be aware of is there are lots of mergers and spinoffs being created all the time. For example, Phena has very recently joined the Linux foundation. So my advice here for you is to look around because it might be that you can join forces with something that's happening right now and find like-minded projects or individuals working on trying to solve similar problems right now. And that brings me to I think the third key point, which is to seize opportunities. When we were looking for an option for AMP, the OpenJS foundation, which was the merger from the JavaScript foundation and the NodeJS foundation was announced. And it looked like a great opportunity for AMP. And AMP joining that foundation early in the process was able to... AMP as a result was able to significantly influence the foundation and make it a much better fit for its needs than it would have had if it had joined a couple of years later. And so this kind of gave AMP a perfect option, which was both cheap and easy and rather flexible because AMP was able to seize the opportunity of this foundation being created and help shape it. Lastly, I think what you really want to do is, well, sorry, thoroughly I have a fourth point, is keep focused. Don't get distracted. Some foundations will offer a whole bunch more than what you really need. And if that's not something that you need, don't waste your time trying to find value in this. Focus on what you need, your goals and your requirements, not the extra stuff because it probably won't be very useful to you for a number of years. And lastly, and I think that's really key as learned from others, a lot of people, a lot of projects have been down that path already and go talk to them. It's the best way to avoid common pitfalls. It was extremely helpful on a road to moving AMP to the OpenJS Foundation, but what you have to keep in mind is to contextualize the advice that you're getting for your particular situation. Because two key reasons. One is the lay of the land has probably changed a lot since that advice was valid, as we have seen. And secondly is every project has different needs and hence they made different tradeoffs. You're not going to make the same tradeoff system, so keep that in mind. And lastly, if this is really mission critical, and this is a bit of a self-serving comment, obviously, but do get professional help for it. And like all of my clients will tell you, having someone do the work and walk them through that path is something that can be extremely helpful and that will let you focus on the project while you get the setup and the background for you. Alright, so thank you for your attention. That's all I have for you right now and we still have a bit of time for Q&A, so I'm happy to answer those questions. Thank you so much for your time.