 Welcome everybody and good afternoon and hopefully you've had an enjoyable open source summit virtual experience. Thank you for coming to this talk. I'm going to talk today about growing your open source project. To become an umbrella project and what that looks like and you know just kind of dig into that and really talk about it from the perspective of a project that I've worked with the open mainframe project that went through this process. So one of the things a lot of people don't realize sometimes about open source projects. Well, you know the real interesting and dynamic parts are certainly all the coding and you know the collaboration that's happening there. There's a lot of work to getting these done. A lot of that work is really the things that happen behind the scenes or the folks that that are really driving the technical decision making. You know they, they may not think about they might kind of find as, you know, a bit out of their scope a little bit out of their wheelhouse, but they're really critical as you scale up your project and when it's, you know, just you and a couple people it's one thing. When you're growing this larger, it becomes bigger. You know the first thing you start hitting in infrastructure of builds where this code's hosted pieces like that. You start to get into the legal aspects of it. You know how is the licensing handled how am I ensuring the code Providence is taken care of how the technical decisions start being made, and it just starts going on and on and on and sometimes a lot of communities almost feel like they're kind of caught in this process of operations piece, but these are really the important things this is what makes these large and even you know smaller than those sustainable open source projects really really work. Now, a lot of these practices you can almost bring from project to project a lot of times there's a lot of similarities there's a lot of interconnection. So this concept of an umbrella starts to emerge. So, imagine this here and this you'll have to deal with my crew drawing of an umbrella here. They have multiple projects that have a interrelation of one another, you know, either they're focusing on the same horizontal area. They're looking at the same vertical perspective. They have natural interconnections with one another, but ended up themselves are sort of driven one by one. They're driven individually is independent projects, all of those pieces of how a project runs from an operational standpoint. Often we see that can be shared with one another. And usually they kind of split into two different pieces. There's one that kind of works on, we call the funding governance. So this is the people that this is sort of the group that is looking at if how funds are managed or operations are managed how, you know, budget staffing allocation, all of these things often a lot of the non technical direction around trademark compliance and advocacy and pieces like that. And there's a split between that and the technical coordination which are not a lot of ways very different discipline. You know that technical coordination is the one of how do we how do we help bring these communities together how do we create a space that these projects can collaborate. How can we provide common infrastructure to get these projects successful so they're not spinning one on each other every single time. How do we put together a life cycle we'll talk about what that sort of looks like later. And this is sort of the area in which they try to focus on it's a very clear delimitation we put in here. You'll notice one is not above the other, they're on the same line, because they handle different pieces there. There's interdependencies, you know there's ways where they interface. There's no, there's not a reporting relationship here it's a peer relationship, and they often focus in different ways. So, what makes this model work really well. You have a big time you have one big tent that everything can fit into and with that everything that you do from an outreach perspective from a governance perspective from a budget and operations perspective. You can streamline because you can share a lot of these pieces across I mean even simple things if you're, you know, spinning up a shared build infrastructure, you know as opposed to having each community have their own individual ones, you have one everyone can use it. You can maybe make it a little bit more robust because of that, but the costs overall work a lot lower. And even as you're doing events, you know, such as this one here, you can do that in conjunction together you can, you know, speak together. You know, have co events that you're doing co content marketing, and you're able to get more avoid so as opposed to everyone trying to work on this individually, you work together. And you can talk to that larger audience more effectively. So that's kind of the whole background of why this umbrella model tends to work and we've seen a lot of success over the last two years here the Linux foundation with us. You know, both from a horizontal perspective so looking at like a cloud native computing foundation or an LF edge and LF energy CD foundation, but also from a vertical perspective. Academy software foundation is a great example of that that just looks at that entire VFX motion picture industry segment and the open source and that. So, how did we get here. Why did how did open mainframe project even exist like what is even the concept of why it's here. And you have to look back to look forward. So, if you go way back to 1955 share was established and for those of you aren't familiar share is a conference that was established amongst mainframe operators as a way for them to basically share practices share code. You know, share best practices share tips, maybe not the same way that we would do today they might be using sort of different mediums, but that's where it started in and you know for folks that know their open source history. You know we can point back to share in 1955 as where the historical root of open source started it wasn't called open source back then. But that's where it all started and we fast forward a few decades here to you know open source really taking root on the mainframe with Linux coming in major Linux distribution customers moving over and then projects coming over as well. And naturally when you start to get to that point where you hit that critical mass things become a little bit interesting. And this is often the times when we work with projects that we see they're kind of hitting a little bit of a glass ceiling. They have often vendors are doing the lead here. So, the events end up being very industry specific very vendor specific and there's no agnostic approach. You know enterprises have difficulty engaging with upstream project it's very one on one. There's a lot of effort just become very disconnected there's no natural way to share you see one off partnerships happening. But really the thing that we saw here is that open source needed a neutral home to get to that next level of growth. So, the open mainframe project was born here and really with these three principles, eliminating barriers demonstrating value of the mainframe on technical business levels and strengthening collaboration for the community to thrive. And I highlight this last one because I think this is a real, real critical one. And this was sort of the driver of why this project started to embrace the umbrella model. They knew that this was a unique opportunity to bring together this community, but they needed to create the space for it. So, this ecosystem had a number of challenges and we touched on a little bit of them of, you know, where it's hard to do open source and really where the challenges and the real hard work in here. But all of these things were coming very true. There was a lot of fragmentation there was a lot of cross pollination on the governance side with these projects. Many of them were spun up either by individual organizations, individuals out in the wild, all sorts of different ways. And there wasn't really a standard way for folks to engage. And even with that, a lot of these things were developed in a very specific product need, you know, versus sort of that larger ecosystem platform play. And, you know, again, as you keep going forward here, the assets need managed and all of these things get just very, very, they're impossible, but they're just a lot of work to do. And that glass feeling that we talked about hits in there. A great example of where we really saw this as an opportunity for open mainframe is project that came in open source summit two years ago called Zoe. And this was the real first, I would say major community project we had others ones that we were working on but this. This is really here this community started to do this at scale. And they had a large problem at hand. And I would spend a lot of time into the details you can read some of the slides here. But, you know, we've made a lot of great, great progress in here. And in a probably not the most ideal way, you know, the concept of building umbrella, we sort of ended up doing a little bit backwards because we saw the need of a large project coming in here. It needed to have sort of its own independence, but it needed the support of a foundation to be able to thrive. So we had to spend a lot of time in focusing on this. And the two things we did out of the gate very quickly was, what does it look like to be a project hosted here. So we needed to go through and put together services and value prop for projects that are coming into here. What do you get for being a project here what what should you expect what's the value that can be brought to the table for that. And then the second half and we'll dig into this a little bit more in the next slide here is a framework for projects to exist in. We refer to that here as a life cycle and the aim of a life cycle is to inset it to ensure that that's consistent quality and sustainability of projects. It doesn't necessarily get into the depths of whether the code is good or not, but it's really focused on is this is this a good writing project is this, you know, a project that has the sustainability to drive forward. And what, you know, if you're thinking about a life cycle and you know there's there's different models that we've seen of this or the Apache software foundation has something very similar. But, you know, for us it looks at a three stages where you have an incubation stage where projects are just coming in the door they're starting to figure themselves out. And really, the focus at that stage is getting your stuff together with my processes with my practice with my governance how do I get releases out the door. How do I decide on whether it can it goes in. You know, who decides that what does that look like what's the pieces there how can people contribute code, you know what are the expectations for a contributor do they need tests. Do they need to sign a CLA do they need to, you know, do something different to be CEO, you know, who's owning the copy know what license even depict. There's a lot of work to do in that stage there but it's an area where the project can just really sit and focus on that sustainability but then also starting to build up that committer base because as a project is moving to active. They need to be not only mature, but they need to be diverse and diverse means a lot of different things. I look at diverse, not only from what we might traditionally think of is, you know, gender, race, ethnicity background age, which I think are all real, real critical things for an open source project, but also vendors, you know, who are the people employed by if everybody's employed by one organization. And that organization decides, you know, we're not focusing this on anymore. Projects dead. If you have a few organizations focused on it and one pulls out. Kind of hard, but the project can still go on. And that's really the big ticker is when you move into active state you have that diversity ability. You have that sustainability that comes in there. And now you're able to turn your focus on how, how is the downstream usage, how is the adoption of this all coming together. You know, this is where you see training come through this is where you see conformance and certification programs come through. This is when you see sort of downstream ecosystems start being built. The activity really starts to get in there. And then, you know, open source projects, they don't last forever technologies necessarily sometimes aren't relevant forever. And as that comes, there needs to be a home for these assets because there are still going to be people using them out there. They can't just kind of go in the wild and being able to have a home for them is a real, real critical thing. And that's often referred to as emeritus where you have often seen the term addict come in there as well. So, as we started to assess how all this fits in here, one of the, one of the first things we needed to do is see, okay, what actual, we have this Zoe project. This is one that's driving it. And that's one set of use cases of what a project needs. What is the rest need? What is that broader scope need? And, you know, we said at the gate, this is a great area for bringing in the concept of the landscape and you might have seen these before we have a number of foundations and projects that use these. And really, it's a way to understand what that open source space looks like. It's a great internal facing tool for you as a foundation is attacked to be able to sort of wrap your head around what the open source project space looks like. But that's also a great external tool. You know, as you're talking to people about the foundation of projects you're working on, you can showcase how you fit into this larger picture. And it's just a great tool for doing that. So, our next challenge was, okay, we have this great project Zoe getting some traction. We're learning a lot of things. At the same time, we're really hitting some nice strides. And what we found very interesting here is you see Zoe was one of this first round of projects. In 12 months, we had six brand new projects, which for some other foundations that may not be that big of a deal. But if you look before here, we had three. So within the course of a year, we went from three to nine. And already in 2020, we're, you know, just barely through halfway of the year, we already have three and there's a few more that are in the pipe coming as well. So we have this influx that's starting to come in, and it's not unsustainable at all, but it makes you start to sit back and think, how can we make sure we're doing this well? How can we make sure that we're being, you know, not just fair to projects, but we're serving them adequately. We're serving them where they need to be. We're adding the right level of value and they're being able to step back as, you know, see, hey, this is a place where we fit in. This is a place that, you know, we see some natural affinity. So one of the first things we dug into there was that cross-community collaboration. And we know from open source projects that being able as a project to be able to collaborate with one another, sort of outside of maybe your immediate domain, but into your broader domain is just a huge value add. And sometimes it's really hard. Sometimes you don't know where all these projects actually are. You don't know who the leads are. You don't know what they're working on. You don't know, you know, where they're looking to go. And when you have an umbrella, all of a sudden you have that natural area of this to come together. I mean, it just, just from the visual standpoint, you have all these projects that are lined up one another. They're all deemed to be in the same space. And I use that sort of term loosely, you know, either the same horizontal technology space, the same vertical space, you know, the same, they're all naturally interrelated. But there's a lot that just needs to be facilitated there. And it's also getting some of these projects to be able to come out of that individual community bit and sort of look at the broader world around them. And that's something we actually noticed a lot with open mainframe as our Zoe project is spending a lot of time really working on building their ecosystem. They weren't seeing a lot of the other new projects that were coming in. And I remember a few months ago we actually had a webinar around a number of our projects and Zoe was one of them. And the biggest comment I heard, and this was especially from folks in the Zoe community is they sat back and said, Wow, this is pretty interesting other projects here like we, there's some areas where I think we align and we could benefit from one another and we could help use what they're working on or learn more from what they're working on or or something like that. That is sort of ends up being a real natural collaboration point and you know webinars are certainly that way that a lot of this is where this technical advisory committee has really came into play for us. That's where our projects have come together. They're able to share what's going on. They're able to share challenges. We had a tech meeting a few weeks ago with one of our projects in incubation that was struggling to get their community up and going. They were struggling to get engagement. They didn't really know what to do. And they in a half hour conversation with the tech, they walked away with a handful of ideas and two or three people that were willing to jump into that community and give them a hand and show them some expertise and show them what they're working on. And it's all of a sudden started to emerge a lot of that best practices of how these things work. Another thing that we did was have that every single project coming in has a sponsor from the tech. This is has sort of two benefits we've seen one is the tax sort of know something's coming. Because usually that tech members communicating with other tech members and you know they're able to talk about you know what's coming down the pipe. Two, since they're the people that approve projects coming in, they sort of know the context already of, is this a project that fits? Is this not? What does it need to address to make it fit? What are the areas it needs to stay out of? And it's also, you know, as a project is going through the proposal process, there's a lot it needs to learn. There's a lot of, you know, just questions that they've never been able to tackle. And having someone from the tech who has went through the approval and have seen these projects grow, they're able to add that guidance right away. So that's a huge, huge help. Another challenge. And we talked about this a little bit with the life cycle is how do we make sure that projects are, we're adding the right level of support for them. But here's sort of the wrinkle. Not all projects necessarily need the same level of support because sometimes it just doesn't make sense. And you talked about it, you know, we're looking at different stages here. A incubating process project is really focused on getting governance together, processes together, starting to get some people to start working in the community. You know, really trying to get their house in order and spending time on helping them build a training program and spending time on helping them build a downstream ecosystem. It's probably a lot for them. It's way too much for them. That's too many things to execute on once, especially when they're laser focused on how do I build a sustainable project going forward. So we did a couple of things here. And then if you look at an active stage project, they're at the point they have their community set, they got their processes in line. Now they're thinking of all those things. I need training programs. I need, I want to start doing events, you know, that specific I want to build ecosystem development platforms, all these sorts of things. So different levels of maturity at a different wrinkle into this as well. So a few of the things we started working on here, which has really worked out nice is, like I said, in the incubation process, when projects are in incubation, we focus on getting them through incubation. That's what they need. Getting the requirements of incubation done for our projects, you know, which is all of those things of governance, you know, committed diversity and all of those projects. All of those processes is all of that. They need that help. They're at that stage where they have code. They have an idea. They have some people that are early on wanting to involve. They need to get through incubation. They need to get all of those other pieces in order so they can be successful. And that's where the tax sponsor can come in. It can also help tie into other parts of the community. We've also found that we're creating these outreach opportunities as opposed to leaving it for the projects to figure out what's create opportunities for them to opt into. So, you know, things like we've done webinar series were invite projects and to have a part later this week. We're doing an hour and a half co location event that we're having a number of our projects present at. We try to make sure we get them included in the blog and we try to give them a structure of how that fits in there. Because again, a lot of these folks have never thought of like what larger outreach or an open source looks like. So that's a really big area to focus on. And then once people get once these projects get into that mature phase, that's the time then we're sitting we're partnering with them we're figuring out how do we help get that broad exposure. So the needs start to begin to change as you go through. So, I know this is a very, very high level overview on the whole concept of an umbrella. There's a lot more depth to it. There's a lot more nuances on it. A couple of things that if you're thinking about this right now that are maybe great ways to start to see if this is something that fits really well for you. You know, certainly I talk about the landscape is a great way just to understand is there a space for this is there actually an area where umbrella could serve. Working with related projects to start and especially ones that have common synergy with them is a huge value point there. And then thinking about what projects fit around in the life cycle perspective, and, you know, life cycles I've seen said a number of different areas, but they tend to have three really distinct phases that formation incubation figuring stuff out that mature, building ecosystem, building larger community stuff out and then that path of how they wind down at the end. So with that, I know we're right at time here. I'm definitely open for questions. I saw one has already came through here. One of them and I'll read it out loud here. The umbrella model is obviously good for vendors and corporate members who wish to commercialize the products under the umbrella as a single product, but is it just as good for the actual community itself. From our experience and from my experience, I actually would say yes. And I've seen this in a couple of different ways. One is is we've seen a lot of times that these projects are difficult sometimes to contribute to because the contribution guidelines, the IP guidelines, things of that nature. You know, they're, they're hard to work with and in the Academy Software Foundation, there's a number of projects that we've worked with there, where it was just really hard because of the ownership and where these projects live. It's really hard for people to contribute to it is really hard for people to use it. The idea of having an umbrella model, not only just brought awareness to what was going on it brought awareness to the projects themselves. But it also created a much more consistent experience for folks to be able to contribute to it. So the community has seen a huge, huge benefit there as well. The other thing that we've seen is when you have these umbrellas, it naturally helps build great opportunities to talk about these projects publicly. So, you know, we've seen a lot of our projects will do, you know, daytime events like one day events around all their umbrella projects, each of the projects have an opportunity to be a part of that. It talks about how these fit together. Imagine each of these projects trying to do it on their own, not just the coordination, but the cost. It would get, you know, just over it just makes it overly too complicated for a lot of these folks. And what we've seen here is by taking those, you know, sort of common needs and help bringing it together under, you know, one group to work with. Oftentimes they just benefit from one another. So you have these natural pieces that come up. But two, they're able to execute it on it so much easier because there's just so much overlap and so many of these activities that make it a ton easier. So hopefully that answers your question. I don't know if we have any other questions in the chat coming through. I don't think I see any. Awesome. Well, with that, I think I'm at the end of my time here. I want to thank everyone very much for attending here. Oh, wait a minute. I think I have another one that's coming through here. Speaking underneath the wire. So it seems these umbrella models make it easier for the economic portion of the project thrive, but you worry about the extra level of influence economics that it can take place in the community dynamic. You know, it's really interesting. So certainly there, you know, I think with anything influence is is a component you one has to sort of consider and any of these projects that all said, I really almost see the umbrella is just an extension of the already existing, you know, you know, duocracy that happens. You know, remember how we structure how have we seen these things structured successfully is there's a technical governance and leadership on one side and a, you know, business fiduciary on the other side. And the fiduciary is just really making sure that the what's put together here in the community, you know, they're able to provide the community with what they need to succeed. Is that infrastructure is that events is that, you know, dollars for staff, all of these things. That's what they sit and focus on so. And it's it's purposely separated from the technical governance because that really focuses on very hard and fast pieces. So, you know, is that duocracy? Are you stepping up to do the work? And then looking at it how it fits in a life cycle where projects have very clear guidelines that they have to hit to. So, I mean, I'm sure in this world, anything is possible. But what I have seen is keeping things in a very practical sense and a very pragmatic sense, which technical communities are really good at help separate this out. And really, we've seen most technical communities. They don't even have to deal with all of the fiduciary half of stuff. It's just there for them. And that's what and so they're able to focus on building great technology. So hopefully that answers your question. And I recognize we're over time right now. So I want to thank everyone for attending. And I will be in the Slack chat after this if you have any questions.