 Thank you very much for joining me with this presentation. We're going to be examining different project ecosystems from a variety of perspectives. To begin with, a little bit about me, I've got about 20 years in open source. I started with the Linux project back in the early 2000s. I've had teams work in Apache, Eclipse, OpenStack, and GNOME. As part of the Linux foundation, I helped to manage the Open Daylight project, as well as ONAP and ORAN. And now working for Ericsson, I participate significantly in the Kubernetes ecosystem and CNCF, as well as Apache Geode. One of the things that I've learned over this time is that each community has a very unique and different culture. And that culture is actually very, very critical to the success of the project. And so I want to spend this time with you today really talking about culture, how cultures are established in communities, how they bring success or frustration to different participants within different communities and so forth. Let me also state that these opinions are my own, and they don't necessarily reflect the opinions of either my past, present, or future employers. So what do we mean when we talk about culture? And culture is really defined as encompassing the values and behaviors that contribute to the unique social and sociological environment of an organization. And we know that over the last 20 years, corporate culture has been recognized as important and has been studied. And I guess I make the argument that the community cultures that are created out of these collaborations across different organizations is also a very important factor. When we look at the foundations of a culture for an open-source project, it really begins with a level playing field. And by that, I mean that simply anybody that's willing to come participate in a community and bring resources to do that is able to actually reap the benefits of their efforts and satisfy their objectives for why they've joined that project or that community. One of the tenets of that is transparency. So everybody has the equal say. You can actually go in and see what discussions and what decisions are happening. It's all public. It's all open. And the leaders, even if leaders do have some level of additional control because they started a project, it's still fair for everybody who's participating. And that's visible. Diversity as a foundational rule for culture is also important. And that's both diversity with regard to the technology as well as diversity in the different organizations or even industries that may participate in a given project. And this really all just leads to trust. Trust is really the essence of collaboration and working together within a community to succeed. So because this is so much behavioral and social in nature, what I'm doing here is actually I've provided a series of skits that kind of walk through different interactions within a community. So I will warn you ahead of time that my video editing skills certainly can use improvement. And I'm not able to hire professional actors, so I have amateurs. And in this illustrative example, we have an internal project called Hagfish that is being open sourced as Project XX. The founding organization is a firm utilizing business aligned resources, or FUBAR for short. And a willing participant wanting to engage in this community is the firm ready to initiate engaged non-privileged development or friend. So let's go ahead and begin this story by the initial launch of the project. This is great. After months and months of painstaking work, our proprietary Hagfish widget is about to go out as open sourced. So true, but please remember, we need to call it Project XX from now on. Of course, Project XX. But regardless, the world's going to be a much better place once the industry rallies around this awesome new technology we've created here at FUBAR. Hagfish is going to be the next big thing in our industry. Yeah, I'm excited too. The team's been cleaning up the code, removing incorrect and inappropriate language, deleting all references to any internal secrets, and any mentions of Hagfish from the Project XX code base. I've spent about four months lobbying my industry peers to join this development. I can't wait to announce Hagfish at the next big industry event, Project XX. Of course, Project XX. After the splash announcement, I'll follow up at all of the industry conferences. And we can let everybody know that the Project XX community is open for business. All right, so we're getting off to a good start here. Recognize that in many of these projects, including the Eclipse Project, OpenStack, certainly the Linux Foundation networking projects, they all started with a significant code base. And just to get that code out the door is a significant effort for those that are creating and founding these projects. Often they need to gain internal approval for intellectual property reasons and so forth. They need to clean up the code, remove any secret names or any code names for projects from inside the company. They typically need to find a neutral home so that they can build a community and have other collaborators come. They have to search out those collaborators and so forth. So it's a great deal of effort. And really, the types of projects that I have worked with in my professional career are all of the type that are really industry impactful. Certainly Linux has been throughout its nearly 30-year history OpenStack with enterprise virtualization. The Linux Foundation networking projects really focusing on an evolution of telecom for 5G. So they all take significant code base and they are all done for the purpose of creating some significant industry impact through some collaborative effort for some common platform software. So building out a community is required to be able to have that kind of industry impact. So recognizing that building that community is one of the goals is clearly part of this activity. So we're gonna move on with the story now and watch the developers during a conference. So everyone in the world might be interested in Project Double X. And we at the Fubar company wanna make this available to the world because we know you guys are gonna find it as valuable as we do. We encourage you to join us. We encourage you to participate in the project and it can help team you helping us to improve the technology. So what did you say? You know, we were considering some thought we're very, very similar to this earlier and we were gonna develop on our own. So it would make a lot of sense to collaborate and help you develop this technology a little bit further. There's a couple of features that we were very interested in some new cool innovations that aren't in your project just yet. So we'd like to maybe bring some of those forward. That sounds great. Look forward to it. Okay. Cool. All right, we seem to be off to a good start. It's worth mentioning that one of the foundational characteristics and the beginning of the setting of a culture inside of a project is what the onboarding looks like. So the ability and ease with which new contributors can actually engage in the project. And for new projects, it is certainly the case that promoting it at various events is very important. But right after that is going to be the need for sufficient low-level documentation because that's always the next step for developers. And it is the case that the more feature rich and complex the software, the more explanation is often needed. Now in this example, let's suppose that the project XX is roughly four million lines of code. So there's an awful lot to teach. And certainly putting that code up on GitHub is really just the beginning of the journey. So as we continue our story now, from that encounter at the developer conference, developers from the Friend Corporation are now interested in actually contributing something into the XX project. Hey, Fubar developer. I've had a chance to take a look at the code. Boy, there's a lot of complexity in there. And it looked like some of the modules were overloaded with a variety of functions. I'd like to figure out how to best add feature queue and I have some thoughts. But I'd like to hear your ideas on the best way to do it in the initial design. Thanks for your thoughts, Friend developer. All right, so we've got our initial first developers. Again, Fubar hasn't done a great job in that documentation for onboarding, but the folks from the Friend Corporation have taken the time to become familiar with the code. They've expended that effort to actually formulate what a contribution might look like. And as is usually the case with new contributors coming to a project, they're looking for some kind of reciprocation in effort in response to their contribution. So let's see how the Fubar developers respond. And his emails go unanswered, no response. Hey, Fubar developer, any chance you were able to read my last email? I have some good ideas, but I need your feedback. Please respond, signed Friend developer. So no response and nobody really likes to be ignored. And this is actually the number one most common issue that I hear from developers that I've worked with over the last 15 years. It's the case that I can't get a response to my question, I can't get a response to my idea. I can't get a response to my JIRA comments. It's often the case that there's an overload of activity, an overload of responsibility on those that need to make those responses. In existing projects, particularly the popular ones, it's often the case that the committers literally get too many contributions for them to be able to sort through. And that's an issue all and of itself that leads to a problem that is growing and is recognized as an issue as a committer burnout. But in this case, with a new project and what often I see in my experiences is the reason being something along these lines. Hey, boss. Yeah. I got this guy pestering me from the Project Double X community. He's from Friend Company. He's got a reasonable idea for this feature. It's actually something that we've been thinking about implementing a couple of sprints down the road, but he's asking for some help on how to implement it. I can do that, but I am like completely buried with my current workload. Yeah, I've been pushing executives at Friend to get involved in Head Project Double X for a while now. We really need them involved in a bunch of others to get on board with this project if it's going to be the industry to accept what story it's supposed to be. Problem is I need you 150% on your current deliverables. If I already slipped twice, if we slip our internal schedules again, it was going to be hell to pay. So community culture is really a reflection of the leaders of that community. And in my experience that really amounts to the contributors and the corporate managers of those contributors. If it is the case that internal requirements and internal product needs always take precedent over community needs, then it means the community ends up getting neglected and you end up losing contributors, which is counter to what we're trying to do with building communities. So this is a difficult balance that has to be worked through. In my experience, some of the best ways to onboard and continue to have new developers thrive and work inside of a community, part of it starts with education and documentation. One of the best ways I have found is through boot camps. These are one to three day events, technical developer events with your experts or the leading experts of the code base going through the architecture, the flow and in detail the code that is out there in the community. Often that material can be taken and recorded and used in webinars and blogs. And then also having a frequently asked questions list and or working with an organization like Stack Overflow where common questions can be asked and answered once so that the existing developers and the experts don't need to continue to answer the same question over and over, yet there's a good solid place that newcomers can get the information they need. All of that exists. Another strong thing that's needed certainly in the beginning of a project but also helpful as new significant participants want to come and work inside of a community are brainstorming sessions, understanding what these new contributors are looking to do. Do they have different use cases than what's already available? If there are, then what are they willing to bring to the project to fulfill their own needs? Often this may actually require some level of refactoring of existing codes so that you can get these new features included. And the existing participants and leaders of a community need to be open to that kind of activity. Not necessarily to do the work, the work should come from the new contributors but to be able to help guide them in what that new architecture would look like and how that activity would actually be done. And then finally, mentoring programs, particularly with a pay it forward feature I found to be very effective. These are one-on-one engagements with leaders of your community with new enthusiastic contributors with the caveat that after six months or so of them being mentored, they actually become mentors for the next generation of developer so that you can expand that knowledge base throughout the community. All right, so when I'll get back to our story with the friend developer now continuing to work on his feature queue submission. Hey football developer, it's me again. I've been spending a lot of time with the code and I think I'm starting to understand how it works and where my new feature would fit in best. I've attached an initial design document explaining my idea. I'd love to get your feedback if you think this is a good way to go or if you have some other ideas on how to implement. Let me know signed friend developer. Sorry I haven't been responding. I've been super duper, blooper, scooper, busy at work. Your idea isn't bad. It has several weaknesses to consider when comparing it to how things were designed in the beginning of the project and where it should be going over time. When I get a chance, I'll explain more what I mean. Thanks, Fubar Dev, out. Fubar developer, thanks for finally getting back to me. I understand that you might need some time to explain this to me later. Can I set up a meeting to go over this? I'd like to get started soon. Signed friend developer. Hey, Fubar developer. It's been a couple of weeks since I've last heard from you. Any chance you could find time to give deeper feedback on my feature design? I've already started coding so that I can stay on schedule within my own team. We are all really excited about bringing in the project XX in our next generation product. I can't wait to hear from you. Signed friend developer. So even though he's being neglected as a contributor, the friend corporation has decided that they want to try to put this in their product plans. So those plans have been established and deadlines have been set. Without any further feedback, the developer continues to work on his own, hoping that indeed silence equals approval from those leaders within the community. And often the fallback plan here is that they would do a downstream fork and actually include whatever new features they wanted to add into the upstream project and just keep it locally within the friend corp as a last resort. That typically is not a good idea for the long term. It becomes very expensive very quickly. So it's not something that's sustainable, but that's the only way to get around it. So continuing on with the story then. Now let me document this poll request. This poll request has new feature queue doing all of those banging stuff in my original design in addition to better supporting core project functionality that already existed. It's about 4,000 lines of functional code and 20,000 lines of test code. I think this is a really well thought out and well documented design. In addition, we have tested it thoroughly here at friend corp. PR review minus two. Thanks for your submission friend. The way you've implemented this is systematically problematic. We're looking at the overall function breakdown and planned evolution of this technology in project double X. There's no way we could accept this contribution without essentially a full rewrite. Fortunately for you, we've been building this feature internally here at food bar that is in essence the same as your contribution. It'll be ready to be shared with the community in another two to four months. Just wait during this time while we do all the heavy lifting for this feature. And then you can undoubtedly take it from us to solve all of your problems. Sincerely, food bar dev. Whiskey Tangle Foxtrot. So this is a typical problem in that cultural change really needs to be led by management. Right now you can see that there are clearly expectations not being met by the new contributors that are trying to participate. Yet at the same time, the existing friend developer or rather a food bar developer thinks that he's satisfying the needs of the community all by themselves with the work that they're doing. We found that particularly with new teams working inside of open source that having those new developers change their culture from working internally within a company to actually doing everything so that it's in the public eye. This comes back to that transparency notion where even though the open project meetings and so forth of Project XXX are all in the open, if individual corporations are doing significant development just behind their own walls and not sharing what those designs look like and further code and their roadmaps, then nobody else in the community can really know what's going on. And so it leads to duplicative work and wasted effort as we found in the case here with this contributor. Fred Brooks, Jr., author of The Mythical Man Month was quoted in the book saying, adding manpower to a late software project makes it later. A real good corollary to that is adding external developments to an open source project slows that progress down initially, which is really what Brooks was saying. When it's late, you're trying to get it out the door as quickly as possible. Things will slow down as new developers come on. You have to have your existing developers help those new developers so that they can become efficient. But once they do, you've doubled your capacity or whatever the number is. So being able to actually do that throughout the lifetime and lifecycle of the project, the only thing that allows new contributors to participate and for the project to actively grow. And also to do this, again, from a corporate management standpoint, you really want to incent the developers to actively include the community. You can do it through, you can identify metrics of diversity of committers. You can do it through identifying and incentivizing, pay it forward mentoring. You can do it by incentivizing that the lines of code from one release to the next of a project, the number of lines contributed by the existing company, in this case, Fubar, goes down as a percentage of the total contributed code. So as a final parting, we've got the managers meeting at a conference. I am so glad that I ran into you. I'm wondering, I've been wondering why Fran isn't getting involved with Project Double X. The way you guys said you were going to, so many months ago when we first talked, I'm a little concerned that we aren't getting the kind of traction we need in the industry. And this isn't going to succeed unless we have folks like, you know, Frame Corporation getting on board and making this part of your production code base. Yeah, yeah, I saw you in there in the keynote. I was hoping we could get a chance to talk a little bit. Yeah, we really thought that Project Double X had a lot of promise. And that's why we started engaging in the open source process. But frankly, you know, my developers are telling me they found it difficult to work with and lacking some key functionality that we need. I'm really concerned about that. I'm getting a lot of heat from the top to implement this functionality and get it into production. So we need to start looking at alternatives to deploying this important functionality. So here we have a set of missed expectations. The Fubar Corp perceives the community is being not committed. They're frustrated that organizations aren't stepping up like in the beginning they said they would. The Frame Corporation is frustrated because they've wasted precious engineering time. They've missed deadlines badly and the trust and confidence in the project is really broken. This is really a prisoner's dilemma, right? Fubar's high level priority and goal was to create a community that would be industry impactful around this project, yet their short-term goals of making sure that their internal product schedules stay on track, which are certainly important, but it's costing the actual existence and creation and growth of the external community that is also a higher level goal. So here's some kind of balance and expectation setting needs to be done. In this case, worst case is the Frame Corporation just leaves the project, but the best case is that the Frame Corp stays, but because they need to figure out how they can actually work inside of the community, they'll try to build a silo within the project to protect their work. Learning that the only way to ensure that the work that you're doing gets into the final code is to actually control the repo with committers. And so that's what will happen. And these silos, once they're created, they start to compete with one another. There's duplicative code, there's wasted effort, testing gets much more difficult, and over time, the technical excellence of the project overall begins to wane because of that behavior. So these are things that, again, you're building a culture here, right? And how to succeed. And these are activities that impact the result of what that culture looks like. So to recap and in conclusion, really when leading one of these open source efforts, it's very important to recognize that indeed the community is important. And if that community is important, then spending the time and the resources to make it thrive are critical. For newcomers to a project, understanding what that culture looks like and if it's a good fit is important before you engage. And if you do engage, then making sure that you're willing to share that burden over time to improve that culture. No culture and open source is perfect, but to be striving towards that means the community will thrive and grow. Investing in and incenting that open source culture within your own organization so that your developers are engaged in those communities is important. And this investment pays over time. It's not something that you see tomorrow, but it's something you see in the next year, the next three years, as that project grows and more and more community members are comfortable in coming in because that trust has been established. All right, well with that, I wanna thank you very much. And I certainly want to put out a huge thank you to my video stars. For Fubar, that was Kenny Paul and for the Friend Corp, that was Jim Baker. And again, while these experiences were taken from my real life in an amalgam of different projects, what you've seen as fiction and any correlation between persons and events of a similar nature are merely a coincidence. Thank you very much for your time. All right, very good. We have just a minute or so for any questions. Hopefully those are the questions that have been going on across the Q and A with speakers has been coming across. Are there any other further questions that the group here has before we close and can people hear me? All right, very good. Thank you. So no questions. Apparently there's some kind of mute button on your screen that you need to click to be able to talk. All right, well, please follow up with me. And thanks very much for participating today. If you do have any further questions, please feel free to email me. I'm Phil.Rob at EST.Tech. And I look forward to any further questions that you might have. Thanks very much folks and have a great conference.