 All right, good to go. All right guys, thank you for your patience, technical difficulties are always fun. So we're going to continue this track. Amanda Folson is going to be talking about how you can use open source even if you're, or participate in open source, even if you are a close source company. So without further ado, let's get started. Thank you. So sorry for the delay. So fun stuff, we're going to run this off of two laptops. How many people does it take to give a presentation? How many laptops does it take? So I'm not breathing into it. All right. So just to get started, who am I? My name is Amanda Folson. I'm a developer evangelist at pager duty. That's a fancy way of saying that I am a professional conference attendee. I pretty much go around to things like this. Yeah, basically, and give talks just like this. My job is to interface with people, write documentation and things like that. I grew up around computers. My dad was a developer in the 90s. So I kind of grew up around like visual basic and some, even some C sharp in the early years, things of that nature built my first computer when I was around seven with some help from my dad, of course. So I've always kind of been into the computer thing. I've always been tinkering with things. So I would say that I am also a professional tinker. That's also a huge facet of my job. In middle school, I was making websites as you do. I was on neopets and a few other things and learned some HTML. And I was like, you know, I really want to make my own copy of this. I had some problems with neopets. You know, nine year old me was like, this is stupid. Why does this work this way? How can I make my own? So I figured that out, found PHP, made my neopets clone. Funnily enough, I still have the source code for that. It is the most awful thing in the world, but it still exists. So it's kind of cool. I really kind of owe my career to open-source software, too. I continued doing PHP, eventually found IRC channels, which is great. Got involved in some IRC development and worked on a project called ANOPE, which if you're not familiar with IRC, it's Internet Relay Chat, old school chat system. And ANOPE is a set of IRC services. So it allows you to do things like register channels, register your nickname, all of that fun stuff. Started hacking on that. And found some weird issues, particularly with a MySQL issue that I ran into. And I was like, hey, you know, this is broken for me. Can I submit a patch to it? And they were like elated that anybody in the world would want to submit a patch to this thing. It was really cool. And eventually they gave me commit access. Oh, God. No. Okay. This is going to be a fun one. Yeah. So started making changes, got commit access after submitting several, several patches to this thing and just was kind of able to do whatever I wanted. Fixed on MySQL issue that was causing a crash. Turns out it had been causing a crash for a lot of other people. Just no one was reporting this bug. So I found it. I fixed it. It was great. And from then on I was kind of addicted to open source communities and kind of explored, you know, hosting websites and things like that. And eventually wound up exploring a whole bunch of other technology. I needed a web server to host my crappy Neopads clone. And eventually got a job as a tech writer, which exposed me to even more stuff. So it's kind of, kind of been all over the place. Kind of been doing this open source software thing for a while. And like at pager duty, I work with Jekyll. I work with Ruby. I do some JavaScript stuff, even doing some PHP stuff. And simply wouldn't be here today without some awesome open source software. Forgive me while I change this in two places. So what is open source? There's actually a lot of confusion around what open source is and what it's not. So people think, oh, you know, open source is just giving it all away for free. And that's simply not true. There's a ton of licenses. This isn't releasing something as open source. It means releasing it under a permissive license for the greater good. It allows people to adapt and re-release your software. Open source initiative and get hub, break down the licensing thing really well. I'm not going to get into that because it's just a crazy subject. And that could realistically be its own talk. And you're sure to find one that will work for you, even if you're worried about IP law. There are licenses that cover intellectual property. And basically that you retain ownership of your source code without giving it all away, giving away all of your ideas. And licensing, super, super important if you want other people to use your code. Whether that's including your project in their own or building on top of it or whatever, without one, they technically can't use your software without your permission, even if the source code is put up on GitHub. So licensing, super, super important when it comes to open source software. Putting it all out there, like I said, allows people to adapt and re-release your software. You know, people will do bug fixes. They will fork it, add new features, do their own releases. I don't know if any of you follow the Node project, but that kind of split and then re-merged. That was a big deal. So things like that happen all the time. Wouldn't be possible without, well, licensing and releasing the source code. And all of this can be done at a global scale. So if you open source your project, you're getting access to literally millions of people. I'm not saying millions of people are going to work on your project, of course, but you know, you might get a few thousand. So you can go from five people working in-house on something to 5,000 people. That's actually not that unrealistic. Some of these larger projects, they have thousands and thousands of committers and thousands and thousands of commits every month. Some people are doing this in their spare time. Some people are hired to work on open source full-time. Can absolutely make a career out of it. Other times it's just people using a tool who want to make changes upstream. And honestly, very few companies can afford to hire the amount of diverse opinions you will get on these projects. Very few companies can afford to hire 5,000 developers. But by open source and something, you kind of get that for free with very little overhead on your part. Come on. So what open source isn't is not giving it all away for nothing. You're giving it away in exchange for out-of-house development. And that affords you so many awesome things, which I will get to in a second. Some people think that giving it away is giving away your bread and butter and your company is going to go bankrupt and all these things. That's really not true. Anybody familiar with OpenStack in here? Okay, a few people. So that's a relatively large project. Rackspace started it and was basically like, here you go, and it runs part of their infrastructure. And there's still a billion-dollar company, despite releasing that. You can basically spin up your own version of Rackspace if you wanted to using this utility, and they don't care. They're like, have it. And they've actually benefited from people taking it over and adding new features and things like that. It's become this huge, huge ecosystem. Parts of Windows and Azure, they're open source. Microsoft is still fine. They're still doing all right. Apple has started releasing things. They've really swift. They're still doing okay. So granted, they are a hardware company, but you can release various aspects of things and not go bankrupt. So like I said, you're exchanging the source code for rapid development. And this is especially true at larger companies. If you're at a company that's got some serious firepower, you're a well-known name and you release an open source project, you're guaranteed to get a few hundred people interested in it immediately. Thousands of commits per month on some of these projects, and you can't always buy that. Maybe you can if you're Microsoft, but if you're at a smaller company, you can't buy that kind of publicity, really. So giving it away to someone who can use it and modify it to suit their needs. That's huge. That's key. Letting people scratch their own itch, so you don't have to. Essentially, you're getting people to come work on this thing for free. I like the scratching gesture. And you're not giving away your business. So there's so much more to a business than the source code you release, of course. There's marketing, there's sales, there's how you market your thing is super, super important. So never underestimate the power of Lazy. Lots of people can't and won't self-host projects like this. Especially if it's a project that's really hard to set up. Lazy makes a ton of money hosting Jira and Confluence and things like that because people simply don't want to put in the effort to host it themselves. And that's huge. So never underestimate that. So I talk to people and they're like, oh, well, we can't do that. And my first response is, well, why not? They're all like, oh, my gosh, we're going to lose control. We're going to go out of business. All of these bad things will happen. Our competitors, they're going to steal our stuff and we're just going to go bankrupt. And that's really not usually true. So I'll give you an example. At PageDuty, we have this messaging pipeline. It's pretty robust. It's very reliable. And it's kind of our secret sauce. We could realistically release our web panel. Nothing super secret about that. So there are times when you do kind of want to keep things closed source just to kind of protect your trade secrets, things that competitors absolutely would benefit from if you released them. If we were to release our web panel, it'd be kind of great because it would allow people to fix their own pain points. But if someone wanted to steal that, if they really want to steal our front end first of all, they kind of can anyway because it's HTML and JavaScript. But also they'd have to build the entire back end themselves. And most people really not going to be bothered with that. If there's an existing tool that works and is cheaper than putting in the dev time, they're just going to, they're going to roll with that, guaranteed. So talk to a ton of people and they're still not convinced. Oh, well, there's no value to open source software. And you just, all I can really do is shake my head. And they're typically telling me these things from their Windows PC or their MacBook, both of which can send open source libraries by the way. Or they say it on Facebook and Twitter, which are making use of like PHP, Scala, Ruby, Apache, Nginx, all those things. They're saying it on their, I actually saw someone blogging on a WordPress site about how open source software was not valuable. And I just wanted to be like, we need to have a little talk. You are benefiting immensely. You are allowed to spread your opinions by virtue of open source. And if you hear this, I encourage you to challenge people on it, by the way. Call them out on it because I think we have a lot of work to do in terms of telling people how prevalent open source software is, just as an aside. You know, your smart TVs, some of them are running Android, cell phones, you know, people are making use of TCP IP libraries. Like nobody wants to write that crap themselves anymore. Same with HTTP magic. Like there's all sorts of things that everyday devices are taking advantage of. Absolutely encourage you to call people out on that. Another point, we have to hire someone to maintain it. Well, so what? It's still cheaper than multiple in-house engineers working on something or contractors or anything like that. If you're open sourcing it, I mean you have access in theory to millions of people. There are millions of potential developers that will hop on this project. And of course, if you build it, they're not necessarily going to come to it overnight. You might have to put in some marketing. You'll have to get it off the ground. You'll have to nurture the community that kind of evolves around it. But for the most part, you know, if you have to hire one person to gain access to literally thousands of people who can potentially work on it, isn't that worth it? Yeah, absolutely. So it's not true that you will always have to hire someone to maintain something for you. You know, you might find that the volunteers will do the heavy lifting for you. And this is true at a lot of some of the projects that Red Hat does. You know, there's a ton of volunteers that are just committing code. Some of them are Red Hat employees, but a lot of them aren't. So they kind of manage the direction and do a lot of the feature implementation stuff so that you don't have to, and that's awesome. But it's not uncommon to see community managers or developer advocates or something in a position like this. Basically to kind of guide the community and guide the project in the direction that it should be going, but also to kind of interface with the community and bring that back within the company and say like, hey, the community thinks we need to go in this direction. Maybe we should try that. Maybe we should listen to them because they're probably in a better position to tell us that than we are to tell them what they need to be doing. So you just provide the community with the guidance and take it from there. You don't necessarily need to hire somebody. So if anybody's like, oh, well, we can't do open source because then we have to maintain it. It's like, well, yeah, but also, no, not so much. And then my favorite, but what about my bottom line? People love their money. They want to hold on to their money. And this is probably the number one thing that I hear about when I'm talking about open source and in particular giving this talk. People are afraid of losing money, which is absolutely healthy. You should be worried about losing money. They want to know that they'll stay in business. Also a pretty healthy opinion to have, right? But if your idea is good, people are going to build on it. The best part is even if they build on your idea and don't release the source, you still might benefit from that. You can see what the market wants through the work of others immense value in that, immense value. You might run into some leachers, some people who just want to take your code and mess around with it and not actually give back, or maybe they want to rip your code off, use it as their own. But they're really not that successful with it. I don't know a whole lot of stolen code projects that surpassed the parent project that they were forked from. You don't really hear about that a whole lot. Worrying about leachers is not a complete waste of your time, but if that's your main concern, like I'm here to tell you, it's probably not going to be that big of an issue. You'll see them modify it. My favorite is when people, they will fork a project and then mass delete all of the headers with the licensing information, but all of that history goes into GitHub so you can actually see them deleting the comments and the copyrights and leaving that history of that behind. I love it when people do that. It's like, are you really? So yeah, most of the time they're not successful. Their project is likely not going to make waves that are bigger than yours. Going back to Rackspace, they're selling you an experience. There's so much more to the product than the code. They're selling you their quote-unquote fanatical support. Everybody's seen those ads where it's like some dude that's like, I've been a racker for 16 years and I provide fanatical support. That's really what they're trying to sell you. The infrastructure, that's important, but at the end of the day, it's a server in a rack somewhere. Anybody can kind of do that, really. Well, mostly. So even if someone takes your code and creates a competing business, there's actually no guarantee that they can provide the same experience that you can. Experience is huge. People are an important factor in this. It's not just the source code. So if you're worried about your bottom line, there's so much more involved in worrying about your bottom line when it comes to this stuff than just releasing your source code and assuming that someone's just going to steal it and put you out of business. Someone will steal my idea. Well, I've got news for you. I can't tell you how many times I've heard this from people with just ideas that are really not that original, not that good. Your idea is probably not that unique. If you're creating a cloud on OpenStack, you're joining literally thousands of other people who are doing the same exact thing. Some control-metal stuff might be different at the end of the day. Like I said, it's just a server in a rack somewhere serving some stuff that's not all that unique. Facebook isn't unique. Social networks were run long before Facebook was in the picture. That's been a thing pretty much since the internet. Photosharing was a thing before Instagram. Search engines existed long before Google was ever a thing. So never underestimate the power of marketing and positioning when it comes to open-source software. And I think Red Hat does a pretty good job of this. They have lots of money to throw out the marketing and development of these things. And it works for them. You can pretty much get anything that Red Hat does for free unless it's support. But yeah, it's free. If you want to set it up, you absolutely can. But if you don't have the time or the patience, they have people that will help you do it. Another spoiler. Nobody really cares about your idea as much as you think. If they did, they'd be out there building it themselves. And it happens from time to time. But in the end, one project usually pulls ahead of another. Good example of this. Linux versus Herd. Who do you think is winning that? And value is very subjective. What you value may not actually be all that valuable to someone else. So if you're worried about someone stealing your idea, first of all, your idea probably not that unique. Second of all, you know, putting your idea out there, you might get some opinions on it that you didn't even think of. Someone might say, hey, why don't you try going down this route or try going this way? Maybe you need to implement this feature. And you just never know what's going to come out of that. So in addition to code, you know, the bug fixes and things, you get some other benefits by releasing your software out there. People can get in. They can get answers. They can get on with their life. This is especially true of technical people. They don't want to talk to sales engineers or anything like that. Not interested in traditional sales and marketing. So in my experience as a developer evangelist, you know, you run into people who they just want to go in. They want to tinker with it. You give them documentation and they just want to go do their thing. Most people who are playing with this sort of thing, they really, they're not all that interested in getting your marketing pitch or anything like that. If people have some visibility into your product, you're opening yourself up to more feedback. So one of the things that we do, which I will cover in a little bit more detail, is we invite people to give feedback. Rigorously. We send them emails. Anytime someone creates an API key, I email and I'm like, hey, what are you building? Do you have any feedback for us? And the email campaign in particular has a 20% response rate, which in this industry, pretty much anything above 3% is phenomenal. But if you're building some transparency, people will love to give you feedback and some insight into how they're using your product and what they're doing, what they hope it does, what it's not doing, that's hurting them, things like that. And you win either way. If you make a sale, great. If you don't make a sale, hopefully you've got some really good feedback from that interaction. And we're, as a collective, the technology community is pretty vocal about what we like and what we don't like, especially what we don't like. So you're extremely likely to get the holes in your project figured out as you're talking to people because they're going to be like, well, it doesn't do X, Y, and Z. I really need X, Y, and Z because of A, B, and C. And that feedback is super, super valuable. But if they're in their tinkering and they see that it works for them, then you might make a sale. And you might make a sale through some non-traditional sales funnel. Like someone just might be like, OK, well, I see, I can get this information out of your API. I can put this information into your product via this API. That's good enough for me. I'm going to sign up. I'm going to do my thing. Leave me alone. That's great. So when we know what to expect, we're a lot happier as technologists. I don't think everybody's first instinct is to go to the documentation. But definitely if we're tinkering with something and we can kind of pull bits and pieces out of it that we like, we're typically a lot happier. Another important thing when talking about open source is that one size doesn't necessarily fit all. It works for you. Not necessarily going to work for someone else. As one person, open stack is complete overkill for me. Maybe I just need a Zenbox or maybe I just need something like Vagrant. Maybe I just need a couple of Vagrant boxes to spin up. I have the freedom to explore all of my options, which is great. As a result, I know more about these products, and especially in my line of work, exposure to different things is key, and I can help other people find solutions for themselves. It's a very positive thing to have software diversity here. If the source is open, I also have the freedom to tweak it, which is how I really got into this. I was playing around on IRC. Something was not working for me, and I was like, okay, well, you know what's wrong. I did some stack traces, got into Vagrant and all of that fun stuff, and was like, okay, well, you know, here's the fix. I'm good to go. So I started making modules for functionality that I needed, and now the users of the software, since these modules got incorporated into the core, you know, they're all benefiting from those changes too. So, and it was something, the MySQL thing, like I said, they didn't know that that was an issue. People were not reporting that bug. Turns out once that fix was released, then suddenly a whole bunch of people were like, oh my gosh, thank you so much for fixing that. That was driving me nuts for months. I've been trying to get it to work. Didn't understand why it wasn't working. So it was great, and they should be able to tweak it. Their changes might even benefit you. I can't even tell you how many things that I've touched that get continuous updates that are then better for me. So like I said, once I might not fit all, it might fit many, and you might find that out just by releasing your software and having people tweak it. And if it'll fit many more, a few users can establish quorum on what they need. So you can get people talking. We have a community site. Some people have gone back and forth on it. And they kind of reach a consensus on some of the prioritization and the features that they need within our product, which is really cool. So kind of the community and the customer base gets to decide really what we're doing, which is kind of cool. And some of the changes we roll out, they might only benefit one person or they might benefit thousands of customers. You just kind of never know with that sort of thing. Another benefit that I think is really overlooked is information transparency. So too often we're stuck in our own silos and develop like these huge blind spots in our product. So we're so focused on one thing that we kind of get tunnel vision. And we don't necessarily notice the holes in our product. So trying to stay ahead of the market can result in some serious tunnel vision. So like we know what we want, but we don't always know what customers want. Even if they give us feedback, are we acting on that? So letting the customers have control over product direction is actually an extremely good thing. They often know more than you about their own needs. So letting them have control is kind of giving them what they need in order to succeed. So as you're trying to apply some of this open source stuff, just be mindful that even if you're leading a project, you don't necessarily know what's the best thing for that project. You really need to listen to your customers and figure out what they want from your project. And besides, sooner or later, someone will make an open source alternative to your product. Even if you make a good product and keep the source closed, someone's going to be like, you know what, I don't like that this is closed source. I'm just going to do it myself. That's kind of the world we live in these days, and it's great. Open and Libre Office are great examples of this. Microsoft Office is pretty much, or was pretty much essential for business needs. You had to have Excel, you had to have PowerPoint, had to have Microsoft Word. Even in college, they're like, oh, well, you have to submit your assignment as a DocX. We're not going to accept anything else, no PDFs or anything like that. And there are open source social networks. There's an open source Facebook. I feel like open source Twitter APIs are becoming more common. So I deal a lot with API design and give a lot of talks on that. And almost all of the examples I see these days are either a four-square clone or a Twitter clone. So there's even open source alternatives to those. If you want to set up like four-square for just your group of friends, like you can absolutely do that. You're probably not going to overtake four-square at all. But the point is, really, you can do it. There are even open source operating systems that can look and feel like any Windows or Apple's box. I'm sure we all know of one or two or five. So these projects, their big selling point is that they have market share. So it may as well be you from the start that gets that market share. You know, go out there, release your thing, launch it, get people to love it, which of course is easier said than done. But you can get that market share from the start. And that's really kind of your competitive advantage when it comes to open sourcing your software. So, okay. Let's say I failed to convince you to open source your software at your company. It happens. You know, going back to PagerDuty, we would be stupid to release our ultra-reliable alerting pipeline. I mean, that's kind of a huge thing for us. We've invested, you know, thousands of hours of engineering time. Reliability, absolutely a competitive advantage. So we don't want to release that. But we do some things internally that are actually kind of cool. So one of those things is internal transparency. We maintain a wiki. And so before coming to PagerDuty, I hated wikis. You know, they're never up to date. They get kind of stale. They're spam magnets. Anybody maintain a wiki here? No? Okay. I can't hear blessings. But they tend to be kind of awful. But PagerDuty actually has one that's relatively good. And occasionally, you'll find some crafty information on there. But for the most part, especially in, like, the product and engineering side, everything's up to date. You can go in there. Like, I'm not an operations engineer, but I can go in there and see some of the remediation steps for when specific alerts come in. Things like that. It's really cool. We have this concept of demo days. So if you want to see what's going on with the product, you can come to a demo date. Everybody in the company is invited. They are recorded. There are notes that are drafted up. Things like that. A lot of the meetings are just open to everybody. So especially in, like, product and engineering and marketing and even sales, you know, if you see an invite on someone's calendar and you're like, you know what, that actually sounds pretty interesting. You can pretty much invite yourself to that with very, very few exceptions. We also have a policy, at least on my team, of no meetings over 30 minutes. Anything over 30 minutes requires an agenda, and even if it's under 30 minutes and doesn't have an agenda, you are allowed to decline it, no questions asked. Or you can hit someone up and be like, hey, I really need an agenda for this before we can actually, you know, talk about it. So we also do open training. So it doesn't matter where you sit in the company. We have scrum training. We have Kanban training. Things like that. You're allowed to come to that. Regardless of whether or not you're working on product or engineering, if you just want to learn about Kanban, like, have at it, we will teach you Kanban. We will get you a certified scrum master certificate if that's what you want. We're really big on that. And another cool thing is executives have office hours. So it's not necessarily a complete open door policy, but it kind of is. It's a scheduled open door policy. So anybody can come in and be like, hey, I want to sit down with the CEO and talk to him about our product roadmap. And you can do that. And he will be receptive to it. It's absolutely great. So I mentioned open information. This is actually my Kanban board at work. So I had to blur the things out because some of them contain customer information and the sort of thing that you don't really want to open source. I don't want to tell the world who our customers are. But this is public to the entire company. Anybody at the company can open this up and be like, oh, OK, well, here's what Amanda's working on. But it's kind of cool. So you see the guy with the green avatar there. That is an intern on another team that answers to someone else entirely. He asked what I needed help with one time. And I was like, oh, you know, go look at these tickets and see what you can take care of. And so since I'm an evangelist, I send a lot of t-shirts and stickers out to people. It's just one of my routine day-to-day things. Reply to a lot of emails. So Godham started working on some of those. And then there were a lot of, like, little code sample tasks that were left over. And he was like, you know, what would it take for me to be able to do these? And I was like, well, you know, he pretty much hit me up. He's like, OK, what specifically would I need to learn in order to be able to do these things? So we taught him JavaScript. And so this is a dude who didn't even know something like a terminal existed who is now a shipping code. He's got some little code snippets running in production now just because he saw a Kanban board at our company, which is really, really cool. So he's working towards becoming a junior dev, which is great. So through open information, he learned new things and now he has some stuff in production. That's something he can put on his resume and take to another company, right? And this task that's over here in the done category over off to the side was something that someone else decided to do over a weekend. It was just a little documentation fix. I didn't ask her to do it. She just up and decided, like, hey, I am blocked on this. I want to do it this weekend. And she just went ahead and did it. And I didn't have to do anything. It was great because my board's open. Not to say that I want to encourage people to do my work for me, but it's kind of nice when people can collaborate on these things and, you know, pitch in and help, especially I am currently the only evangelist at PagerDuty kind of swamped, especially doing all the public speaking and things like that. So it's really nice when people can step in and be like, hey, I know you're out on the road, but I really need to fix this documentation right now and then just go do it. So we're also big into cross team functionality, which you just saw. These people, they're not even on my team and they're contributing JavaScript and documentation fixes. So anybody can contribute anything and learn the things that will allow them to contribute via the training or the outside study or whatever. Absolutely not saying that anybody can be CEO for a day. There are certain things that, you know, use some common sense here, like, don't let your intern be the CEO for a week. Obviously, definitely not condoning that. You know, not saying that everybody is allowed to go to the board meetings or anything like that. It is okay to have some need to know things. Even open source has some need to know things. It's just like, it's okay to not release your bread and butter. You can absolutely give back if you're using open source software and not open sourcing your stuff, you should absolutely be giving back to the communities that are helping you out, especially if they're helping you make a lot of money. So the teams own the projects. They establish specific guidelines. I own the documentation at PagerDuty. I have a few simple rules, which are pretty much no force pushes. I don't want to see any of that. They're actually prohibited through GitHub, which is awesome. No deploys until a test pass. Yes, we actually have tests for our documentation. If you're not doing that, it's fun. I'd love to talk to you about it. And everything must be edited and signed off on before going out. Little basic things. And people follow these rules all the time. If somebody, they had some sort of like issue with things getting clobbered in their repo and I was like, hey, don't do that anymore. And they were like, hey, yo, I'm so sorry. They rolled everything back, fixed it. It was good to go. More often than not, people don't want to inconvenience you by making you follow their workflows. So the force push thing, not a huge ask from people. So I handle the bug queue, review the pull requests, merge things as needed. But many other people are involved in making that project run smoothly. And that's something that we do. We are big on transparency when it comes to us screwing things up. So we have public blog posts about things that have gone sideways. But internally, we recognize everyone makes mistakes. This is one of the scariest parts of transparency is letting everybody see when you screw something up. It's scary. You think people are going to judge you. People are going to be angry. And yeah, you know what they might. As I was showing Captain Intern something, I took down our entire developer portal and now he knows not to do that. So my screw up was a lesson for him and how not to deploy documentation. So you never know when things, when people are going to learn from something like that. We also have a concept of blameless post-mortems. No one is blamed, no one is attacked, no one's fired unless you're just blatantly reckless, which most people are not, most people are reasonable. And really, no one should be fired for a bad deploy in this day and age. It happens. Hopefully you have some tests that are running, but sometimes, stuff happens. We all know that. These failures are just great opportunities for us to improve and they're treated as such. Like I said, we even released them to our customer base. Like, hey, we ran into this weird thing with Cassandra, like this stuff happened, it sucks, but here's what we did to triage the issue, here's what we think happened again. So it's absolutely great. And if you could take one thing away from this talk, it would be this, really learn from your failure, adopt a policy of blameless post-mortems, stuff's going to happen, everybody can learn from that. So what are some other things that we can open source? Like if we're a company, we're a SaaS based company and we don't want to give away our entire SaaS product, there's all these other things that are kind of attached to a company that you can actually open source. So documentation, super important. We have API docs, tutorials, things like that that allow, and we allow other people to contribute to them. We've had people add their own code samples to our documentation which has been great. Things that we hadn't even heard of. I just found like an Erlang library for pagerduty and I was like, hey, you know, you still maintain this and he was like, yeah. And I was like, okay, I'll add it to the documentation and he just went ahead and did it himself. It was awesome. I didn't have to do anything, he was just like, okay, I'll add it to the documentation and it's great. Because it allows people to kind of dictate where the documentation goes, they know what they need, so why not let them help out with something like that. There's a whole bunch of libraries and tools. These are usually not secret sauce that you can release. Other people might find them useful. Things like I wrote this really crappy Perl script like six years ago to help me manage my DNS zones and some dude was like, hey, this is a great thing and it's now maintaining it himself. I'm like, great, that's awesome! Go do that thing that you want to do. People might find them useful. Even something like we released an open source cron thing. People have managed their crons and that's great. But they might find utility and are particular cron utility. And they have been. There's a bunch of stars in the repo and things like that. You never know what sort of things people are going to find useful. of your bread and butter, I guess, just release them. You really don't have a whole lot to lose in cases like that. SDKs, also key, again, the people who need this should be able to tell you what they need or modify it themselves. It's great when you see, you roll up to a new utility and you see, oh, they've got this API. Well, I'm a PHP developer, do they have a PHP library? And then they do, and then it's a nice PHP library because the people developing it are actually PHP developers, not like some Java dude who has lived in Java land who is trying to do the PHP and doesn't necessarily know the nuances of the language or whatever your language of choice is, right? Frameworks, same sort of thing. Absolutely release your frameworks. I would sort of put OpenStack in that category where it's part of their business, but it's not necessarily the most important facet of their business. So go ahead and release stuff like that. Same with modules. There are people that release all sorts of modules for all sorts of things and it's one of those things. Again, you never know who's going to benefit from something like that. So we got started a little late. Thank you so much for your patience with that. Hopefully you've taken something awesome away from this talk. I would love to hear your thoughts on it, so please feel free to reach out to me. Changing things in two places. So thank you so much. Are there any questions? No questions? Okay, we'll start over here. Sure, so the question was, are there any sort of utilities out there to help you release certain portions of your project? And the answer to that is maybe. So there are different package repositories. There's RubyGems and things like that that you can release or you could get into Composer with PHP. So there's all sorts of things like that that would help you. The downside is that you have to kind of modularize your things in order to ship them to people. But yeah, definitely. Or depending on how your app is architected is really gonna kind of determine how you do that. In the back, have we found that it helps us recruit? Actually, a little bit, yeah. We get people all the time. We actually have a core chef contributor on staff and he was like, yeah, this is kind of cool. Pedro is using chef, let's get a job there. So yeah, absolutely. Huge, huge recruitment tool. And I would encourage you, if you are interested in hiring developers, open source something and let them go nuts over it. There's another question right here. Some parts of the code might be covered by patents. How would you deal with that? That's really gonna depend on your company. I feel like that's getting into legal territory and you probably wanna talk to a lawyer about that. Would definitely encourage you to talk to a lawyer about that. But if it's your intellectual property and you've got a patent on it, patents are good for X amount of years. In theory, you should be able to release that and be covered by virtue of your patent because if somebody starts releasing stuff that violates your patent, you can go after them. And you see that all the time, people fighting over rounded corners and whatever in name crap, right? So yeah, you should be covered. Hopefully you will not need to sue anybody, but you might, would definitely encourage you to talk to a lawyer about that. Another question? So he's saying he has an issue with submitting patches that just kind of get into a black hole and how I would approach that. Getting permission to work on an open source project. So I have a policy of I don't ask for permission if it's open source, like I'm gonna submit a PR or I'm gonna hit a mailing list with a patch or whatever. And yeah, sometimes they get ignored. I've definitely been ignored by projects. Something that has worked for me is I just keep submitting something until someone pays attention. I get at people on Twitter, I will highlight them on GitHub or whatever, find the Slack channels or IRC channels that they're hanging out on and just kind of, I don't wanna say harass, but aggressively point them in the direction of my patch or my contribution. And that typically works pretty well. But yeah, sometimes it's unavoidable, especially if it's like a project that's not really maintained anymore. That's gonna be a lot harder. And that's probably getting into fork territory at that point. Do you have like a specific example? Oh, okay. Do you have a comment on that or? Okay, huh, good to know. Yeah, so specifically, good to know. Yeah, so specifically fighting your legal team to be able to contribute to open source. Honestly, in something like that, I mean, I can't very well say like, oh, we'll just go find another job. That's not feasible, it's not realistic. I would just keep pushing. Eventually they will either give you an answer, which is no, or get so tired of you poking them that they will let you do the thing that you want to do. I feel like I have spoken to people, particularly at larger corporations where that's a thing, where the company has a policy that says, any source code that you write at work, even if it's in your spare time and touches anything related to work, like they have ownership of it, and they just keep fighting. And eventually some people will get an explicit like, no, you know, we own everything, you can't do anything, or we'll give you permission in writing to do what you want to do. Yeah, no problem. Any other questions? Last chance? All right, thank you so much.