 I'm Scott Nicholas. I'm Vice President of Project Formation for the Linux Foundation. And I set up projects with communities. Today, I want to talk to you about just some general guidelines on how you can set up successful and sustainable open source projects. This is not going to go through all of the minutiae and the details, but I want to touch on some general rules that can be helpful. I want to talk about different stages of projects, how you can start from the very beginning with some practices that will position your project for success, how you can transition and prepare a project to transition to a foundation, and then considerations when you're at the funding stage, when you're looking for resources from companies and other organizations to provide supports for the project long term, some ways of thinking about how companies will look at a return on investment from providing money to a project, and ways of structuring a pitch to be most effective. I am one of the attorneys at DLF, but I'm going to walk through practical suggestions, so none of this is legal counsel. I'm going to start by focusing on these three areas, greenfield communities, preparing for a foundation, and then the return on investment. So ultimately, there are four core elements generally to sustainable open source communities. These are neutrality, ID clarity, open governance, bureaucracy, and financial support ecosystem. To provide a little bit of granularity, more information. I'm moving away. Thank you. Gracias. To provide a little bit more granularity to this. So neutrality, a structure where no one company can take control of project assets. IP clarity, clearly state what the licenses are that you'll be contributing under and that the code will be available under. Open governance and bureaucracy. We want people to be able to participate in the project to earn technical roles through hard work on the project and financial support ecosystem. Most projects don't require funding, but there are projects where they reach a point where there are resources that they require to continue to grow, and the availability of that financial support and a mechanism for providing financial support can be very helpful in sustaining the project long term. Alright, so let's start with building Greenfield technical communities. This is just some very general guidance that when it's followed well, can position a project for success quite nicely. So, of course, you start an open source project, you've got to pick a license for us open is, for example, a license approved as open by the open source initiative. And then put the code in a public read repo, get lab, get hub. That's the basic step, but there's more. So effective projects will focus on some simple rules to lay a strong foundation for future collaboration and growth. One, tell people what you're doing. Sounds simple, but if you focus on doing that in an easy and direct manner, it can be very helpful. Two, make it easy for people to collaborate and three, leverage tools and resources for best practices. So let's dive into a couple of these in detail. So tell people what you're going to do. Explain what the purpose and scope is for the project. Have a read me file in the repo that sets forth what you're interested in doing. What problem are you trying to solve? And what are the code dependencies? What are the other projects that you're leveraging? Describe how the project is organized? Is there a co-component? Are there modules? Are there sub projects and write down your governance? It doesn't have to be complicated. It can be as simple as we have eight committers and they make the decisions or we are organized into the following structure. This group has a maintainer talk to this person if you have questions about that sub project, etc. Make your decisions publicly and document them. This is critical. So you can't be an inclusive, you can't easily be an inclusive project if you have private lines of communication. You can't get all time zones necessarily if you're doing private meetings. People that are unaware of the project don't have an easy way of tapping into that knowledge. And in the case of US export control laws, the specific exemptions are available for public technical conversations. So make your decisions publicly and document them. Prioritize documentation. So quick example of some well organized documentation from a project, Yachto project. We'll have a quick, I'll have a couple case studies of some projects at the end. Yachto will be one of them. But right here is a documentation. It's right on the website. Yachtoproject.org. It's all laid out. Quick build, what I wish I knew transitioning to a custom environment, how to get started and how to get operating. Very useful to have information presented like that. And that's hard work. Someone took the time instead of putting in code contributions. They thought about the documentation. They thought about how it should be organized and presented. And then they put it up on the website. So more examples on telling people what you're going to do. So write a mission statement, put it front and center of the repo. Readme file is a great location for that. Put your governance, how you make decisions and who makes them in the repo. Public code repositories have tools to facilitate communication. Use those. Avoid technical communications in private. We talked about that before. But GitHub issues, GitHub discussions, GitHub actions. All those can be very useful in facilitating communications and their GitLab examples are the same. All right. But also make it easy for people to participate. So provide resources for new contributors. When someone first lands on the project, they're not going to know very much about the project or how to get involved. So write down your requirements for contributions and have this file in the repo. All familiar with the contributing file. Those are very useful. Operate as a transparent, welcoming and inclusive community. And if you host meetings, document decisions in the meetings for the benefit of those that work in different time zones and consider rotating the time of meetings and make the meetings publicly available. More examples. So here we have Kubernetes documentation and right here making your first contribution. You go to CNCF. You go to Kubernetes. I'm interested in contributing. I need to recommend something that will tie into what I'm working on. There's your roadmap. Exactly how to do it. So having getting started or how to make your first contribution documentation can be very useful. Some projects have contribution requirements. Some have special technical roles. Document those so people can understand what it means to participate. If you have a hierarchical structure, which as projects grow and scale, they often find they want to have, where you have layers of maintainers, you need to document that. So if someone wants to make a contribution to a particular repository, they know where to start and they don't start necessarily at the wrong level of project. Code of conducts can be very helpful in setting conduct expectations for the project. It's part of being an inclusive community and those are very useful. When we set up our technical charters for our projects, we pull in code of conduct by default. All right. Lots of tools out there to help. This is in no means an exhaustive list. There's a lot that's been written on how to set up open source projects the right way. And, you know, there's many more, there's much more in terms of materials to read. Our open SSF project, which is focused on security, has a best practices badge program. Projects can go through that badging program, can get a badge for the project once you complete it. There's also security scorecards that we have. The to-do group is a fantastic resource for learning how to collaborate in open source for setting up open source program management offices, but they also have extensive information and documentation on how to start an open source project. So spend some time over the to-do group resources that can be very helpful. We are huge fans of SPDX license identifiers. So one of the components of a successful project that we talked about in the beginning was IP clarity. Part of that is having a license file right at the top of the repo that says, here's what contributions will be made under. But it's not uncommon to have some differences. I've never seen a repo that didn't have files contributed under a license that wasn't the project's license. Compatible, but different. And the way you can document that is use SPDX short-form identifiers. So as simple as comment, SPDX short-form identifier, colon, MIT, colon, Apache 2. The automated tooling that exists to do license checks can pull those tags and they can make software bill of materials from those tags. Very useful feature. And OpenSSF also has some security tools, fuzz inspector for C and C++. All right, so we've talked about some things you can do in the very beginning. As the project grows, one of the ways of accelerating growth is to look at transitioning to a foundation. This talk isn't going to focus on the mechanics of doing that. We host nearly a thousand projects at the LF. We do this a lot. We have a project that's looking for a home. Feel free to reach out to me or contact information at the end of this. But that's not the main focus of this presentation. But there are some things as you're architecting the project and designing it for its future growth that you can think about early that will help you when you make that transition. So in many cases, open source projects will start from either internal efforts at a single company or a small group of developers. It could be initially proprietary work that's open sourced by one organization. And it could have been started by that organization with the public-facing repos. It could have some financial support from that company. And that support can be very helpful in the beginning, but most projects will start without funding. It's not uncommon when a project starts to have all of the contributors from that founding organization. That's pretty normal. As the project becomes better known and understood and valued by the community, more contributors will join. That's one of the growth targets that most projects usually have. As projects as larger and companies think about joining that project, they will consider making a commercial dependency on the project. And certain decisions that you make early in architecting the project will make other companies' decisions about making commercial dependencies on your project much easier. So let's spend some time on commercial dependency. First, what are we talking about? A commercial dependency means that an organization is going to use the product as an upstream in its projects, products or services. So it's going to rely on the project for its business. If the project breaks that line of business, that product, or if it's another open-source project that it's pulling from, is going to have a problem in its builds. So what is customary when a commercial dependency is made? Organizations will usually have a due diligence review. And they'll ask their team. The team will say, we want to use this project. It solves a problem for us. It's interesting. It ties into something we're doing. We want to do this. And there'll be a due diligence process that their open-source program management office will send them through. Usually it consists of detailed questions about the project. What is the project? What does it do? Who makes the technical decisions for the project? So let's pause for a second. All those questions sound very familiar because they tie back to what we talked about in the beginning in terms of how to start, how to position a Greenfield technical project for success. Tell people what you're doing and tell them how to participate. So right here, your README file is probably going to have all that information. Similarly, you'll have the license information, and people can immediately see, okay, this project is using this particular license. It has these dependencies. I understand the license of the dependencies. I understand the license of the project. But other questions will be asked, too. And this will tie into some stuff we'll cover in a second. Do I have to transfer my copyright and contributions to the project? Or do I just make a contribution available under the open-source license of the project? What about the name? Are there commercial entanglements around the name? Is it the name of a competitor? Is the competitor's product the same name as the open-source project? What does the documentation look like? Is the project well maintained? When's the last time there was a round of bug fixes? These are questions that will be asked. So when you're starting the project, if you can get into the habit of clean documentation and regular updating and bug fixes, you can have these questions answered very quickly. And in fact, the landing page of the README is almost a prepared set of questions. And in fact, the landing page of the README is almost a prepared set of answers for the due diligence questionnaire that you hope other people to get by going through commercial dependency tests. All right. So I might have covered some of this, but how can you position the project for these due diligence reviews? Be precise about what you're doing, what your dependencies are. Have clean documentation. There's some other factors, though, that we'll spend a little bit more time on. So naming. When we start new projects at the LF, we talk about how hard naming is. It's very difficult and it can be a tremendous blocker because you can't get a repo, you can't get a domain name, you really can't get started unless you have a name. So it's important, but it also has to be necessary for a step. But there's some things that you can do to make it easier for companies to decide to become dependent upon the project. So naming the company after the project. Lots of examples of that. It has the potential to create confusion because when you're talking about the project, are you really talking about the project or are you talking about the company that started the project? Or are you talking about the company's implementation of the project that's slightly different than the project itself? People don't know. That raises questions. Anytime there's questions, that due diligence questionnaire grows, the sales cycle to get someone to commit to a commercial dependency, that gets longer. You want to shorten that sales cycle. You want to make it really fast, really easy for someone to become dependent on the project. Branding commercial products, rather, using the name of the open-source project creates similar potentials for confusion. So it happens a lot. But creates a situation where if that project decides to go to a foundation, you have to figure out how to separate the branding of the project from the commercial product. There's some approaches for that. But if early on you can have some separation between the name of the project and the name of the company and the name of any products and the name of the project, that makes this transition much easier. The name is also a sensitive point because it's considered a control point over a project. And so when people are looking to participate in a project, again, they're looking for IP clarity and neutrality. If someone else has a name that's deeply integrated into the project and owns that name, that's a potential to exercise control under trademark law. And it can, again, give rise to more questions and an extension of the sales cycle when you're trying to bring on new contributors. CLAs. CLAs are used by many, many communities. We have communities at the LF that use CLAs. There's a role for them. They can slow down onboarding new contributors because you have to get a corporate signature. Instead of just having someone make a contribution to the repo, they have to get something signed and then they can start contributing. Occasionally, CLAs will have a transfer title of copyright to one entity. And if it has that, you'll also start to get questions because that gives a specific type of control that's very topical right now and people are specifically concerned about which is the ability to unilaterally re-license a project to a license, for example, that may not be an open source license or approved as opened by the OSI. So that's something that if you can keep that out of a CLA, you'll speed the time in diligence review. All right, so how to structure a funding effort and why... I'm going to spend a second. Why do we care about somebody making a commercial dependency on a project? Making a commercial dependency on a project means they value that project. That is your notice that that is a company that you can approach and say, you're already working with us, we value your contributions, support us financially. So when it's time to secure neutral funding for a project, your lists of companies that you should talk to are those companies that have established commercial dependencies. So it's a really good thing to have. As you think about funding, there's some things that you can do and be aware of to position the company, the project rather, for success in making those pitches. And it helps if you formulate the pitch deck for the project and you should have one, with an understanding of the basic three reasons that organizations have for financially supporting an open source project. And there's others and there's different flavors, but in my mind, they boil down to these three categories. Companies participate in open source because it creates new sources of revenue or it allows them to reduce costs. Or it lets them solve a problem that they can only solve as a group that they couldn't solve by themselves. So generally, when we launch projects, we see a combination of these three factors. But if there's one factor that's particularly dominant for your project, talk about it. Talk about the cost savings that your project can deliver or the functionality that doesn't have to be invested in because your project is taking care of that as some examples. And this just gives a little bit more background as to the motivation of companies to participate in funding of open source projects and the momentum that exists in the funding of open source in the cycle. Because what happens is we start with open projects that are open base layers for proprietary products and services in compliance with the applicable licenses of the project. Those give rise to products and services which are monetized, economic value in the form of cost reduction or problem solving that can otherwise be solved or new revenues is recognized by the participating companies that then invest in new projects and the cycle continues. So when we're talking about positioning a project to ask for funding and to understand the return on investment metrics that a company will have, we need to put it in some context. We've got to talk about how much funding you're asking for. Sometimes we're asked when a project is starting, you know, how much does it cost? And that's a difficult question to answer because the immediate question we ask is, well, what do you want to do? So the first step when you're thinking about funding is what are your immediate term goals? What would you like to do in the next two to three years? And like the mission statement, this is something with your contributors in your community, you can sit down and have a conversation whether it's iterating on a document asynchronously, whether it's a series of meetings and come up with what you think your intermediate term goals are. From your goals, you'll have ideas as to what the resources are that you need to attain those goals and then you make a list of those resources. So these will vary by project. Every project is different. No project is the same. Sometimes we're asked, well, just give us a standard budget. Really isn't one because all of the goals are going to be different. So if you want to grow contributors, well, you should probably invest in training, hackathons, events. What about translation support? Let's put the documentation in other languages. If you want to have someone set up meetings to facilitate a large number of technical operations every week, okay, that's project support. If you want to enable deployments, you can invest in CICD, release infrastructure, marketing brand awareness campaigns. If you want to add features, you can invest in commission development. The list of possibilities is endless and it depends on what your intermediate term goals are. And then the step is what do you think these will cost? Let's come up with some ballpark estimates. It doesn't have to be perfect. These will sort of, some you'll be high, some you'll be low, but overall they'll sort of balance each other out. But you want to come up with an annual expense of what you think your goals will cost. And one thing I'll mention right now is you're starting a new form of collaboration right here. It's almost like you have a second open source project, except it's not open source. You're producing funding. It's an open funding project. But you can start having open meetings with the people that are interested in participating the same way. And you're collaborating now on your funding goals. And we'll talk about some case studies of projects that have done this very well recently. But you don't have to decide this in a vacuum. Part of the attractiveness to an organization that's thinking about funding your project is to participate in those architecture discussions as to what you think you need. All right. So return on investment considerations. Once you have the estimated cost what you think the project will need from an annual budget perspective and you look at your contributors and who's actively contributing, who has commercial dependencies on the project, you're going to have a feel for what the universe looks like of the number of members and number of organizations that can support your project. And then it's math. If you think you need $500,000 a year in aggregate you can back into and you think you have a universe of 10 members that feels like a $50,000 a year membership fee. So when you start talking to potential funding organizations you want to think about the return on investment metrics in the context of that $50,000 amount. And when you're doing that pitch what we always recommend is think of it as you're not just pitching the project to the individual that you're talking to. You are also pitching with them to the person in their back office because they're going to have to take your pitch and they're going to have to make the business case on their end and you want to make that really easy for them. So walk through the three drivers. New revenues, cost savings, solve problems. Think about what for any particular company and they're going to vary by project and they may vary by funding opportunity. Think about what what driver is motivating that company and have examples at hand as to how your project can address those particular requirements. Let's say you know that hypothetically a proprietary solution is resulting in $100,000 a year of training from an organization. Well, one of the great things about open source is everything's open source. There's lots of training manuals that are already there and perhaps the project has the opportunity for the potential funder of dramatically cutting that proprietary training spend and they can instead turn to differently priced open source training solutions. That should be part of the pitch as one example. So let's go through some of these particular factors to keep in mind by each of the three projects and then we'll go to some case studies and take some time for questions and wrap up. New revenues, so projects can allow companies to enter new markets. It can allow smaller companies or companies that are not incumbents in an area to gain competitive functionality. It can increase the footprint of a company's products and services and can let a company leverage the branding strength of an open community. So if you have a new entrance into an area people may not know that company but if they qualify for example for using a conformance mark and they can say powered by open daylight and everybody knows what a daylight is immediately they get some brand benefit from that. Alright, cost reduction. Open source lets you externalize your R&D. You get an entire community working together. There'll be components that you're not interested in. There'll be functionality that doesn't fit your particular market segment but that's okay because there'll be a lot of stuff that does. I already gave the simplify external training example but many companies will be providing support for projects. Oftentimes the support once it's funded by the project community itself through community funds and that will let companies refocus their investments on more proprietary R&D or the next project. And relying on open source projects and funding those it increases the interoperability of projects downstream and it also allows you to cut costs by crowdsourcing, bug control and fixing problems. Finally, there are problems that we can only solve as a group together. The common example here is in the case of security we are only as strong as the weakest link and so security solutions are something that we should approach together as a group. Alright, so to sum up what we've covered a successful open source ecosystem comes down to four core factors neutrality, open governance duocracy, financial support and IP clarity. We have the foundation for these four factors by telling people what you are doing making it easy for people to participate and integrating best practices and tooling. Make it easy for organizations to make commercial dependencies on your projects and consider their business cases and potential return on investment when you're pitching for funding. So that's the main overview on how to position a project sustainability. Want to do a couple really quick use cases and then we'll pause for questions. Yachto project which many of you are probably familiar with opensource project that helps embedded developers create custom Linux based systems regardless of the hardware architecture. Project architect is Richard Purdy and executive advisor is Kate Stewart. The project was formed in 2010 and it's a highly successful and sustainable project neutral and open governance IP clarity and is financially supported by members. It had a governance transition a couple of years ago to adopt an open governance model and we can see in its the growth in its contributor since then that that was successful. So here we have from 2013 project contributor growth very strong and continues momentum the shift to the open governance was in 2018 and looking at a couple other metrics again contributor strengths remains high and we can see a transition year from the number of organizations funding and then renewed growth in supporting members from that. Zephyr project another embedded project RTOS operating system really good documentation so here's another one here's the documentation site look right here getting started guide make it really easy to start contributing to the project they have a page on the website about all the products that are running Zephyr and as a result you can see how well they're scoring with total commits in a recent overall RTOS survey so case study number three very timely and we have Marcus here from the project Marcus again congratulations on the launch of Kamara Kamara is a project focused on leveraging telecom APIs it launched as an unfunded technical project in February 2022 it was a green field technical project so there were APIs that had been developed but the technical work had not started but under Marcus's direction the project community was laser focused on telling people what they did and making it easy to participate so this is the repo right here mission statement really simple right there project charter there's open governance right there code of conduct inclusive and welcoming community so they started with a couple companies that were interested Marcus you now have over 750 participants in the project with the mailing list that's double that so very strong growth and today they announced a funding effort with 15 organizations providing funding so that's the other case study here so that concludes the material we had to walk you through in terms of giving you some ideas this again is not an exhaustive list but some ideas on how you can make some decisions upfront and some early investment of time in some areas that can really position a project for future growth sustainability and success so thank you for coming today any questions I'll try not to move around now thank you for your presentation I'm Tatiana from Aminti Code and you mentioned that foundation is a good I would say legal form to to frame open source project but how about fairness how do you distribute this funding across multiple contributors and how do we decide how this funds will be allocated and who will decide can you elaborate on different models sure I don't know if I followed all parts of your question completely so let me start to answer and if I'm not answering exactly what you were asking let me know the way we structure funding projects is we don't want to be disruptive to the technical work we want the technical work to involve the smaller contributor and so one of the requirements that we have is technical contribution in our projects is open to anyone if there is a funding project you do not have to be a member or a funder of the funding project in order to participate technically you should be able to progress technical roles gain responsibilities in the technical project whether you're an individual developer or representing a smaller company and in fact most of our funding projects are set up so there is a mechanism so that the chair or leader of the technical group can have a voice on the budgetary board so again the setup is done to very much not be disruptive to how a technical project is operating so that smaller companies that may not have funding can still participate in ad value and receive value from participating in the project but if I didn't answer your question fully please let me know close enough, alright, thank you checking time I think we got about 5 minutes left if there are any other questions do you believe that the foundation model is the best solution for all open source projects or do you think there are certain types of projects where the foundation model isn't the best option for them there are hundreds of millions of projects and if you look at the universe of foundations they only serve a small a very small subset of those so I think there are numerous approaches I think the foundation model is very good at solving for IP neutrality for providing a home for projects for providing a home for trademarks and for resolving some of the open questions that exist in terms of efforts that we're seeing to take control of everything that doesn't necessarily mean it will work for every project again, hundreds of millions of projects but we find it a highly efficient model that has worked for our communities other questions in the back, Marcus so Scott, thanks for mentioning Kamara Hydro SX Ample and I can confirm all the points you have shown oh good one small point so you mentioned that companies can get a return of invest but the same happens also for the people every person who is working in the open source project nobody is working without getting anything back that means you have to be very respectful to the persons that's the basic thing respect each person if he provides a lot or only a few things respect him and then he has to know what's the overall goal so he knows the effort which I do is sensible that's the second thing and then give him an honour back for some person it's sufficient that they get oh I've done something very good it's good for me now I'm feeling good and it's done back to their company show look I have made my company visible it's visible there so they need to get something back and that is the only point which I want to add and you have to win the persons by heart for the project thank you Marcus I'm going to build that into my slides we got one more here if there is a way to spread this fund to lose individual individuals okay yes that can be done there are various approaches for that so we will have projects that are focused on external distributions in terms of commissioning work that's done we give a lot of flexibility to our projects to identify what their priorities are and for some projects their priority is to commission development and to engage maintainers and keep maintainers focused so recently launched half a year ago now but Rise project focused on enabling solutions in the RISC-5 architecture they are very much focused on that model so again in the development of the budget if part of the priority for the project community is funding individuals providing money back into the broader community that's absolutely something that can be budgeted and executed against follow up question oh you look like you have a follow up thank you any other questions alright thank you everybody for your attention have a good day and enjoy the rest of the conference thank you