VM: [00:00:00] For fuck’s sake, doc your shit!
Matty: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matty Stratton, and I have a great guest with me today, but first, a word from our sponsors.
VM: Chef is a community of professionals practicing DevOps every day. We are making, proving, learning, and shaping the future. We are known for welcoming, encouraging, and liberating others to do the same. We do not talk about change, we do change. Join the community and learn about our solutions at chef.io.
Matty: This episode is brought to you by Datadog, a monitoring tool that helps bridge the gap between operations and dev teams. Datadog brings together system metrics, changes, alerts, and events from over 120 common infrastructure tools such as Chef, Docker, and AWS so that dev and ops teams share their key data and alerts in a single place and collaborate on issues in real time. Datadog is available for a free 14-day trial at arresteddevops.com/datadog. So I’m joined today by VM, aka VM Brasseur, the Vice President of the Open Source Initiative. We’re going to be talking about contributing to open source software, how you can do it better, why it’s important, and all sorts of things free and open source. The show notes for this episode can be found at arresteddevops.com/foss. Vicki, before we get into this, can you tell our listeners a little bit about yourself and your background?
VM: [00:01:41] Well, hi, Matty. Hi, listeners. It’s great to be here. Myself and my background, I am an open source developer. Policy and strategy freelancer, and I also am the VP of the OSI, the Open Source Initiative. So, uh, what the freelancing is, it’s not, you know, I see a lot of listings for open source developer, open source strategy, open source this, uh, well, don’t see listings for open source strategy, unfortunately. Um, and those are primarily development, and I’m more on the business side. So I come in and I help companies understand open— free and open source software, and how to use it, contribute to it, release it, and comply with the licenses. So, how to do that properly, but how to do it in a way that’s good for their bottom line and the community at the same time. And it’s— that’s one of the things that I see we don’t do a lot of in free and open source software, or in business, is pay attention to both the business perspective and the community perspective and balance them appropriately. That’s what I help companies do.
Matty: [00:02:47] Fantastic. One thing I wanted to talk about for starters, some exciting news, and this will probably play a little bit into the topic. You have a book coming out, right? Forge Your Future with Open Source.
VM: Holy shit! OMG! BBQ! WTF! Yes, I have a book. For those of you who have considered writing a book, I would first say, don’t do it. But if you do it, do it with Pragmatic Publishers, which is my publisher for my book, because they were so amazing and so supportive throughout the entire process. Writing a book is hard. So, this book is all about how to contribute to free and open source software projects. It is, as far as we can tell, the only book ever to cover this, and there are some possible social reasons for that, I’m sure, that I won’t get into right now. But it finally exists. You can get it right now at Pragmatic Publishers. It is available in an early release beta, and the hard copies will be available in mid-October, I believe. We’re going to be doing signings at All Things Open, so we better have hard copies by then.
Matty: [00:03:59] Yeah, or else you’ll be, I don’t know, signing people’s hands or, you know, t-shirts or, you know, rock star on them. It’ll be kind of a little bit of a different thing. When we think about the business, and actually, there’s kind of a topic, and I don’t want to catch you by surprise, but speaking of open source and the business of open source, Redis had a pretty big announcement in the last, what, 24, 48 hours? I don’t know if you’ve read about that, but they’re changing their licensing.
VM: Yes, I have read about that. I have already blogged about that. I have written on Hacker News about that. I have wasted most of my time fielding questions today about that. Wasted is probably the wrong question, the wrong way to phrase it, frankly. But, um, yeah, it has kind of consumed my life today. So for those of you who don’t know, what happened is that Reddit posted— I know it wasn’t really a blog post or news or anything like that, but they posted a page explaining that they were going to take certain components which were not listed or named. And they were going to relicense them under the Apache license with something called the Commons Clause attached. And what the Commons Clause does is it prevents anybody from making any sort of money whatsoever from those components, whatever they may be. Now, to be clear, this is not core Redis. This— so Redis itself, apparently, according to the lead developer, is now and always will be under the BSD-3 license. So don’t freak out about Redis being closed source now, but a lot of the pieces apparently around Redis are being closed source. Although the Commons Clause implies that it is open source, it’s not. Because all of the freedoms of open source software and free software, they all ensure you can do whatever you want with the software, including make money. So, I have some thoughts and feels on this.
Matty: [00:06:10] Do you have questions? So, yeah, we will definitely put your blog post, we’ll put that in the show notes for sure, so people can follow up on that. But yeah, there’s definitely been— the Twitters have been on fire about that for sure. When we kind of think about the— so you talked about kind of the business side of open source and the business development kind of side. What are some of the lessons that people can take away about this, some of the things that don’t get thought about that you alluded to before?
VM: Well, for starters, people seem to think that open source is a business model, and that’s foolish. Open source is not now and never has been a business model. Open core can be a business model, but open source itself is concerned with the freedoms of the use and modification and distribution of software. That’s what it’s concerned with. Business models are a completely different thing. Open source is one of the many tools you can use within your business to potentially make money, but you still gotta do the really hard work of figuring out how to do that. So simply opening up your core software and saying, okay, now people are going to pay me for it, I mean, that’s stupid. That’s not going to work. And if you look at the list of companies that have been open core over the years, there are very few of them that you can point at and say, yes, open core has been successful. And the only few you can point at and say, quote unquote, success, they were all exits by acquisitions. They were acquihires, because you could not obviously be acquiring the technology. It’s already freely available. So open core doesn’t appear to work. My friend John Mark, who is currently at edX, he has a really great series on this, on, I believe, Linux from 2015. And if you would like me to dig that up from the show for the show notes, I can certainly do that. But he just lays it all out and says, come on, guys, this is not how you do business. How you do software and how you do business, they can work hand in hand, but they’re not the same thing.
Matty: [00:08:28] Yeah. So like you said, it’s strange that you have to actually think about how to run a business and actually think about revenue and not just magically build it and people will just give you money, strangely enough.
VM: Yeah, weird, isn’t it? Well, well, the strangest thing is that people do just give you money. They’re called VCs, and they just give you money, several million dollars. And yeah, your open core business can chug along quite fine as you burn through that, that runway, but then you just have to go back and get another funding round, because you will find that you’re having a difficult time just, you know, selling your support or selling your extra add-ons or what have you. And so I think that this is something that we need to give a closer inspection. Not that it can’t work, because people definitely can make money from free and open source software. I do it. This is how I pay my rent. But There are, I think, on a case-by-case basis, people need to reevaluate whether this is the appropriate business strategy for them.
Matty: [00:09:40] What are— so we talked about open core being something that rarely works. What are maybe some success stories of being able to— like you said, it’s not a business model, but being able to leverage open source software as part of a business model? What are some examples you’ve seen of people doing it successfully, organizations doing that successfully?
VM: Well, open source, I mean, it’s not a business model, so you can’t just release all of your stuff and expect people to pay unless you’ve got a really good reason why they would do that, which apparently is one of the problems Redis may have been having. It’s really hard to tell why they decided to make this move, and so I’m not going to pretend I know. So, but the thing is, free and open source software, Depending upon the study you look at, it is in anywhere from 80-some to 98% of the software that is currently developed in proprietary companies. They rely upon free and open source software a lot. So using free and open source software is an amazing way to bootstrap innovation and to get your company off the ground. Where we seem to be falling short is on contributing back to free and open source software. And Nadia Aghbal had a really great study that came out. It was sponsored by the Ford Foundation. I think that was in 2014, 2015, not too long ago, where she researched the crumbling infrastructure of software development and how it is based upon all of these free and open source software projects that are not getting the support they need to be successful. So Nadia, she was at GitHub. I forget where she has moved to now. She’s doing really great work on the research side now. So thank you, Nadia. So that’s a really interesting study. And a lot of people, that set off warning bells for them. And they realized that, holy shit, I am basing my entire business on software that is just hanging by a thread because there is one dude who was doing this in his free time. And that’s actually what happened with Heartbleed and OpenSSL. There was a very tiny team that was not receiving the support it required, and they weren’t able to cover all their bases. And that caused a lot of problems for a lot of companies, the entire internet, frankly. So that is something— once Nadia’s study came out, it was an alarm bell across the entire industry, and everybody started talking about the open source sustainability problem. Which, because a lot of these people come from Silicon Valley, they interpret it as, let’s throw money at it. So, that’s what we’re currently looking at, is this bevy of sustainability initiatives for free and open source software. And I do believe that a lot— that most of these core contributors do need some sort of remuneration. For their, for their efforts. I think I strongly believe in paying people for the work that they do, but what they need more than anything, I believe, and what we are neglecting a lot of, is help. They need more core contributors to help them, and they need themselves to learn how to allow other people to help them. So it’s a very complex people issue. It’s not actually a business issue. And we’re— all of the approaches I’ve seen so far are coming at it from a business and a technological perspective rather than the people perspective. And I think we can do better. And that’s what I hope my book will help with, by helping to show people from the contributing side how they can help the projects on which they’re their own projects, their companies, on which they rely. And then, hopefully, maybe, we can start working on the other side. You, project maintainer, you core contributors, how can we help you get more assistance, so you don’t have to be working nights and weekends and missing your kids’ baseball games and things like that?
Matty: [00:14:04] Yeah, it’s— like you said, there’s only so much that you can just throw money at, because there’s still the finite amount of effort and Burnout, even when you’re being paid, is a for real thing. Being a maintainer is often thankless and frustrating. Jess Frizzell talks about, like, she’s the one who, when something gets merged wrong, is on the front page of Hacker News for breaking Docker. Speaking of, Jess has a great blog post we’ll link to again called The Art of Closing, and it’s about being a maintainer and about learning how to say no. I’ve loved that one. What are some of the things when, if someone is— because I think I think it’s people get very excited about starting projects. And then when it becomes this inertia, or not inertia, but just it becomes getting burned out, or becoming overwhelmed when a project gets big and very dependent, and the people in general are fairly thankless. So what are some of the things, I guess maybe we could start with, for maybe some advice or some thought, and I don’t want you to give away everything that’s in your book, because we want all our listeners to go buy it, but maybe some some tips or tricks, or not tricks, but some insights or thoughts, starting with maintainers, about some things to think about to be able to share this, to be able to make it easier for people to contribute?
VM: [00:15:25] For fuck’s sake, doc your shit! Seriously, that is the biggest problem, is that people— so, I have this talk I do, which is all about drive-through contributors. And a lot of open source projects kind of turn up their nose at drive-through contributors. And what drive-through contributors are are people who show up, they give you one contribution, and they never come back again. And my talk thesis is that these people are actually good, and if you use that as a metric, and if you can maximize those and get more of those, then your project is actually doing well. The reason behind that is, if people are able to show up, drop one patch, get it merged, and then get the fuck out, you have done something really well that is going to make it a lot easier for people to show up later and to stay longer. And one of the problems that I found in my research is with drive-through contributors, they would show up and it would just be so hard. You would be expected to read the code rather than find documentation. There were no install docs. There were no user docs. There were, you know, no how to How do you set up a developer environment? None of this is documented in a lot of projects. I understand writing is hard. Honey, I just wrote a fucking book. Writing is hard. But it also is the best force multiplier because it means you get to stop answering all those questions that you get over and over again. If you just write shit down, and make it easier for people to self-serve. Just take a day, take a weekend, and just do nothing but documentation and leave all of those other bugs aside. Just do documentation. Even shitty documentation is probably better than no documentation at all, and you’re more likely to get contributors if you document how to do it.
Matty: [00:17:26] And I think even, like you said, even shitty docs, you’re more likely to get contributions to those docs than no docs. I’m a big believer in the concept that a blank piece of paper is very intimidating. So if I was going to go and take on a project, look at a project that I love and say, well, it has no docs, I don’t even know where to start, but versus you at least half-assed your way through it and like, oh, well, I can edit that. I can add to it. I can find defects in the doc. So, I think, because I always know that’s one of the things that people say, how you can help contribute if maybe you don’t necessarily have a patch to contribute or whatnot, but with documentation or writing tests, things like that. Again, that’s—
VM: Yes, but. I mean, we all say that, and I am a very strong believer in the power of documentation and and unit tests, and particularly integration tests, which is something we neglect a lot. I’m a strong believer in this, but in order to write documentation, you have to understand the project. In order to write tests, you have to understand the code. And so we get a lot of these recommendations from people saying, oh, if you want to contribute to free and open source software, just write docs. No, don’t write docs unless you know the project. Then yes, you can write some documentation. You made a great point that I don’t think is made often enough. You can fix the docs. You don’t have to write them from scratch. As a maintainer, just getting people started is typically all you need, because they’re really eager, and they want to do the right thing, but they can’t if they’re starting from zero. If you start them from even one or two, they’re more likely to be successful. Help your project?
Matty: [00:19:20] Yeah, I, uh, going through this a little bit, it’s, it’s not, it’s not open, but as I took on a project here at work, um, that someone who has left has had kind of built, and now I’m going through it, and again, it’s none of it’s documented. The problem is when you’re taking something on that’s not documented, what you don’t have is you don’t know what’s not important anymore, right? When you’re trying to reverse engineer something, because we don’t always clean up after ourselves. In our projects. We keep methods around. We keep stuff around that we’re not using. And you can spend an awful lot of time trying to figure out what something does that actually isn’t used at all.
VM: Yeah, you might think your code is obvious, but I guarantee if you yourself look at that code in 6 months, it’s not going to be obvious at all. Document it even if you’re not going to open it. Add comments, add docs, Markdown or AsciiDoc or I don’t care.
Matty: It reminds me of one of my friends said that I’m the only person he knows who argues with themselves in GitHub issues on my own projects. And I said, well, it’s because I might have to go look at it again in 6 months. Like, I start something, I want to keep track of it. But yeah, it’s a whole, you know, I’ve got GitHub issues that are a whole thread of just me. But it’s different instances.
VM: [00:20:35] Thank you. So my first job in technology was at a library automation software company, and I was there for 6 years. And I’m very pro-library and library positive. I think libraries are amazing, and they do astonishing shit with technology that just would blow your mind sometimes. But one of the most valuable things that job instilled into me was how to use an issue tracker. You write everything. Every single thing, every command, every output, everything. And it’s not because you’re being micromanaged. It’s because that issue is going to go to somebody else and they need to see what’s happened and what, why, and how. So I treat my issue tracker like a, like a scientist’s lab book. And I’m constantly talking to myself and saying, okay, I’m going to try this because of this reason. Oh shit, that didn’t work. Okay, here’s what I got. Now I’m going to try this because I think that’s— this shows me that’s going wrong. And just constantly having this dialogue. So when I hand this off to someone else, they’re like, oh right, I see where she’s going. She’s totally off base, but I see where she’s going with that. But you can’t do that if you don’t even document your issues. It takes a lot of time, but I’ve never once regretted doing it, and I have it so many times, regretted not. So thank you. I’m so glad to hear you do that too.
Matty: [00:22:04] I think it’s also a chance to, as a maintainer, or, you know, to lead by example as well, right? Just like I try to with my own projects, even though, yeah, sometimes I’ll YOLO right into master, but I try to, I still do PRs for myself. And even if I’m the one that approves it or whatnot, because it’s giving an example, it’s showing this is the workflow, this is how it works. Right, so other people, when they want to look and see, can follow along.
VM: Absolutely. And it also makes you more comfortable when you are working in a collaborative environment because you already know the workflow, right? You’re going to default to a positive workflow rather than the one that you use on your own projects.
Matty: And it’s not different— the same thing. And when you have the collaborators coming in, you’re not treating them any differently than yourself. One of the challenges we talked about, kind of talked about the sustainability problem, and I know a lot of enterprises, it’s hard to sort of, for them to contribute back. And I’ve had that challenge with customers of mine when I was at Chef, and that was a big thing. We were doing a lot of open source stuff, and we wanted customers to be able to send stuff back. And usually they like to throw the, usually the lawyers get in the way. What are some of the things you’ve seen with how that’s maybe been changing? Some of the— are there— is there positive things we can see that maybe, you know, are things getting better?
VM: [00:23:33] The answer to almost everything is going to be it depends. It’s something that is constantly evolving. I think that— so lawyers are Understandably and justifiably so, very particularly IP lawyers, so intellectual property lawyers, are going to be very conservative and risk-averse. And that’s because any sort of IP-related stuff is going to get you in a world of hurt and it’s going to cost you a ridiculous amount of money. I do talk about a lot of IP stuff in the book and constantly say Don’t fuck with IP law. I don’t use the word fuck because the editors don’t like it, but that’s really what I’m saying. So there are some complications with that. And what we— what I am starting to see are some companies trying to kind of grease the rails of contributions. It’s pretty rare that you find a company that is able to do this. Some companies are modifying their employment agreements. So, GitHub did it, and GitLab did it, and I believe there are others that I don’t have off the top of my head, but they modified their employment agreements to specifically say, on any device owned by any person on any time, if you are making modifications and want to make a contribution to a free and open source project, it’s okay. But a lot of employment agreements don’t allow you to do that because of IP restrictions. Um, so some companies are trying to modify their employment, uh, agreements for that. It’s pretty rare. What you see more often, but it’s still also rare, is this, um, checklist of, of things for— to make it easier for people to contribute. You don’t have to ask permission if XYZPDQ. If you can put a checkmark in each one of these boxes, go ahead and contribute. It’s okay. But that list varies from company to company because each company has a different risk profile. So if somebody is giving you this, like, I know, cookie-cutter checklist, use this for your company because it’s what works for us, that’s a load of hooey. And your company and your lawyers are probably going to get really ticked off if you try using that within your, your department. So don’t do that. That’s why people like, like me exist, so we can come in and make sure that you can set up those guardrails to make it easy for people to contribute without having the legal and business risk.
Matty: [00:26:22] What are some of the other things to keep in mind when we think about open source, from a— whether either from a contributor or maintainer or business perspective, some of the things that people tend to not think about?
VM: The things that we— so, we think of contributing to free and open source software as code. And I know we’ve already discussed docs, and those aren’t code, but you do commit them to the version control, so really, they’re essentially code, right? It goes through the same process, and that’s not the case. You don’t have to be a programmer in order to contribute. And we, in free and open source software, have kind of shot ourselves in the foot with this over the past 30, 40 years, because we have become highly programmer-centric. And because of that, we do develop a lot of things that have crappy usability. And because of that, we’re never going to have the year of Linux on the desktop. Care how many people say it, because we, we are developing things that require a lot more technical knowledge than they necessarily should. So if you are a designer, if you are a usability expert, if you’re an accessibility expert— holy shit, accessibility experts, get in there because we need your help— you know, if you’re a marketer, a lot of the reason why a lot of these projects can’t get more contributors is that nobody knows about them. So if you’re a marketer, you can find really good ways for them to get their message out. We need help like that. A lot of organizations might receive funding and need help— how do I deal with the funding? So if you do finance, great. Find a free and open source software project that needs your help. Find a free and open source software organization or nonprofit that needs your help, like Conservancy or Software Freedom Conservancy or Software for the Public Interest. There’s lots of organizations out there that need help that are not just code. So, software is more than about the code. Software is about all of the people that have to come together to make it happen.
Matty: [00:28:40] That’s, yeah, a lot of ways that’s really insightful to think about all the different skills that people have to be able to leverage for these things that are important, and that are, like you said, are not the default place that we think. I think even I’ve been aware of just some conversations I’ve had with folks around the infrastructure of open source. When you look at things like crates.io for Rust, they run on stuff, someone’s got to do ops of that. I did an AMA with Ashley Woodland, who kind of runs that infrastructure for crates. And that was the thing. She’s like, how do we do on-call? How do you do on-call for critical infrastructure with a bunch of volunteers? You know, I want to kind of be like— I talk to a lot of companies where people are like, I don’t want to be on-call. They don’t pay me enough. I’m like, I want the people that are on-call where they don’t get paid at all.
VM: Exactly. Well, so when I was at Hewlett-Packard Enterprise, my team was entirely dedicated to upstream open source development and anything they could do to make the projects on which HPE relied better, anything they could do for that, was their mandates. And a large number of them were dedicated to the infrastructure of OpenStack. And I don’t know if you’ve looked at OpenStack and its contributions process, but holy shit, there is a lot going on in the back there to make those contributions possible. And the team was dedicated, a lot of them were dedicated to that. And they were— they had a lot of the same problems, right? I mean, what do you do with on-call when you’re a globally distributed project that’s one of the largest open source projects in the world? How do you make sure that it stays up and people are able to contribute wherever they happen to be? A quick note on not— on the multiple ways to contribute. My book is not focused on programmers. There are maybe one or two examples that use code, but it’s focused on all of the ways to contribute. So, if you’re not a coder, this book is still good for you, because it walks you through all of the steps regardless. Because the vast majority of contributing to free and open source software, it doesn’t matter what you’re contributing, whether it uses version control, or code or whether it doesn’t. You still have to know all of these social mores. You have to know how to use chat systems and mailing lists and just all of that stuff. You have to know those no matter your type of contribution. So don’t feel you have to be a coder to contribute. Don’t feel you have to be a coder to read my book. So hey, go buy my book.
Matty: [00:31:22] Yes, absolutely. Everybody buy the book. For sure. A lot of, a lot of good insight there. I’m looking forward to picking it up myself, especially thinking about different ways to be part of the industry and help things be better. And that’s from my own personal experience too. It’s like, I’m, you know, I’m not by far my— I was gonna say I’m not the world’s best software engineer. I’m not even the world’s worst software engineer. There’s people that are, you know, I’m worse than the worst software engineer, but I think about things you do with podcasting and with events and organizing things like that to help drive the ability for people to be able to share this information and do things like that. There’s all sorts of ways to apply your skills, I think, to help make everything better. I want to take a quick tack because something that we— we’ll keep talking about open source, but The fans of the show know we did an episode recently with J. Paul Reid and Mary Thengvall, and we talked about safety and stuff. And so last week, Vicki and I were both at Redeploy, which was probably, from a content perspective— I’m not saying that because I spoke there, because I was probably the worst speaker— one of the most interesting and learning experiences I’ve had at an event in years. It was really, really well done. They—
VM: [00:32:48] I was really impressed. I only, full disclosure, was only there for one day because I had client stuff the next day. But it was so well done. It was content-packed. And it’s not just that it was content-packed, but it was all relevant. And it was all really well delivered and somehow seemed to connect each piece, each talk, seemed to connect very nicely to the next one. They all hung together well as a program that gave you, oh God, so much to think about afterward. It was great.
Matty: So we’re hopefully, we’ll definitely tweet out when we find out that they’ve got the videos and stuff up there. But hopefully that we’ll be doing this again and don’t miss it for sure. The, when, and one of the things too that I found out through some conversations while we were there is that you, help people kind of develop their abstracts or proposals or ideas around that. What’s some of the things that maybe, and how that could go into keeping a little bit on our topic about that you’ve learned or you’ve been able to help people with about being able to communicate the different, maybe different kinds of ideas, different viewpoints than sort of the normal tech talk about here’s, you know, 10 cool tricks with npm?
VM: [00:34:10] So I, by the end of this year, I will have reviewed over 1,000 conference proposals in this year alone. That’s not counting all of the other years. And I also do trainings on how to get, if your team, your company wants to get more people organically placed through CFPs so they have more speakers at conferences, I do trainings on how to do that. So I have a lot of feels on this subject. And a lot of experience looking at proposals and knowing what works and what doesn’t. If you’re really excited about the latest hot thing that’s out, if you’re excited about Kubernetes, or, you know, a couple years ago it was Docker, or artificial technology and machine learning, or security and IoT and privacy, and all of these things that are really hot right now, It’s hot for a reason, and you can be guaranteed that lots of people are going to be proposing talks about it, just like you. So what’s going to make your talk stand out from everyone else’s? What’s going to make yours look like something else? Well, first, go to YouTube and make sure that someone hasn’t already done a talk almost exactly like the one you want to propose, because I’m pretty sure you’re going to find lots of them. So find a unique angle on, say, personal security and IoT. Don’t just go for the same thing that everyone else has done and, you know, regurgitate Matthew Garrett’s excellent blog posts on the subject. So don’t do that. But when you do finally come across an idea that is a unique perspective on the latest hot shit, please, for love of God, tell me audience takeaways. Don’t just say, hey, this is really cool and I’m going to talk about it. That’s nice. My conference is not the place for story time. That’s where you go to the bar and you talk about things. But my conference is where people are paying money. Okay, my conference actually is SIGIL, Seattle GNU/Linux, and people don’t pay money because we’re free as in beer, um, and we’re free as in speech. But the other conferences I help, people are paying money. Their employers are sending them there to learn shit. And yeah, they might also be having a lot— a great time. But the bottom line is they have to learn shit. So if you’re not telling me what they’re going to learn, I’m not going to waste their time with your talk. So if you can’t literally put in your abstract, by the end of this talk, the audience will know. And then give me bullet points of 3 things that they could do after the talk that they couldn’t do before. And if you do that, you will be better than 95% of the talk proposals that I see.
Matty: [00:36:57] So I’m gonna— I’ve got a kind of one follow-up thing, and then I’m gonna let you, uh, go. I’m gonna give you, give you, give it a chance to rant if there’s anything else you want to rant about, because I love your rants. So you just said, you know, in a talk proposal, say the 3 things that you’ll be able to do that you weren’t able to do before. So what are maybe 3 things that after someone reads your book, they’ll be able to do that they weren’t able to do before?
VM: So after they— shit, man, you put me on the spot. Excellent, very good question. And I think I need to prepare a better answer for this, so I’m just gonna ramble on for a moment and try and—
Matty: Well, I’ll fix that. We’ll fix that in post, so it’ll look like you nailed it right away.
VM: No, no, no. I need people to know that we all just make shit up as we go along. I don’t care. I’ve been in this industry for over 20 years now, and honey, we all do this. It’s fake it till you make it, and you’re always faking it. So, 3 things people will be able to do with my book afterward, after they read it, that they couldn’t before. Number 1, they will be able to find a project that is a good fit for them, not just any project. Pro tip, it’s not going to be contributing to Linux. Number 2, everyone can do a PR, who cares about that? Number 2, you will be able to accept feedback in an empathetic way. Number 3, you will be able to give feedback in an empathetic way. Because communication and people is really the key to all the free and open source software. And a lot of the book is dedicated to how to communicate in a way that the free and open source software people will expect. So you’re able to be more successful with your contribution. And feedback is very important in that.
Matty: [00:38:42] Great. Those are— I’m looking forward to that because I could sure use some help with those things. So as we kind of come to wrap up, is there— are there any, any things that we didn’t cover that you want to make sure that we share with our listeners on this topic?
VM: Oh, I know you have a lot of opinions. Oh honey, I have opinions with a capital O. So, you know, specifically, it’s not like I came here with a soapbox beyond, hey, I’ve got a book and it’s really cool. Could you buy it please? Because it is really cool and I would like you to buy it please. And you can do so today. And if you do so today, then when it comes out in October, you get a nice little email saying, hey, now that you’ve bought it in ebook, do you want to have this small fee and get the hard copy? So, if you want to do that, that works. But, you know, I just really think that, I mean, we as individuals, some of the questions I’ve been fielding for years are always, how do I contribute to open source software, and how do I find a project to contribute to? And we in open source, we have let people down. That we are 20 years on for open source and nearly 40 years on for free software, people are still asking this fucking question, that’s our problem. We as a community, we as a group, we have let people down by not making it easier for them, by not making it obvious how you find these things. We are just so head down in our little projects dealing with our stuff that we haven’t picked our heads up and looked at the big picture. The big picture is we’re drowning. If you look at the GitHub State of the Octoverse study that comes out every single year, every single year there are literally millions of new public repositories on GitHub alone. That’s just GitHub. That’s not counting for GitLab or Bitbucket or all of the independently hosted Open source project repositories, right? That’s millions. And if you look at those millions, yeah, they’re just public. Maybe only half of them are open source, meaning they’re using an OSI-approved license. Okay, maybe half of those are not forks. You’re still looking at several million new open source projects every single year on GitHub alone. Jesus Christ, people, this is not sustainable. We have to make it easier for people to contribute. Otherwise, we’re just going to crash under the weight of our own success. So, we can do better. And if you’re a contributor, read my book and contribute, please. We need your help. If you’re a maintainer, read my book and learn how to make it easier for people to contribute, because we’re just all going to burn out. It’s, it’s not a good scene I see coming in a few years. I guess I did have a rant. I’m sorry.
Matty: [00:41:34] You did. I enjoyed that. That was fantastic. Great. As usual, if you are looking for— DevOps Days has a bunch of open CFPs, so if you go to devopsdays.org/speaking, you can check those out. There’s still a bunch left for the rest of the year and always coming up. If you go to restdevops.com/foss, we’ll have this episode’s show notes. You can sign up for our newsletter, see all the rest of the DevOps stuff you could ever want. If you go to restofdevops.com/itunes, you leave us a review in the iTunes Store. That helps other people find the podcast, apparently. Vicki, thank you very much for joining me today. This was a great conversation.
VM: This was great. I love chatting with you, Matty, though. You make it easy.
Matty: Super fun. I’m Matty, @mattstratton on Twitter. This is the Rest of DevOps, and remember, There is always DevOps in the banana stand.
