 Hi, this is your host, Upin Bhartiya, and welcome to another episode of GFL. Let's talk today. We have with us once again, John Murtic, Program Director of the Linux Foundation. John, it's great to have you on the show again. It is great to be with you, Swap. And today, we are going to talk not about any project, but a lot of projects, because you just released your book, Open Source Projects Beyond Code. So first of all, congratulations about the book. Now, tell us about the book with the publisher, and is it available already, and what is it all about? Yeah, so it's through PAC Publishing. It is available through PAC Publishing. You can also get it through Amazon and wherever good books are sold. The real focus of this book was looking at the Open Source Projects and just sort of like all the ingredients that make it work. And it's all sort of those behind-the-stuff things that I've been doing with projects for my entire career, from helping them work on governance to helping them look at licensing, to helping how companies get involved, and just also just how to really build these strong, sustainable communities of bringing in contributors, helping nurture them into the community, helping identify those that sort of rise up within the ranks, helping sort of bring in those new leaders of the future, and looking at the aspects of the conflict and the commercialization and the career growth and everything that happens as a part of it. You think about Open Source from the output of you get great code. You get a cool project. You get some interesting technology. But as I've known throughout my career, there's so much more behind it to make any of that even begin to happen. And that's really where we focus, where I spent a lot of time focusing on the book is digging into those details. What are those ingredients you need? And a lot of it, I pulled some great stories from projects that I've had the fortune of working with over time and lessons that I have seen and stories out there to really kind of hopefully connect the reader to not just sort of be a do this, do that sort of list, but something that's just showing examples of how it's worked in different communities, how things somehow sometimes don't work and just sort of understanding some of the variables that play because the one thing I've learned at Open Source is no two projects or anything alike and you can't say what worked and won will work in another 100%. There's just, there's nuances, there's differences and that's what makes it challenging and it also makes it a lot of fun and makes it really fascinating. And that's really what I dug into in this book. Let's break these things down. I know it may be harder for you, but if you could just give us a glimpse of the kind of chapters or sections that are there so that in a way that you have written them or where you feel, hey, this is the way to build the story for the book. Yeah, so the book is really set up in almost a way as like a cookbook. There's a couple of really introductory chapters that if you don't have great familiarity with Open Source, it's a great place to start the first two chapters and the first chapter really goes into kind of like a history of Open Source but kind of like winds back all the way into the 50s and sort of talks about how the progression of technology created the elements that Open Source is what it is today and starts to look at what are the elements and what do Open Source projects look like and why did they come to be? Like what was the driver's? What was the impetus behind it? And then it gets into, I start talking about what makes a good Open Source project. Like what are the things that you need to have there to have success? And once you kind of have a lot of the base material, then we start to dig into a lot of different areas and sort of the first next set of chapters are sort of that arc of how do you get from, I like this idea of doing an Open Source project to actually launching one. So it gets into licensing, gets into employer involvement, gets into sort of those early days of what your projects look like. And then from there we kind of transition into the steady-state project and really start to, I spend a lot of time digging into the interpersonal dynamics within a project. What is that relationship between maintainer and contributor look like? How are you able to make your project look welcoming so that you get contributors that come in the door? And then once they come in the door, how can you begin to identify those ones that sort of rise up within the ranks and how do you appropriately nurture them and how do you see if they're gonna be a good fit and kind of bring them in? Because I mean, one of the big challenges that is within Open Source and we run into it with projects all over the place is you have a small set of people that the heaviest amount of tasks are weighed on and one of those people go away and these projects crash into the ground and that's something I really try to spend a lot of time exploring of like, well, how do you do this intentional process of getting somebody through that mentoring process so they can be that next leader? Not just also for them, but also a comfort for you as a maintainer because oftentimes for people that are starting your own project, it's kind of a lot of your identity that you're tied to. So it can be really, really, really challenging to in a way relinquish some of that control but sort of understanding of the why's and the models and how it's been done and how others have done it before. So we spend a lot of time that understanding sort of the interpersonal dynamics, understanding how conflict works and sort of how the personalities are coming in and really starts to get into the human mind of how people interact with one another. And then we started to dig into the sort of next level of topics in there. Marketing, community, or I'm sorry, commercialization, building careers through it because there's so many people that get involved with open source as a way to sort of jumpstart their career. They put, I mean, it's the portfolio of our time. Like an artist will have a portfolio of work they show. Today you show your GitHub profile. And so how is that kind of tied into there? And then we started to take it on the back end of sun setting projects. When projects run their course, what is the responsible ways to do that and how do I identify that and what really happens next past there? So it really tries to hit a whole arc of everything but when I was writing the book I really consciously wanted to assemble it as a cookbook as something that you get this book and you may not all the chapters might not make sense right now but you put it on your shelf and when you get to that section you come back, you grab the book and then you then all of a sudden it really sticks to you. Perfect, excellent. Thanks for giving an overview of what the book is about. Now, when I look at you, you're not just an author. You're also leading a lot of open source project there at Lennings Foundation. I think that when you're working on the book and when I look at the book it also reflects a lot of work you yourself have done. You may be humble enough to not say that but talk a bit about what was the influence that kind of encouraged or inspired you to do work on this book. Yeah, so I think really the big ones that I work with right now, Open Mainframe Project Academy Software Foundation and the LF Energy Foundation are three that I've worked with a ton over the past couple of years and I've been working with projects for over 20 years now but as I've worked especially with those three and seeing where they're at and sort of their open source journey and especially as compared to some of the other projects I'd work with that maybe from a little farther along or at different stages it just gave me this great perspective of there's so many interesting lessons and things that we're seeing and stories and insights that coming from the mainframe industry and the motion picture visual effects industry and the energy industry pulling all of those things together and really trying to kind of comprehend them in the book. To me it was an opportunity to take the great insights from Open Mainframe Project Academy Software Foundation LF Energy amongst a ton tons of others and have it as sort of a resource for those communities but also communities that come after that to really just start to understand and learn. I mean it doesn't necessarily answer all the questions for you it's not designed per se to do that but it certainly gives you the right questions to be asking and the right things to be thinking about and thoughts and ways to look at it and patterns of how communities like this and many others have built themselves and have built community and have maintained sustainability. When you were writing the book and which also I mean, which involved a lot of research and when you're like, hey, oh, this is the aspect of open source that even you were excited about that, oh, this is how it works or I mean a lot of times we have been working in the field for so long we start taking a lot of things for granted. So was it any experience while you're writing a book doing your research where you came across an aspect of open source where you were so either surprised or super happy to look at it? You know, I spent a little bit, I spent one chapter where I was sort of dissecting the growth of a project called Motic. So it's an open source marketing automation tool. And I thought it was a really fascinating because we looked at the entire arc of them from an early project to kind of a large state community and breaking apart the areas where they were at points in the road and why they made sort of the decision they did but then also how they were looking to pivot and change what they accepted success as. Cause I think that's one of the interesting challenges when I work with open source projects is, you know, there's this blanket saying of like, well, how do I know if it's being successful or the other half of it is, are we doing as well as Kubernetes? And then I have to kind of like, you know, I just care about people's expectations there a little bit, but it's understanding that the projects are different parts of their journey. They're gonna have sort of different sets of expectations and different things you're optimizing for. And so I thought that was a really, and I knew about Motic and I really hadn't looked into them as a project for a long time and going back and kind of walking through it, I thought that was a really, really fascinating opportunity to really dig into that one really in particular. I think another one that I really enjoyed digging into was a little bit on the sun setting process, which just seems a little bit morbid, I suppose. But what was really interesting, I spent a lot of time researching projects that did sunset for one reason or another and why they did that and what that looked like. And what were the reasons for it? Because one sometimes thinks you just sunset a project because nobody cares about it anymore. And sometimes that's just not necessarily the reason. And so it was interesting exploring some of those cases as well. So within there, there's always interesting themes and stuff I kind of picked on the way, but I think those really stuck out at me. It was really fun parts of the research going into it. As you were saying earlier that no two projects are really hard to replicate a model, but yes, there is no playbook. But while writing a book and then you look at a lot of projects where you did find, hey, there are some common grounds which are essential for the success of not only a project, but also commercialization of the project. Was there any focus on that in the book? And also if you can just kind of, I don't want to give too much about the book. I want people to write and read the book, but just a teaser is also fun. I think we really, in the middle part, as we were starting to dig into sort of the interest to contributor, to maintain, or to sort of lead or journey, there's a lot of ways that happens. But I think the one thematic that you could have as all of across that is it's typically not something that happens by happenstance. Like it's just not, you can just trip into it earlier. I mean, okay, there are open source projects that just, you open the doors and the flood gates to open and everything works out. And even those, I don't think it's a sustainable thing. I think it's sort of more of a shot in the arm. But the one thing I think there's a theme in there is you have to be intentional of thinking about it. Like I run into projects all the time that are like, geez, we need more people here. And I'm like, well, the way to get more people here in a lot of ways is helping think about why those people would want to come here and be a part of this project and what is going to draw them in, what's going to value them. And frankly, also what you need them for, like what are the things that you need in this community that you don't have? And I think when you're thinking about sustainability it's not an overnight process. And that is something that I really try to talk about at a very high level. I mean, we get into some of the different aspects of little things to think about and whatnot. And again, not all those translate over but the biggest theme is, is it's something you have to actively think about and plan for and start working on and have it as a part of your entire strategy for your project. I mean, if it's a project you're just gonna start up and it's a hobby and it's out there, have at it. Like, that's totally fine. But if it's one that there's an anticipation this is gonna be around a while thinking about that long-term aspect of it is an extremely important part of it. I think my family for putting up with me for the darn near year that it took me to write this thing. Lots of nights, lights, lots of weekends. I really want a big thing to Guy Martin who did the technical reviewing for me. And without him, I don't think it would have turned out the work. I mean, he was a great validator of the book really. And so I can't thank him enough. And the thing I think the most is every single open source project that I have had the great honor of being a part of or helping in because everything that I've learned is from other people. There's not a, I mean, it's kind of weird to say there's not a lot of original thoughts. It's all things that I've seen out there. I mean, I guess there's original thoughts but it's all things that are happening out there. And in a lot of ways it was an effort of collating and pulling and kind of bringing some thematics with it. But I think the hard work that is happening out there in these communities, every day I'm learning something new from. And a lot of my goal was, I just wanted to get right this down and put it in an area so that this can be a resource for other communities that are looking to start up. I mean, it's not gonna have all the answers but it's at least gonna give you all the right questions to be thinking about and maybe a couple of answers along the way if you're lucky. And that's really what I was aiming to do. And I'm hoping this really makes a really good impact for folks that are just thinking about starting a project. They might be great technologists but have not thought about all the other aspects of this. And hopefully this gives them some good context and some good thinking to work from. John, thank you so much for sitting down with me and talk about this book. And of course I would encourage your viewers to get this book and read it because as you mentioned that it covers the whole spectrum of open source word which goes beyond code. And there's always something for everyone not just for maintainers, people who are running companies but also people who want to become contributors or just consume open source. So thanks for writing this book and thanks for talking to me today. I look forward to a next interview. Thank you. Absolutely, thank you.