 So, what I'd like to share is what does it take to take all this energy and this positivity that we have today as a brand new project and how do we sustain it, how do we make sure that this project is here 10 years from now, 15 years from now, and that it's successful and it's a thriving community. And my name is Nithya Ruff, I'm a mother, a technology strategist for Comcast. I run the open source program office at Comcast. I consider myself a pragmatist and not a pure idealist on one side or the other and that's important in shaping my talk. I'm really passionate about the fact that companies should really work outside of their sphere to innovate and not just inside the company. Innovation comes from everywhere and open source in fact allows us to collaborate and innovate with people all over the world. I advocate for inclusion in technology in various forums. I sit on the board of the Linux Foundation and represent diversity. I consider myself a woman of color, she, her, that's the classification I go by. So let me get to my talk after introducing myself and Dave Luster, thank you so much for inviting me, it's fantastic to be here. So my question to all of you is, is organic growth of a project good for a project? And what I mean is, sometimes we think organic, natural, it's good, there's nothing added, it's not manipulated, it's not changed, it's not planned, it just grows by itself naturally and that's a good thing. I contend that for food maybe it is a good thing, right? Because on organic food for the most part, I think most of us will say organic food is a good thing. It's pure, it's clean, it's unadulterated, it's untouched and it's healthy. But I also contend that organic open source is yet another thing. And perhaps it's not so good to have organic open source. And what I mean by that is just letting open source kind of grow by itself, a project for example, without some amount of thought and care and intention. And many times we have very long held beliefs in open source that really hinder us from growing a project or sustaining a project successfully. We often get trapped by our own thinking and we tend to think if it's good it'll just grow by itself. So I'd like to kind of challenge some of those myths that we all believe in. Not all of you maybe, but some people do. And then kind of talk about what it really takes to be a successful project to sustain a successful project. So one of the myths that we all tend to sometimes subscribe is that if we build a good project they will come. That if we build a good project that people will discover it, people will flock to it, will start using it, and it starts kind of organically growing, and it becomes magical and it just grows. Perhaps it was true about 15, 20 years ago in the beginning days of open source when there were very, very few projects. And all of us have heard the famous story of Linus' email and the world kind of said, okay, we'll get involved in Linux and soon Linux became a big, big project. But it's not always the case. Today, for example, there are about 72 million repos just on GitHub. And then I haven't even looked into Sourceforge and GitLab and other places. So when you have this kind of paradox of choice and then there'll be hundreds of database projects alone, many different libraries for doing a certain thing. And you kind of then say, gosh, how the heck do we communicate to someone that we are here, especially as a brand new project? And how do we make sure that people get involved, whether it's users or as contributors or committers, etc. So what happens is today it no longer is sufficient to create a project and tell your friends and then it takes off. You have to create awareness. In fact, marketing has become quite a science now in open source. You've got to create a brand awareness for the project. You've got to tweet. You've got to have blogs. You've got to go speak at conferences. You've got to have, of course, a logo. And you've got to have stickers and all of that good stuff. And that's what it takes these days to go out and actually create awareness for your project. The second thing one often hears is that open source is quite different. Planning is for companies. Planning is for commercial projects. Open source needs to be natural and organic and goodness. And sometimes we tend to think that it doesn't need the kind of intention or planning that projects in the company and commercial space do. The key questions though, that you would ask in open source and in commercial projects is often the same. Every project needs to have a goal. Every project needs to ask why do we exist? What problem are we solving? Who cares about this particular problem? And how do we then reach that target audience? And how do we welcome this target audience? And you also need to ask a bunch of other questions. What kind of license do we use? Because what kind of behavior are we looking for from our contributors and from our developers that want to get engaged in this program? Do we want to CLA or not? What kind of legal documents do we need for this project? And very often in the early days of open source, many developers were quite well worst in licenses and licensing information. But today, we often don't spend time learning about licenses or what the intent of each license is and what kind of behaviors it can create. If I use a GPL, what happens? If I use an Apache 2, what happens? What do I want? Do I want corporate developers getting involved? Or do I want contributions back into the project? They don't want contributions to be hidden away by people who make the changes. So you've got to think through some of this before you launch a project. And you also have a choice these days. In the early days of open source, projects were often standalone. And today, you have the benefit of foundations. You have the Apache Foundation. You have the Eclipse Foundation. You have the Software Freedom Conservancy. You have the Linux Foundation. You have multiple homes for these projects to be housed in. And projects in the foundations often get an umbrella of benefits, whether it's legal advice or business development or marketing or events. Or other kinds of support and sustenance. And more importantly, it gets a neutral home. For instance, when I look at some of the projects that we've created at Comcast, there are pros and cons to hosting it ourselves at the Comcast GitHub IO. And then sometimes it makes a lot more sense for us to host it at the Apache Foundation or the Linux Foundation. And we've often done that because we wanted to provide a neutral home. We wanted to make it grow differently. And sometimes a single company glow may not be beneficial for the project itself. The third myth that I often come across is good coders will figure things out. You don't need any onboarding. You don't need any documentation. You don't need any help. And this used to happen particularly in the embedded space. I used to be in the embedded space. I worked in the Octo project. And the Octo is a distribution builder that allows people to build their own custom distributions. And we often used to say, hey, if he's not smart enough, or if she's not smart enough to figure this out, then they don't deserve to be in the project. And they don't need any documentation. They can figure this out. And maybe it was right in those days when the pool of developers was very little. But today you find that there are a couple of different reasons why you need to make sure that you have good onboarding, good documentation, good structure for the project. One, you often find that 75% of projects on GitHub have one or less maintainers. And often these maintainers are bearing the burden of the entire project. And they're often burning out. And they have no help. And they have no support. And if they choose to leave, or God forbid, you think about the bus problem, right, if they get hit by a bus, then what do you do? And you do need to make sure that you have succession planning. And you have at least different roles in the project. And you have people working on maintaining the project beyond the main maintainer or the main person who started the project. So that's one very, very big reason why you need to create documentation, create structure, create standardization of what's happening in the project. The second is a lot of new industries are coming into open source these days. Finance, healthcare, even us from a media and entertainment perspective, we have recent entrance into open source. And in the last 10, 15 years. So you find that a lot of new people and then new college students coming out. Also, I find that a lot of us, if you are underrepresented in open source in the past and you're now entering open source, you struggle to get through a project because some projects are just not documented well. They're just not welcoming. And if we are to grow open source and if we are to sustain open source and if we are to continue to have people enter this business and this culture that we've created, we do need to make sure that it's easy and welcoming and it's well documented. The next myth that I often hear and this is happening a lot, which is open source is not necessarily the right place for me to solve security, reliability, and scalability issues. It'll be done by the user when they start using it. They'll do the testing, they'll do the patching and they'll work and make sure that it's scalable in their organization. And very often we kind of say it's only necessary for us to work on the functionality and then the users can worry about all of these things. But it's not necessarily true anymore. You find that as we use open source more broadly, we need to really build in more security into open source and best practices around reliability and scale up front and cannot be an afterthought. In fact, some projects have been born in data centers such as Facebook's data center or Comcast or say Google's and then released into the open. And they come with some of those prerequisites built in because they've been tested and tried in the data centers of those organizations. So it really is important that organizations, especially projects, take on some of this work up front rather than leaving it for users to do. And you find that foundations like the Linux Foundation, for example, has started projects like the core infrastructure initiative whose job it is to create best practices for security and also to review security practices for projects that are under their umbrella. And to help them to create better practices. And they also do badging, they do reviews of your practices, etc. So there is help there for projects to build this into their projects. This one is often also cited that open source is really about people who are serious about solving a problem. It's about passion, it's about enthusiasm. And that if you build too much structure, too much process, too much planning that it kills it. And that open source to grow should be left alone. On the other hand, some of the successful projects have seen, including the conference Namesake, which is Kubernetes, really was created with a lot of structure and planning in mind. Including different groups, subgroups, and the community, and how the communication will take place. And how it will scale, and how planning happens, how commercial companies will use it, and then mirror in open source or vice versa, etc. And so when you have structure, it actually allows for more improvisation. It allows for more experimentation because some things are codified, some things are documented, some things are well understood. And so you can actually play with it, change it, modify it, and keep moving it forward as needed. Good projects live forever. And this is something that I've heard also, or we don't even remember that projects have a life cycle and projects have a certain amount of time that they live or they need some intervention in between. And we just kind of give birth to the project and then just think that it'll grow and it'll keep moving forward. And what I find is that projects actually go through a life cycle. There's a launch period where you have to do a great deal of awareness, building, perhaps a lot of course correction, adjustment. You're putting some initial components in place, governance, etc. And then it goes through a commercialization period where perhaps companies are using it, companies are basing the commercial products upon it. There's a commercial ecosystem that's developing around it. It becomes a much more thriving community. And this is often one of the peaks where the project is extremely popular. And then it starts going down in terms of it has reached everywhere it needs to reach and it's gotten a lot of traction. And it's more in the sustaining and the maintaining mode. And the kind of activities during the sustaining and maintaining mode are quite different than you would do during commercialization or launch. You probably reduce your marketing. You're probably doing more case studies. You're probably doing more to kind of continue the momentum of this project and things of that nature. And then there's the sunset mode where you actually put the project to bed. Because perhaps there's a newer and better project that's come into being. But you still need to worry about all of the users who are dependent upon the project. How do I make sure that they can still continue to use it but that we are not spending so much time and money maintaining this project because it now is self-sustaining. And it just needs minimal support and work. What you learn from this really, what I have learned at least is that project sustainability really requires intent. And it also requires goals. It requires constant monitoring of where you are and which phase of the project. And what you need to do to make it go successfully or you need to provide the right level of support for the right phase of the project. So I know I'm going much faster than I expected, Dave. So I'll give you guys some time back. It's really intention and planning that's needed in order to sustain and grow open source. It's not just beliefs. It's not just give birth to it and then it'll just grow by itself. We do need to market a project. You cannot just let it sit on a GitHub in among 72 million repos. You need to have a strategy. You need to understand what the goal of the project is, who it needs to reach, how it needs to reach them. Whether it's a small project or it's meant to be ubiquitous and reach as many people as possible, the kinds of users it needs to reach. We do need to worry about culture, everything from how we onboard people, how we make the project more inviting, more inclusive, to how we communicate, how we are transparent in the project, to who takes care of the project, what the succession plan for the project is. And the culture becomes extremely important and best practices. There are a lot of best practices for scalability, reliability, and security. And we need to adopt those as a project. You don't need to invent everything yourself. You don't need to create everything yourself. But you do need to follow those practices. And frankly, if you have a good structure of the main core elements of the project, then it becomes easier to improvise. It becomes easier to transition the project to other maintainers and developers. And it also allows us to sustain the project if we have a good plan in place for the various phases of a project. When I look at FoundationDB, and I just did a very quick look at FoundationDB, I find that you guys have put a really fantastic plan in place. And there is a real commitment to community over code. And I think that's really terrific because at the end of the day, a project is made up of people. And people are the ones who create code. And people are the ones who create innovation. And if we take care of the people, then good code follows. And I think that's a great practice that the Apache Foundation speaks very passionately about. And I'm a big believer in that. I love the fact that you guys have a great code of conduct. And code of conduct is not to discourage people, but it's mainly to say, this is how we'll conduct ourselves as a team. This is we will be very respectful of each other. And we will be inclusive of people in this project. And this kind of a summit where people can come face to face and talk to each other, develop relationships is so, so important. Because we often are working remotely. We are often working on email. And so I find that when I come to one of these events and I have a relationship that's built on meeting the person, looking at them eye to eye or having a meal together, it's often so much easier to get work done remotely than if I never knew the person and I just had to deal with them remotely all the time. I love the fact that there are so many communication forums and it's transparent and it's laid out nicely. And you've provided for structure. You've provided for tools. You've provided for ways for teams to engage on the foundation level as well as the add-on levels. I like the fact that it's in a neutral home. And while, yes, Apple is the big benefactor behind the project, it's nice to know that it'll be sustained and it's ongoing and that everyone can get involved in the project. And I think you guys chose to do a light governance to begin with, which makes sense. Because you're saying, I don't know which way it'll go and what else we need to put in place. So we'll start with a light governance and then we'll add and change as needed as we move forward. And being on GitHub and providing some of the tools and some of the other documentation, the onboarding guide, et cetera, is fantastic. So I thought that you guys have already put a lot of great elements in place to create a sustaining and a successful project. And just to kind of end the talk, if you want to look at some of the projects that we've put together, it's at comcast.github.io. We've hosted some there and some we've kind of donated to Apache and then some sit outside of the company again to kind of see where is the best home for the project and you can see what we're doing from an open source perspective at that place. And those are some of the attributions and I hope I've given you some of my thoughts around why some of the organic mechanisms that we often believe in or some of the beliefs that we have are not always the right ones and that we need to actually do planning, actually understand goals, actually understand intention when we want to create a successful project. Thank you.