 Hi, everyone. So we'll get started. Thanks. Thanks for joining. I think for this particular topic, actually 30 minutes isn't enough. So I'm going to just give you a whirlwind introduction to kind of things you should think about when you're launching a new open source project, which kind of getting things going. So with that, just a little introduction on myself. My name is Trishande Landrull. I'm with the Linux Foundation been there now six years. I run some of their networking projects with a particular focus in data plan acceleration, open radio access networks and stuff like that in that space. And I've helped kick off several projects of the LF, not just in networking, but even in some of the statistics languages. And when I first joined actually helped launch the open source uov program as well there. You know, how are we going to spend the next 25 to 30 minutes here since it's a smaller crowd. So we could feel free to interject with any questions and keep it interactive. So we're going to dive in, give you a quick intro. I think you heard from Gabriel this morning about sort of the importance of open source from a corporate strategic perspective. So I'm going to skim over that a little bit. And then we'll kind of go into some of the considerations that you might want to take into account as you build your as you decide doing and contribute to an open source project, or if you're going to start a new open source project, bring a project to a nonprofit like Phoenix or the Linux Foundation, and then kind of interject that with some good best practices that you should take into account here as well. With that, the the old, I think the field of dreams movie reference, you build it, they will come to go through your open source program on a GitHub and expect to build a community around it. Probably not. It's not going to work that way. You just be lost in the forest there, and you got millions of projects up on GitHub. So the key to these, the building an open source sustainable open source project is to build sort of that ecosystem and a community around it. So the projects like the Linux kernel, when they got going, we had it takes more than just throwing the source code as you know, it is you need to build a sustainable ecosystem around it. You so you build a community of developers that can contribute to the project. You have products and solutions that are built on it. Kind of test that if you see around here, some of the companies here working on Venus based projects, and then you continually improve on that code base with bug fixes and security updates and things like that as well. For the enterprise is in this notes keynote. We mentioned it's now it's it's actually in for your business strategy. You kind of take into account open source and build out open source projects within it. And as I said, everyone kind of takes it and lip service or we're going to build an open source project. But what does that really mean? And when you're looking at it from a strategic perspective, you kind of look at it the high value is you're trying to increase your market opportunity while kind of building an ecosystem and products, you're decreasing your costs by collaborating on the development, reducing your risk in that sense to because now you have to invest less to build your project and product around it. And by collaborating and building and building that ecosystem, you are in turn sort of building the de facto standard that people would then base their solutions on case in point if you look at Kubernetes and the container space that becomes like the one that everyone is going and building on if you want to do containers. And as I mentioned, the project is just the first step. You get the to build that project. You kind of go in a cycle. So you go into products, deployments, eventually you get to profits. It takes sometimes a couple years to build. So you won't have a successful open source project in year one. You might be collaborating. You take phenos, for example, it's grown over the last several years, three to four years that it's taken it to get to this stage. And it's still continually growing. And then you build the developer community around the program as well. So what does it take to build a successful ecosystem? Basically, you could think of it break it down into four key areas. Neutrality, having that forum to collaborate and work together. The open governance model clearly laid out charter rules, set of ground rules that you can play by clarity around IP ownership. That's the licensing for the software who's contributed what and how you can use it. And then building out that ecosystem, which is to engage, kind of encourage commercial engagement in the project and building it to recruiting channels and opening it up to recruiting channels, adoption and improving contributions in terms of features and new developers and contributors and use cases as you build out the applications to have a successful open source ecosystem requires a lot of resources. It's as I said, it's at the beginning here. It's not just throwing your source code up on GitHub. This event is a good example of that getting as an opportunity to get the community together and work legal. You're looking at license scanning your software, any issues that might come up as you're working through it and governance questions, training programs, certification programs, the phoenix just announced their training just yesterday, I think testing, certification, compliance programs around your pro software as you build that out. And you won't have an ecosystem if you don't engage with your developers and listen to them. So you want to have avenues and channels to bring in contributors, companies, engineers to come in and work on your projects and they need a place to work. So you need to have the CICD infrastructure in place and what does that look like as you kick things off as well as then considering security. These days, security is a big consideration on how do you address security vulnerabilities and issues quickly? How do people report them in? And then how do you do like software below materials around your program as well and then manage on that supply chain side of things, which has become a critical factor these days as well. So let's look at going forward. Let's break down spend the next couple minutes kind of looking at the different areas and we'll break it down. So we're going to start with sort of the governance. What are the policies that you might want to take into consideration as you build your program or decide to contribute to a project? If you're contributing to a project, you should take a look at their project's charter, see how well documented it is, how will they good documentation around it? What's their process? What are the rules of the road, so to speak? And then the development process, lifecycle, release process, what sort of infrastructure is in place for that and an ecosystem and intellectual property. So let's dive in. I know we're going to go in quickly. So we'll go through this far quickly. And then my slides are available on schedule. You're welcome to download these. And there'll be like little checklist that you can then use. So what is this governance model look like for a well run open source project? This is an example of a smaller scale project, which has a governing board, which is responsible for the sort of strategy and finances around the project. A technical steering committee is given a car blanch on the technical direction of the project. And they work on the technical and you have technical steering committee members, they could be from the governing board. But eventually it becomes a meritocratic process, where the engineers that are in the developers that are serving on the TSC come up based on their merits and the contributions that they made to the project. And then within that you might have working groups for marketing events, finance, and then if you have a compliance program, you can build that out with with your community labs and open labs that you might set up. And then if you want to look so this is just as a simple example of a governance. But let's take a look at the what a umbrella project might look like. So this is a larger scale project which has large sub projects underneath it. And we have multiple technical steering committees that would then report up to sort of a technical advisory council. And then you'll have a broader marketing advisory council to develop your marketing programs. You're looking at cross project collaborations, convergence infrastructure that might work across different projects. And then large scale developer testing forums and events that you might have. And then as you build your program out and mature it and you get more end users, you start an end user advisory committee group to look at new use cases and and future look kind of a forward looking group. And then as you also have the governing boards, they are working on their budget. And then the the TSC is again, they're managing the technical direction of the particular projects. Feel free to jump in with any questions. Oh, these are just this is an example from LF networking. And these are some of the project names. ODL is open daylight. So what should you consider when you're looking at the governance on a project? So this, as you said, sets the ground rules. First off, what's your mission scope for your project that you're building, the guiding body or guiding principles for your committee, what brings your community together on that. And that's what you might want to have that laid out upfront. The composition for your technical steering committee, your governance structure, the responsibilities you lay out your voting structure, your intellectual property, your IP licensing, you know, is your software that you're releasing on Apache, BSD, GPL, what what see your contributor, do you use a DCO developer contributor agreement or do you use a CLA a contributor license agreement format? And you define your technical community roles, your committers, contributors, reviewers, and how you might how they might contribute to the project. And then you have a life cycle. How do you take a project, a new project that maybe comes in if you're an umbrella from an incubator and stage to a sunset stage, like what stage is a project look like it's reached sunset? And, and then where would you allocate resources? And importantly, it's also good to have a code of conduct as folks here who signed up for this event to this event itself as a code of conduct. So you want to have a good code of conduct that you can refer back to you for your community and there are plenty of examples of good code of conducts online for open source projects. Okay. Yeah. Oh, the DCO is sort of a developer contributor. That's an agreement agreement that people sign off on when they're contributing code to sign off line that you put into your get commits. Now you kind of take in, okay, I'm planning this new project. I've got some funds. How do I spend it? And it's important to know how to allocate your funding. And so these are some of the financial considerations that you would want to take into account. As I said, the intellectual property, as you're building your brand for your open source project, you would take into account your trademark, your the licensing export compliance rules. If you need to do explode compliance, license scanning. Do you have a leadership team that you want to build out? Do you have someone? Do you have a marketing communications PR person? Do you have an executive director if you were a standalone organization, program managers and leads? And how much do you want to spend on events like this event for developer get this to simple events to meetups? It should just be as simple as pizza boxes and company sponsored space that folks can work in or in this day and age virtual zoom meetups and webinars. And then as your project grows, you should start thinking about certification programs. What does it mean to be say powered by your project or be running on it compliance programs, training, documentation and then a big chunk of usually a big chunk of the budget kind of goes for it and infrastructure costs. That is when you have build servers and stuff. I'll kind of follow up on that here. And then the other area that you might want to consider that people forget is up streaming and cross project collaborations. So are you working with the stand? Were you implementing a standard? How do you work with that standards body? Are you pulling in source code from a dependency and open source dependency that you're using? How do you collaborate with that open source dependency? Are you fixing a bug that comes in? Are you forking it and then working on it in your own project? Or can you kind of upstream that back to the project? So if you need to budget for it, it's good to kind of have that front and center as well. So as I said, now you've got your mission scope. You've got your project idea. You've started to pull your code together here and you're getting ready to work on your project. So how do you get your code prepared? So in an ideal state, you want your license. Make sure it's a OSI compliant open source license approved license for your project. It's got the commission, the permissions you know you've laid it out. You've got a license file in your source code and you've got SPDX license tags as well, you know, in your files so that when you do a license scan, you can find all your files that are in compliance or not. And I've seen a few projects where we've got, oh, here's a big contribution. Recently we got a new contribution for a project and the folks that submitted it, it was had no license files in it. So we had to hold the contribution back and say, okay, you need to go back and put the license information in. And so we can actually kind of clean that up before it is accepted. Documentation, as I said, the SPDX, tagging the code correctly. And then it's so that those are machine readable tags for your licensing. Put the right copyright notices in on the document and the website. And then finally you can run license scans on your code to kind of catch those any issues around that as well. And Phosology is one of the tools that is available that you can use as a sort of a first pass. And the DCO, this is the one I was mentioning, is the Developer Certificate of Origin, which it kind of captures provenance at time of submitting the code. It's just a little sign off statement that's is signed off by name at an email. And it's enforced, particularly in you can enforce it in Git, Garrett, and GitHub environments in the Git lab as well. And as you're going through, we have the CII, which is the Co-Infrastructure Initiative, has this badging program. And I encourage if you're working on an open source project is to pull up the CII criteria, which gives you a large checklist of things and best practices that will let you kind of see at a glance, like, are you really following these best practices? And it's good to kind of check them off as you go. And it gives you like a sanity check. And we've encouraged for our projects, we've encouraged them to all apply for and get a CII badge so that you can say, okay, you know, you're doing the documentation correctly, you've got security response processes in place, you've got good commit practices and stuff like that. Speaking of security, that's your security disclosure procedures. This could be as simple as having a private mailing list for a subgroup that'll focus on getting any security reports that come in and then taking action on those to writing up a CVE case and publishing that as well out there. So just have that process in mind and from the good goal. So development infrastructure, when you're considering the development side of things, as I mentioned earlier, kind of consider upstreaming first because say you have a dependency and there's a security vulnerability that is identified in a dependency. Now, what's your process to bring that back into your project? If you found an issue in an upstream project, did you contribute it back to them to address it so that it doesn't replicate when you go to a new version of the software? So consider working upstream with with that project community. Allow your maintenance and then the code, your contributions, you become more of an active participant out in the ecosystem with your changes that you can you kind of become a good citizen that way as well, building that relationship with the other communities. And in a selfish way, it takes the onerous off of your plate to maintain it by pushing it back up to the upstream project that you're using as a dependency as well. And then you kind of also build some skills working on these different projects. The this is just an example of what a sort of a typical CICD model for a workflow might look like as you come in as a contributor on a project, you your codes up there on GitHub or Git, you sign your DCO, you submit a patch. We have build servers that might build it do the dependency tree and build it up. And then you have a code verification, you have the reviewers that plus two, meaning they'll that be two people reviewing, they'll approve it. And then the code gets accepted into your source code management system. And then you merge it and then you might have a build artifact for a release that you might push out as well. And these are just some of the tools that that we use on one of my projects as an example. For those who are submitting patches and submitting code, some good ideas. And this is a bit of an eye chat. But it's basic. Just a bit is make sure you've documented your code. You've got good and you put a git commit, you really clearly say what you're committing and why you're committing it. If it's addressing an issue that's in your issue tracker, you tag it. And if there were any comments, you address those things as well. Usually, and you should rebase it to the head of your code, and then submit the code as well. And then general good coding practices. If you are programming, just make sure you've sectioned off alphabetized your import statements, your functions organized. Make sure you have your tests for the software that that's a key criteria when you when you accept anything that's submitted to your project. And then do you have the documentation? And then do you you know, have you passed sort of linting, which is verifying the quality of the code that's being submitted as well. And then if you have any backward compatibilities, you kind of take that into account. So as you do this within your project, and you're building a project, we mentioned the stages. You kind of start either as a user or an adopter as a project or you come on and then you've got or a contributor, then you become a trusted committer with access with keys to the get Garrett repo, you become a reviewer. And then eventually you might be one of the main maintenance of the project. So you kind of earn your trust by contributing to the project as well. Now you have the code, you have your budget, your finances, and then you want to really start working on getting to know your community and building out the the community, get to know who you're part working with. One key here is, you know, you really want to listen to the community and the contributors. And even if you have some ideas of how you want to run your project, you might you still want to have that forum in place that you can listen to people and collect the feedback. So some do's and don'ts on this. Get to know your folks, subscribe, have the communication channels like your mailing lists and your IRC channels or Slack these days, zoom meetings, weekly community meetings, ask questions, listen, and then offer to help. And actually usually don't forget to read the manual. And then as and just assume you always better just always kind of take into account what others think and and then it goes without saying don't be an a hole in the community. The other piece of it is when you're out there doing these projects, contributing or trying to build a new project, don't drop like huge patches and expect them to get integrated into a project. You want to piecemeal it, have it in smaller pieces, make it easier to digest and don't do drive by coding. You know, you might be encouraged or have this module. I think this will work here without talking to the community and asking for feedback and then just coming and dumping a million lines of code into a project there. Folks in the community will not be happy with you. So bring it in pieces, encourage, get started dialogue, get a conversation going, get buy in and then you can start contributing to the project. And sort of also keep in mind when you're building, working on a project or a community, keep it, keep the whole picture in mind and see what the direction going back to the mission and vision of the project and seeing how your contributions might fit into that broader scoping as well. As you build your project, these are some areas and this is an example from an existing project. Things you might want to get started and have as communication channels within your community of engineers. Your technical steering committee weekly calls, having your mailing lists, doing plug fests or hack fests with the community, contributing to documentation, encouraging contributions on that front, having end user advisory group for end users to engage who are not necessarily contributing code, have a clear path for submitting bugs and issues. And then if as your project goes, you might have little user groups in different parts of the world and different time zones to work in. One of my projects we ended up without even realizing we ended up with a Japanese localization group that was working on a Japanese language version in and they were contributing that back. Define the compliance, as I said, the test cases and then review and submit your codes there. Don't forget to market and promote your project because you might have the world's best software that does something but nobody knows about it, nobody will care. So you need to build out some thought leadership around your project. Figure out how you can get the news out, press releases, social media communication, having proof of concepts, demos that you can push out there at events like this or other expos and then have use cases, white papers that you can publish on the front and then speaking opportunities to talk and share your project and get folks involved. And yeah, sort of finally, I mean, as we wrap up, open source is a team sport. So when you get working with the community, kind of keep that in mind, listen, collect feedback and then kind of collectively move forward with with the community and the project. Just as a summary wrap up, if you're kicking off a new project, as we mentioned, get your internal alignment, prepare the code base and the assets and get that out and then really work on concentrate on the building the ecosystem part of it. And don't forget the marketing and promotion security aspects of your project as well. Some resources for those who are looking for best practices. The to do group shares for especially if you have an open source office, there are some they have best practices and documentation and guides at the to do group. And then around community building, there's the people powered from John O'Bacon. It's an old school book, but it is a physical book that you can flip through that you can use. And it's an ebook too. Yeah, and I'll just leave you with this. As I mentioned, you have your source code and you're building it. And then you kind of have that neutral governance that you're putting it in. And then you build a virtuous cycle with your project and neutral governance bug fixes, community development and then your products. With that, just a quick acknowledgement to the team that helped me with some of the slides here. And questions. And you can feel free to each email me directly if you have follow up questions on this as well. So I know I'm standing here between you and lunch. Yes, I uploaded it on sketch. So the slides on on there already. It's equivalent, but it depends on the license that you're enforcing as well. So for example, you have Apache licenses which have that. So I'm going to prefix this. I'm not a lawyer with the but you have the Apache license that has a CLA template for it that you can use the CLA because of the way it has the patent grants in the license. And then you have things like BSD licenses which don't really use a CLA. They use just the DCO for how they approach it. So it really depends on what license the software is released under and then which mechanism is easier from a use case, use perspective. The DCO is a simple process and there are other projects that actually cover and have both. So you sign a CLA once and you put that in the system and then every commit comes with the DCO sign off as well. So the CLA is just a one time sometimes a one time thing and you can manage it as well. Now you should have something on the sign off. So it makes it easier to trace back the contributions and stuff. It's more for the contribution side. Great. I think I'm on time. Thank you everyone.