Bridget: [00:00:00] So, like, of course, people contribute to open source because they’re excited and passionate about it, but people also like to sleep and see their families.
Michael: It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I am your special guest host, Michael Hedgpeth, @michaelhedgpeth on Twitter.
Matty: I don’t remember authorizing any special guest hosts here.
Bridget: What’s going on here, Stratton?
Matty: Yeah, whatever. We’ll do it live. It’s DevOps. We’ll do it live, Michael.
Michael: What do you mean you’ll take us out? We’ll do it live.
Matty: Yeah, we’ll do it live.
Michael: Arrested DevOps is brought to you by TenthMagnitude, a company that figures if you’re listening to this podcast, you must be pretty cool. I think 10th Magnitude is pretty cool too. I’ve been getting to know them the last few weeks as my wife Annie has been working with them, so they’re pretty awesome. They’re great with Azure, great with Chef, and all-around good people. You can find more about 10th Magnitude at arresteddevops.com/10thmagnitude.
Matty: [00:01:11] This episode is also brought to you by Hired. Hired is a platform for top developer jobs, and they love DevOps people. Developers get an average of 5 to 10 offers on the platform, all with just one application. And you get job offers and salary equity upfront before you interview, so you don’t have to waste your time interviewing for jobs you might not end up wanting. And Arrested DevOps listeners get double the $2,000 bonus just for signing up at arresteddevops.com/hired.
Bridget: Did you just say salary equity? Because that’d be kind of amazing.
Matty: Salary equity. I want my equity paid in salad.
Bridget: I want kale.
Matty: Said no one ever.
Bridget: Okay, this episode is also 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 plus a free t-shirt at arresteddevops.com/datadog.
Matty: [00:02:14] I also want to give a special shout-out to our friends at Kikura, who are letting me podcast from their office today. You can find out more about joining their team at kikura.com/careers.
Michael: Thanks, Matt. Today, for guests, we have Doug Ireton, who is a Senior AWS Chef Engineer with OneStrategy. Welcome, Doug.
Doug: Thanks, Michael. OneStrategy is an AWS consultancy focused on DevOps transformation and big data. I’ve just joined them recently in July. Before that, I worked 23 years in IT and 22 at large enterprises. So I’m happy to be here.
Michael: Thanks, Doug. We also have our regular host who will be our guest today, Bridget Kromhout from Pivotal. Welcome, Bridget.
Bridget: Hey, yeah, this is, this is gonna be fun. I’m looking forward to it.
Michael: Thank you. I think it’s gonna be fun too. And finally, we have Matt Stratton from Chef who is our guest host as well, our guest today.
Matty: [00:03:16] Sorry, I’m a guest guest.
Michael: Yes, I’m the guest host. It’s getting confusing.
Matty: Welcome out. Awesome. Well, this is— it’s always much more— it’s way more fun to be a guest on a podcast than a host, I can tell you that.
Michael: So yeah, so we should probably start out with what’s going on here, right? So at ChefConf, I attended a Doug’s presentation on open source and how to operationalize open source in the enterprise. And I had a ton of questions throughout his presentation, but unfortunately I was called away toward the tail end of his presentation and couldn’t really interact with him at all. And I started realizing that just what he was talking about was a fantastic topic. It would have been helpful for me to listen to a year or two ago, and it would be a great podcast episode on Arrested DevOps. And I started talking to Matt about it and realized that he’s also an expert, along with Bridget, on how to operationalize open source within organizations, and I’m really the one who has a lot to learn. So it’d be interesting, I thought, to ask them the questions since I have them, and then learn from Bridget, Matt, and Doug on how exactly to make open source work inside of an organization. A little bit about me, I am— I was on a few episodes ago. I am a senior software architect at NCR, and we do restaurant point-of-sale stuff, and we do ATM financial stuff. And retail, you know, like if you go into Home Depot and do a self-service, that’s our technology. And I’m in charge of making DevOps happen within our hospitality organization and worked with Matt a year and a half ago on bringing in Chef for NCR. So that’s how Matt and I know each other, and that’s how I’m involved with stuff. So what I wanted to do is just to catch everybody up who wasn’t in the room with Doug in his talk at ChefConf is just talk to Doug a little bit. Doug, tell us a little bit about the journey that you took in your previous company and how you made open source work and what outcomes you created from that.
Doug: [00:05:49] Sure, thanks, Michael. So, I think the first thing to say is that I was sort of the unofficial go-to person for questions about open source at Nordstrom, and that wasn’t an official title. It was just because I cared a lot about open source and interacted with several open source communities, including the Chef community, which is just fabulous, and I learned a lot from them. So, it was very unofficial, and I think for other companies who are trying to do this, I don’t know that it requires some sort of formal committee or title. I think it just requires people that are passionate about open source and helping their companies do the right thing. So, our journey, I think open source for a lot of enterprise companies is a very big culture shift, and culture change takes time, I think, is the big takeaway. The mechanics of open source are pretty straightforward. But as far as, like, going from— for Nordstrom, it took us about 4 years to go from open source contributions are allowed to open source is the default approach for fast-moving teams. So, I wouldn’t expect anything to happen overnight. So, just a brief history for Nordstrom. In 2008, we were using Red Hat Enterprise Linux, was sort of our only open source. Really, and no one went to conferences, really, and we didn’t contribute to open source. In spring of 2012, we bought Chef, which is really our first real, sort of real open source tool. And in fall of 2012, one of our VPs said, you know, contributing is part of using open source, and employees signed an intellectual property agreement. Which sort of explains, sort of work that you do for the company belongs to the company. And then in 2015, we had some devs who wanted to contribute to React.js, but they needed to sign a contributor’s license agreement. A lot of companies, including Chef and Facebook and Google, require a contributor’s license agreement, which just says that you that you own the intellectual property and you’re contributing it and you have the right to contribute that. So it took about 4 months to go through legal because we’d never done that before to get the Facebook Contributor License Agreement approved. They had a lot of questions. There’s a lot of back and forth. And it just— and then it required like 2 VPs’ approval. It was kind of a pain, but we did it. And And then fast forward to 2016, open source for Nordstrom is now the default for fast-moving app teams, and the Google Corporate Contributor License Agreement, because we were contributing to Kubernetes, that agreement was signed in a week because we’d done it before, and the legal team and the contract team were a lot more— they kind of knew the process.
Michael: [00:09:00] That was one of the things about your talk that was interesting, is how you were talking about how you socialized with legal directly and kind of created a partnership, and you didn’t really expect that, but once you had that, it was way more effective. You were way more effective at accomplishing what you needed to accomplish. So you want to tell us a little bit about that process?
Matty: Sure, I guess.
Doug: So yeah, I never— so this may sound strange, but We definitely had leadership approval for open source, but I never actually had a close relationship with legal, which I kind of wish that I had. The VP, I tried to approach them and they sort of rebuffed me a little bit and said, you should go talk to this VP. So, I went and talked to him and then I was sort of working on that relationship with legal and then he left. I think if you’re not at a technology company, your legal team may not be sort of focused on open source and may not sort of understand differences between licenses. I think ideally, you know, they should be involved and they should understand it. I think at the time, Nordstrom’s legal team was like, well, we trust this VP and we’re not going to worry about it because they had expertise in a lot of other things, but not necessarily open source.
Michael: [00:10:27] So, so the other thing that was interesting about your story just then to me was how you kind of started out with Chef, which is just a configuration management tool, and then that led you to using open source tools within your core development where you had to work with Facebook. So that’s generally not a a typical— that’s not what people would think. We’ll start with configuration management, and it will lead to developers using more open-source tooling. So, what was that like? I guess it was a culture shift, but how did your introduction into Chef get you to use more open source deeper into your company?
Doug: Well, I think the thing to realize is that, and as you well know, because you’re in the same position, Nordstrom is a very big company, and our team never used Kubernetes, nor did we use React.js. There were other app teams that were doing that. I think there was an evolution, as there’s just been a general evolution in IT, of this realization from the leadership standpoint that open source allows companies to move faster. And we’re sort of moving away from that, we’re just going to talk to a couple of large enterprise vendors, and we’re going to go through a 6-month process to choose some software. And now, as we hire new engineers and as leadership realizes that the primary thing we need to do is move fast, and open source allows us to move fast, there’s sort of a co-evolution of all of these app teams, especially the sort of more fast-moving app teams that are doing, like, frontend work or mobile work or API work, things like that, that open source tooling really allows them to move fast. Our use of Chef and other teams’ use of Facebook and Kubernetes, like React.js and Kubernetes, those are sort of co-evolved, I guess.
Bridget: [00:12:25] I would also say it’s not just the fast-moving frontend or whatever that can benefit from open source, right? Even like you were pointing out with Chef, with all your infrastructure stuff, with Kubernetes, with everything you’re doing with your platforms, open source is where this stuff is moving a lot faster. And working with a vendor who tells you, this is the only thing, like, okay, but is that only thing built out of open source, is the question you should be asking.
Doug: I would say that, for sure, at least at Nordstrom, there were some fast-moving teams, they were building APIs and building frontend mobile apps and things like that. And they were sort of the tip of the spear, the leading edge. As far as open source, but it’s definitely pervasive now at Nordstrom. And so backend teams are, it’s sort of open source first in a lot of ways, so.
Michael: Yeah, and from my experience, to your point, Bridget, like Chef has really helped me and our organization understand kind of the workflow, the community aspect, pull requests, the whole thing in terms of being involved, and it sounds like that’s what happened with Doug as well. But then there is this other aspect of it of, you know, you have to be very comfortable with a wide-ranging solution set that covers a lot of different people and not under one umbrella. And for a Microsoft organization, that’s a really big shift because you’re used to being told This is all there is. It’s Microsoft. It’s going to be easy under one umbrella, and the world’s changing, and Chef’s really helped us take those baby steps into being a community member like that. It seems like, Doug, you’ve already done— you did a lot of that journey at Nordstrom as well. So looking back— oh, go ahead, Matt.
Matty: [00:14:29] Well, I was going to say, I thought it was interesting that you started saying about coming from the Microsoft thing. And I was just going to say, I think that’s both Nordstrom and NCR, both of you coming from that is, again— and it’s not even necessarily just Microsoft, it’s enterprise platform in general— is the old joke. It’s like nobody got fired for buying IBM, right? I worked at a company where our sister company— like, for us, it was Microsoft’s the answer, what’s the question? And our sister company was IBM’s the answer, what’s the question, right? And what you run into in a scenario like that is, is you look to that vendor for all the solutions, right? Because you don’t even think that things can be componentized, made up of components, made up of pieces. And to the point of that, I can think of several occasions in both of those, both on the Microsoft and the IBM side, where as a customer, You go to the provider and say, hey, IBM, we’re having this problem with X. What do you have that solves X? IBM actually may even say to you, we don’t. We have this thing that’s sort of like that, but not really. You’re like, great, I want that. IBM is like, you really shouldn’t use that. That’s not what that’s for. Yeah, well, we’ll make it work. You end up then incurring all this tech debt, but it’s like, hey, but we bought the IBM answer, so therefore it’s fine. Or we bought the thing from Microsoft. I mean, I had that with BizTalk. Like, we built this crazy, ridiculous thing using BizTalk because it was the closest thing that Microsoft had. It was massive overkill for what we were doing, and we could have done it probably with some small open-source tooling that would have just done what we needed, but we had to buy the thing from our vendor. The good thing is that’s changing, I think. Yeah, but if you’re— and I think that if you’re starting on an open source platform, you probably already are more used to that philosophy of that I might get this from you, this from you, this from you, this from you. But if you’re thinking from more of a traditional enterprise vendor platform, you expect to want to live inside the box, whether that’s for the, the phrase that I hate, the single throat to choke, which a lot of CTOs and CIOs love, right? I want one person to go yell at when it sucks, or Because you believe that if I buy it all from Microsoft or I buy it all from IBM, it’s all gonna work together super well, when the reality, that’s also super not true, right? ’Cause—
Michael: [00:16:51] Yeah, and the thing that I’m dealing with right now within our organization is there is a desire to standardize stuff because efficiency, because NCR is a large organization, But that’s almost against the open source model that says, hey, you’re doing a project, what are the best tools for you? We trust you to make good decisions, bring those— bring that solution together and make it work for you and bring a lot of value out of that quickly. So how have you guys seen organizations appropriately deal with that and inappropriately deal with that? Challenge of centralization versus the broad community of tools that are available and people with different opinions?
Bridget: That’s a really, really big area of inquiry. So, I guess I’ll just say that I don’t think that having a large, well-composed, say, platform, like, for example, I do tech advocacy for Cloud Foundry, is necessarily in opposition to devs using small modular tools on their desktop. Devs can be using Docker, and you can run Docker images on Cloud Foundry. So, as long as you’re making your, again, open source and cross-compatible choices, such that you don’t have to use only the one giant thing for everything, I think there’s room for flexibility there. But I think, Doug, you were unmuting, so I know you have something to say.
Doug: [00:18:32] Yeah. So, I think you’re very observant there. That’s great. So, I think Netflix has a good example where most teams use Java, and maybe that’s not every dev’s favorite language, but there’s kind of a there’s a well-trodden path or a paved road for Java at Netflix. And you don’t have to choose Java, you can choose something else, but there’s a lot of tooling built around Java, and your job will be a lot easier if you choose Java. So, I think the thing that people react against standards in companies is, if you have a centralized architecture team, that makes decisions by reading white papers and talking to vendors, then people are gonna be naturally resistant to that versus if you have architects that are embedded on dev teams and they have, you know, they have a community of sort of a cross-team community of architects and they are involved in actually writing code and supporting things in production. Then certain toolsets will sort of naturally come to the forefront. And so, like, I’ve seen at Nordstrom, a lot of API teams are sort of moving to Golang or Node.js, and both of those are well-trodden paths for writing APIs. So, a team could use something different if they’re willing to support it in production and justify it, but there’s also sort of a, here’s something that there’s a lot of tooling built around and a lot of standards built around.
Matty: [00:20:16] I think anytime you try to declare something by fiat, you’re really not going to get a lot of traction. The best way that I know of to get people to do the thing that you want them to do is to make the thing you want them to do to be the easiest way to do the thing they want to do. I think that goes to your point, Doug, which is to say, like, okay, you don’t have to use Java, but we’ve got a bunch of really good patterns for you, and you’ll actually— your job will be easier if you do it this way. Then you’ll do it that way versus me saying, thou must, right? And I had this conversation with a customer last week about, like, how do they— they were talking about with regard to Chef code about, like, oh, well, how do we keep people from doing the thing we don’t want them to do with Chef? And I’m like, well, stop thinking about the thing you don’t want them to do, like the action, and think about the result you don’t wanna create. So I’m like, you wanna look at it and say, I don’t really care how you write your infra code, but you damn well better not make an artifact that enables remote logging. ’Cause I’m like, if you sit there and you play the game of you have to do it this way, you have to do it this way, everyone’s gonna figure out how to get around every blocker you put in there because they wanna get their shift done. And they think it’s a— so it’s like about not being pedantic. And also, again, as you grow to a large enterprise, it becomes incredibly challenging to have an architect that can understand all of the lines of business, all of their requirements, all of that stuff, and be able to make a very informed prescriptive standard. You have to become really vague as you go up, up, up the ziggurat in a big, big, big, big, big enterprise, because you just don’t know everything and you have to like get into more maneuver warfare, right? Like, which is, here’s the broad strokes of how we do stuff here and how you get there, get there the way that makes sense for your line of business at the smaller architect level or something like that.
Bridget: [00:22:03] So I spent Friday last week out in Seattle at a chaos engineering day put on by Netflix. And what they were talking about there, and there were a bunch of companies there from Google and Microsoft and other, you know, Jet that just got acquired by Walmart and a few other places, talking about the fact that you can’t predict absolutely everything that will happen. What you can do is deliberately inject the kind of failures you can predict so that you know you can survive those ones well. But what kind of made me think of this is you talking about the architect who has, the ability to understand the massive scope creep that is all of our modern infrastructure. And I would say Netflix and others are definitely moving that into breaking that up into, you know, the trendy microservices, but trendy for a reason, right? So that you don’t have to actually have someone who understands how all of these pieces work, as long as they communicate with each other via clean APIs.
Michael: Yeah, and something I’m getting from your answers that was a new insight for me is, like, standardization is great when it enables freedom. And when people are free and when they’re more productive, they will get on board with a standardized thing. And for us, Chef’s a good example of that because, you know, like, yeah, you can do whatever open source thing you want to do, and Chef will make it easier for you because you can get whatever agent or library or whatever installed, on this thing in order to enable it, and that’s something that we’ve recently done with HashiCorp Consul, server service discovery, and we’re using that for orchestration, but it was super easy using Chef. We’re standardizing in Chef, but people like it because it gets their stuff done quicker. I think that was a little bit of Matt’s point as well.
Bridget: [00:23:50] Well, and back to the Netflix open source stuff, I think the reason a lot of orgs are using Netflix OSS, even non-Netflix orgs, Because we talk to a lot of people who are using Spring Boot, cloud-native Java, and what have you. As much as I shudder and think of giant JVM stack traces from my misspent past with Hadoop, like, yes, okay, you can actually write modern Java that is not going to make you cry, or so my coworkers at Pivotal tell me. The people who are really— they want things like, Eureka for service discovery or Hystrix for circuit breakers. If they don’t want that Facebook integration on their website to break their website when Facebook is down, because I don’t know about you, but I’ve got— raise your hand if you’ve been paged for that. It’s like having good tooling to do stuff like Matt’s alluding to, that happy path, having the good tooling that already exists, is battle-tested by other people, is part of what open source is about, but it’s also about, hey, we’re gonna make there be an incentive for you to choose this tried and true way if your needs and usage patterns fit with it.
Michael: [00:25:04] Absolutely. So, to change gears just a little bit, Doug, another thing about your talk that I found really fascinating is you made an argument that an organization’s open source stance affects their hiring and what kinds of people they are able to recruit, and that you had an interesting survey that backed that up. You want to talk about that for a few minutes?
Matty: Sure.
Doug: So, yeah, I think we had a number of engineers who said that they looked at our GitHub profile before they came to the interview. I think it’s important to realize that you will be able to hire a number of engineers who wouldn’t even look at your company if you are contributing to open source. And contributing, because engineers can say, oh, wow, look, they’re contributing to Kubernetes, and they’re contributing to Chef, and those are cool projects that I respect. So, I think you get to interview people that you wouldn’t otherwise get to interview. In fact, we were, to name drop here, we were able to hire Nathan Haney-Smith, from Chef, primarily because we contributed to open source. So we wouldn’t have had that opportunity if we didn’t contribute to open source. So your GitHub organization is your organization’s resume in the open source world. So I think that’s super important. I think the other thing is that it helps retain engineers because they get to participate in the open-source world and not just contribute code, but speak at conferences and contribute issues and things like that. So, there’s a lot of benefits in hiring and retaining talent that you just don’t get. I’m trying to find a— there’s a tweet that I tweeted out and it was a poll. Here it is. So, I asked on Twitter, I would be willing to work for a company which didn’t allow open-source contributions. That was my poll. Question, and 68% of people disagreed. So, 68% of people would not be willing to work for a company which didn’t allow open source contribution. So, there’s over 2/3 of the people that you’re missing out on, and 25% were neutral, and then only 7% agreed. So, there’s a lot of people who would not look at your company that you wouldn’t have a chance to interview. If you didn’t allow open source.
Bridget: [00:27:42] I think there’s also kind of a reality check there, which is so many companies today are building their businesses on and relying for their success on open-source software. And if they expect it’s all going to be written by people in their spare time, like, they’re being unrealistic. So, like, of course, people contribute to open source because they’re excited and passionate about it, but people also like to sleep. And see their families. And so, like, I’ve heard that these are things people enjoy, and I know I enjoy them. So having, um, a company willing to put their money where their mouth is and, like, actually either pay people to contribute to open source, either if they work at a vendor, great, don’t just write closed source stuff, write open source stuff, or if they work at, you know, somebody who isn’t vending open source software themselves, paying their employees to write stuff that is going to enable their employees to continue to have that public presence helps you hire people, just like Doug was referring to. And it also, I believe, is just the right thing to do if you’re benefiting from it.
Doug: [00:28:45] Yeah, I think companies don’t also— that are using open source, if they are sort of unwilling or hesitant to contribute back, I think people don’t realize how hard it is to maintain private forks. It becomes quickly an untenable situation to try to do that. So, So don’t do that.
Bridget: The private fork is a disaster for so many reasons, especially the part where you try to hire new people and they’re like, all right, so you use Project Foo. What?
Michael: Yeah, this is different.
Matty: We sort of do.
Michael: So switching gears a little bit again, I thought it was interesting to overlay Doug’s talk and what we’ve been talking about open source with maybe what we think about when it makes sense and when it doesn’t make sense to spend money on this stuff. And I can view my journey with open source and how Chef’s helped me in 3 different areas, and I see a lot of open source vendors doing that, but I thought it would be interesting if we just talked a little bit about when you guys think help with open source is a good thing, and then when perhaps it might be a bad thing because you haven’t, you haven’t built the organizational maturity that you need in order to succeed with open source. I’ve recently, last few months, been working at Algae, and early on we would be learning an open source project, and you run a command and it just totally doesn’t work. And she says, well, what now? And I say, we Google that error. We Google it. And the open source workflow is very much about running it, Googling the problem you get, running it again, Googling that problem, and then eventually you get it working. And then you get it working, it’s awesome because you get to leverage this community’s broad whole skill set of being able to create an issue on GitHub and Google something and maybe go to a conference and talk to the community. That is all kind of learned. And so I’ve found that partnering with vendors really helps with that. What do you guys think?
Matty: [00:31:07] I was going to say there’s another piece of that workflow that’s really important in your organization, which is now that you learn the thing, how do you share that thing? So that the next person in your company that has the same problem doesn’t have to go through the same Google, GitHub issue search, Stack Overflow search, etc., etc. I think that’s one of the things when I talk to customers, when they talk about challenges they’re having, a lot of it is based around internal community, around that thing, a lot of reinventing the wheel, a lot of, we’ve got 25 different versions of a Tomcat cookbook here, or You know, how, how are they communicating? And the thing that’s— I want— one hand, it’s like, it’s a super simple thing because it’s just rinse, repeat what the public community is, right? Like all these things are there, you know, everything you do for the public community will work on your internal community. And when I think you’d look at companies that have robust and healthy internal communities, they look just like a public community, right? Except that they’re behind the firewall. And It’s interesting. There’s some fun insight that you see when you’re a resource for DevOps, like this show is. When you start to understand, like, there’s a bunch of customers, a bunch of companies out there that I know exactly what they use for their wiki software, because I see the referral links to ADO episodes from their SharePoint or their Wikia or their whatever, right? And so stuff like that, it’s like, how do you, you know, so you were the trailblazer that went out there and solved for this, but you don’t want anybody else to have to solve for it. And that’s the sharing part of DevOps. Right? Like, it’s sharing what you learned. So what are you, what are you working on, Michael, within your— within NCR’s internal community that you’re working on? How are you helping that? Not to put you on the spot, but a little bit.
Michael: [00:32:52] Well, yeah, that’s— I’ll answer that question, but I think what you’re saying is something that I was really surprised about with working with you, Matt, and with working with Shep, and that was I thought I was showing up so that I didn’t have to Google somebody or that in the middle of the night I can fill out a support request and they could answer it. And then you guys like really quickly did that kind of thing. Like, okay, where’s your internal community? And they have all of the, all this sort of checklist of building an internal community that, that I didn’t even have on my agenda. I thought my problem was a technology and there’s this kind of crazy open source landscape of of Slack channels and GitHub, and it really has— our relationship has morphed more into like a consulting type of thing. And that has driven us, me, into being very strategic about who I talk to within the organization, what is making them successful, what’s not, and whether they are talking to each other, whether they’re appropriately talking to Chef for anything that they’re having problems with, what other tools we’re looking at, enabling people to have the freedom for that. And it’s not natural for people at the beginning to work like that. And it is really freeing to them. I remember this one guy I was working with, really great guy in Prague, and he’s used to sort of the directive. He’s just like, you know, okay, we’re gonna use Chef. And then, and I tell him how I do Chef stuff, and he immediately disagrees with me. Like, well, I think here’s this problem that I’m having that’s different than your problems, and here’s how I’m gonna do it. And my response was, Great, go with it. This is your thing. And he was surprised by that because he’s used to this sort of top-down, no, it must be my way thing, but then like the community aspect of it allows for diversity, even internally, where people can have different opinions and take the problem in a different way. And that kind of stance for us has, really created a better community than I thought was going to be there when we first started and has morphed our relationship away from the support model to the consultant model when we’re talking about Chef. Before we get into that more, like with that support model, we had another situation. I guess I could just name the I won’t name the tool, but we started to try to use a tool. We give the person 2 days to use it, and they come back and they’re like, couldn’t get it running, sorry. Okay, then you go to the website and they’re like, hey, you know, we’re open source, but if you want some support for this or our stable this or that or the the installer that will do it all or whatever it is, you can pay us some money. So, but I can’t do that. I can’t go to my boss and ask him or her to pay money for every little tool I want to look at. So what’s the relationship? Is it almost unhealthy to use open source vendor as a support model because maybe you’re investing in something that’s not really great to begin with? Or is that a good thing? What do you guys think?
Matty: [00:36:40] Well, I mean, you’re, you’re, you’re, you do get what you pay for, right? You know, and it doesn’t mean, you know, it’s, it’s sort of the old, old gag, right? The Linux is only free if your time has no value, um, which was, is fundamentally untrue, but still funny. The, the thing about that is, you know, someone, someone’s got to pay for something. But when you think about the model And I can, again, mostly just speak for the company that I work for, but I know the vast majority of the people who use Chef do not give us a dime, right? And that’s fine. You know, that’s good. There’s, there’s reasons for that. The— and it can, I guess, as the person who is paying for it, it feels like, you know, kind of, you know, I guess it’s— I guess now we can get into some libertarian argument about, right, why are you funding all these people who don’t have to pay? Because just because you can pay, Michael, But there’s things you want that— so the thing is, like, I guess, let me take it all the way back. There has to be more value to paying for my product than just you get some support, right? And there’s reasons for that from my perspective as the company, because if all I’m selling you is support, I don’t have a really sustainable business model, because eventually you’re not going to need help from me anymore because you’re going to be better at my product than I am, because that’s what’s going to happen. So I need to be providing value besides just you can call me up and open a ticket and we’ll help you with it because eventually you’re going to run out of need for having support for me. But the thing is, if you’re saying open versus closed source, when it comes to that about, well, why would I— I mean, you’re certainly going to pay for that in the closed source model, right? But the kicker is that that might be all you’re really getting, right? Like maybe all you do need is the support and then maybe you’ll eventually not need it anymore. You don’t have that option in the closed source world, right? You know, where it’s like you’re paying for maintenance because it’s the only way to get upgrades or something like that.
Bridget: [00:38:31] Yeah, and I can speak to that too a little bit from the business model perspective. Like, for example, Cloud Foundry is open source. Pivotal contributes about 65% of the commits to the open source project. We have a foundation, we have IBM and HP and all sorts of giant, Swisscom and all sorts of CenturyLink, et cetera, et cetera, GE, all putting commits into the open source project. But if somebody wants a commercial, commercially supported version, Yeah, they don’t have to install it themselves from, you know, a README on GitHub or whatever. But I think there’s a huge gulf between, I stood up some sort of, you know, massively scalable Hello World app from GitHub, and we have an actual POC that we can kick the tires on for purposes of, like, our company’s internal needs. And I think one of the places that we try to offer, and I know Chef has offerings like this too, but one of the places we try to offer something like that is, We have like a 60-day free trial, no credit card required, of the commercial product that people can just go put like a phone number in to get a text, you know, a code texted to them just to kind of minimally prevent them from gaming it forever. And then like they can try the actual commercial product without having to stand it up themselves. So like that way they can see after they’ve tried on run.pivotal.io whether or not they actually even like it, then they can talk to a rep and find out if they actually want like, again, a free POC stood up for them. Before they sink money in. So, like, I would say it’s kind of a straw man argument to say, oh no, I can’t install it myself from GitHub, so therefore, like, I can’t get a PO cut. Like, there’s a huge range of activities you would go through before you cut a PO.
Matty: [00:40:12] There’s also, and I think that is something as a vendor that you should be looking at, which is how do I kind of grease the skids on that evaluation process? Because a lot of these things, a lot of these toolings we’re talking about, they can be a bear to get going, and that’s fine. It’s because they’re complex systems. They’re not just like brew install blah, right? But the thing is, I don’t want to have—
Bridget: Your coworker Juicy has a great tweet on that. It’s like containers in dev, it’s like tiny, this little thing.
Matty: Oh, the clip of production working.
Bridget: The clip of productivity, and then like, oh, when you want an entire orchestrated containerized platform, that’s an entirely different thing.
Matty: So the thing is though, but what I don’t want to have to do is if I’m trying to decide, do I want to use Foo? And then it’s like I have to spend like a week to stand up infrastructure to even push a button to see what the hell food does, then to be honest, as the vendor, I failed, right? Like, and so that’s one of the things that I know, you know, we work on. And I, you know, it’s exactly the same kind of thing Bridget was talking about, about run.pivotal.com. Is that right? Run.pivotal.com?
Bridget: [00:41:15] Yeah, and I know that the Hosted Chef has the same thing. We used it at Drama Fever.
Matty: Right, and then there’s even other things that we look at to do where we’re building it to say like you want to get your hands dirty to actually say what’s it And when I think about, you know, again, without going too specific, like, because nobody cares but me, that was like how I would, as a solution architect, how I would do POCs, which is, hey, I want you to have the experience of what it’s gonna be like when you’re using Chef. Let me— what I’m trying to give you is the flash forward of what’s life gonna be like 6 months from now, because then you’re like, oh, this is how we’re gonna work with this. I want this. So now I’m willing to invest the time in building the infrastructure and doing all that shit, but I might not want to do that. I might get halfway through it and go, why do I even want to do this? I don’t even know if I’d like the thing yet. So that’s something I think time to first value, or at least time to first delight, is, is really necessary.
Bridget: Yeah. Schaefer calls that mean time to dopamine.
Matty: Yes. That’s perfect. So, um, that’s the thing to look out for and to figure out. But the thing is, to your point, Michael, when you’re saying that’s great, you’re like, but I’m not the vendor, so I don’t get to control what they do. Realize that they might be willing to do stuff like that too. Like if you run into that and then it’ll just be the big buy now button, you know, you can always reach out and say, hey, can we arrange something? Because I really need to test this, but I don’t have the bandwidth to, to make install on this crap right now, you know? And yeah, so that’s telling about the relationship you’re going to have with the vendor too, right? You’re with the, with the maintainer is if they’re like, nope, just PR is welcome, GTFO, then you’re like, maybe this is going to be a tough relationship for the way we work.
Bridget: [00:42:57] And I think that’s a really important point, Matt. It’s also invaluable to look at what the rest of the open source community that isn’t buying something from that vendor is doing. So, for example, the US government with 18F is using open source Cloud Foundry for cloud.gov, and they have put up some amazing stuff on GitHub. And, you know, just documentation pages, a whole bunch of Terraform stuff to stand up their things in AWS. And it’s like, hey, this is better than the things that, you know, we had written or other people had written. You know, it’s like, hey, the 20-step checklist, you know, is now a Terraform script. Like, this is the kind of open-source community that I think it’s really valuable to see around a project before you decide whether or not, you know, put your toe in, how’s the water? It’s like, let’s see if some people— and I know there’s other great, there’s fantastic examples in the Chef community too, because I’ve seen a lot of them. I’ve been at ChefConf and seen this. And I think if you see that kind of engagement from the community, you can, as a consumer of open source, feel a lot safer using it. Because, like, if that one vendor starts to not be somebody you wanna work with, you have other options.
Doug: [00:44:03] I’ve really been trying to push vendors that we evaluate to, like, hey, Don’t, like, give me a Terraform script or give me CloudFormation. And I find that that’s sometimes a difficult conversation. So, but I, like, I wanna get started with your thing, and I would like you to make it easy for me. And I don’t have 2 weeks to try to write my own CloudFormation thing, and I don’t wanna just go through the console and install manually.
Bridget: Right, because you want it to be repeatable.
Doug: Exactly.
Matty: Yeah.
Michael: Yeah, so then you kind of start out on helping open source, or an open source vendor is helping you get started, and then you move into, I think, Matt, your main job right now is helping organizations create a mature community within their organization and a mature strategy for making the reality of open source real inside of an organization. And then I think there’s a third thing, which is, you know, maybe the freemium model where you have the basics that you could do. Let’s use Chef, for example, the basics with Chef, but then you have Chef Automate on top of that, which gives you more features, but then also kind of is very similar to if you were to buy a vendor application because you’re kind of locked in at that point. So very briefly, what do you guys think about that freemium model and its usefulness within an organization? You think that works for people?
Doug: [00:45:47] So can I jump in? I’d love to go back, if I could hijack the conversation a little bit, go back to the internal community because I think that’s something that we haven’t really talked about, that’s super important. And I think that one of the things you have to be prepared for if you’re an enterprise that’s new to open source is that a lot of times you’ll get the response of, well, what do you mean that I should submit a pull request? The vendor should fix that. There’s a bug in there. You know what I mean? So, it’s like there’s a bug in their software and they should fix it, and I’m not going to do their work for them for free. And so, a lot of that, there’s a lot of that attitude, I think, that you encounter. And I think as you mature as an organization using open source, you realize that, you know, you as an engineer have some unique insight into the problem that you’re trying to solve with this tool. And, you know, as an example, we were using some open source software using Supermarket, And we found a bug maybe a year and a half ago, and it was something that we were super familiar with and we could fix in 5 minutes. And so, we fixed it, and it was merged within an hour. And so, versus calling the vendor and complaining, and, you know, calling Chef and saying, hey, this thing is broken, we need you to fix it, and then they have to sort of triage it, and they have to put it in the next sprint, and it takes 2 and a half weeks, and no one’s happy, versus, hey, I know how to fix this thing. It’s real easy. It’s a very, very simple thing. I can fix it in 5 minutes, submit a PR, and then it’s merged within an hour, and then everyone’s happy. So, I think there’s that maturity of realizing that open source is a collaborative thing.
Michael: [00:47:32] Yeah.
Doug: Hey, this is a bug, we should fix it.
Michael: The light bulb kind of came on for me one day as I was working with the Chef support organization, where it’s very early on, I filled out a support request. This thing isn’t working. And then they were really nice about it. They’re very empathetic, which I think is important for a vendor to be for people, helping people along. But so they didn’t tell me this, but I found out. So they created a GitHub issue and they created a pull request and they submitted the pull request and they got it merged in. And then they reported back to me, it’ll be in this version, and then they linked me to the pull request, and the light bulb went on. It was like, oh, I could have done all that myself, and it probably would have been easier, and they just sort of showed me how it goes in a very empathetic and gracious way that didn’t make me feel dumb.
Doug: [00:48:33] Yeah, last time I was on a major project with a closed-source major vendor that everyone sort of that we reported an issue, and they’re like, well, we’ll probably get to it in 6 months.
Bridget: Oh, brutal. And you’re like, but I need it now.
Doug: But we’d already paid them the millions of dollars, right? So, what was their incentive to fix it, right? And I don’t know if that fix ever got in. I left the project before the 6 months were up, but I don’t think that it did. But they’re like, yeah, too bad for your problem. Maybe we’ll add it in 6 months.
Bridget: This is, this is why I like subscription models because it’s like, huh, if you’re going to have subscribers churn, you’re going to care and do what they need.
Matty: Well, and that’s, that’s really the model almost everyone is going to, you know, so that’s, that’s, that’s a whole other conversation. And heck, you could have a whole podcast, not episode, but podcast about success, about customer success as a thing. Um, but it’s, it’s super important because again, in that, just, just to Just to Doug’s point, right, if it’s a perpetual license, like everything matters up to the sale, right? Like that’s, that’s when you’re gonna have the most attention from your vendor. That’s the thing that matters the most until you sign that PO. But it’s kind of flipped on its lid when you’re looking in a subscription model where your vendor is gonna love you the most a year after you buy it, right? So there’s your dirty little secret for all your subscription-based stuff. Renewal time is the best time to ask for anything from your vendor. I probably shouldn’t have said that.
Bridget: [00:50:04] And your vendor, if we’re telling vendor secrets, if you agree to be referenceable, your vendor will love you forever.
Matty: That’s just a good thing to do. Uh, but, but, but conferences, we love all that kind of stuff, but we guys know that. Um, you got, y’all know that. Um, so I, I was thinking about the freemium thing. Um, I think it also matters about how that, that, And that’s something that’s like changed a little bit with Chef from Chef 11 to Chef 12. So it used to be that there was an enterprise version of Chef that you paid extra for, then there was regular old Chef. And the thing that kind of sucked about that was you really were kind of locked in, right? Because you couldn’t just decide you wanted to stop paying for Chef and stop paying for it. I mean, we probably could, but not legally. You’d have to go reinstall everything. So that was one of the ideas with Chef 12, and this is extended through into Automate. Is that the core product, the core thing, whether it’s Chef or Habitat or Inspect or whatever, that’s open source, that’s its thing. And everything around it is wrapper. And you can— now again, it’s easier said than done to say you can just turn it off when you don’t want to use it, because we hope that you don’t. We hope that we’re sticky enough that you don’t do that. But the, but the onus is still upon the product to be sticky, right? To be valuable. I, you know, the thing is, if you’re like, I don’t get any value out of automate, well, then, then it doesn’t hurt you to turn it off because you didn’t actually need it. But if it’s sticky, in a way, you can’t complain that it’s sticky because it should be sticky because it’s valuable, right?
Bridget: [00:51:35] Yeah, super good point. Super good point. Like, as purveyors of open source software, we need to keep providing continual value.
Matty: Like, bottom line, you want, you want that premium thing to be sticky because it’s valuable, not because it’s in the way. Right? I want you to renew because you like it, not because it’s easier to renew than to get rid of it, whatever that means. I’m not quite— there’s a better way to say that, but yeah.
Michael: But in the back of my mind, sometimes with the freemium thing, like with Chef Automate, for example, you know, would it be better for me in our organizational maturity to stand up a Jenkins pipeline and have a bunch of— have our own Elasticsearch cluster that is feeding data in our monitoring framework that’s open source this and open source that, and just kind of keep things at that basic level instead of kind of the all-in-one solution?
Bridget: I can answer that. The answer is, it depends. Okay, but seriously, so it’s— I think that there is a fairly common fallacy I see inside organizations that have really smart employees, who are possibly practicing resume-driven development and would definitely like to build a cool thing and talk about it at a conference and be a rock star. And, like, there’s— I think there’s a common fallacy that they should probably mature to the point where they know and understand every single thing, possibly down to the chip fabrication. Not really sure where the end of the stack is. There’s turtles down there somewhere. But the reality, and, like, this is definitely a Pivotal Party Line TM, but I also agree with, because I’ve actually done this, is you should only build the things that make a differentiating business value for you to fully control the horizontal and vertical and end-to-end of. The stuff that doesn’t is probably a commodity to you. I’ll give you an example. I worked before Pivotal at a streaming video company called DramaFever. We did not roll our own CDN. It took Netflix years to roll their own CDN. I mean, the CDN was obviously essential to our business working. What we did at one point when we looked at our Akamai bill and went, oh, good God, was we got ourselves to a position where we could go multi-CDN, and then we went and had a conversation with Akamai about our Akamai bill. Turns out we didn’t need to go multi-CDN because they were perfectly happy to deal with us once they saw that we were prepared to. But that’s the sort of thing where, like, we could have built a CDN, we had the skills in-house, But would that have been the most effective use of our time? We were busy building a completely Docker, Packer, Chef-based platform, which it could be argued that when we started doing that in, you know, like early 2013, there wasn’t a good off-the-shelf option out there for us to use. And that made a huge amount of business sense for us to have the ability to say, we run a K-drama site. Hey, AMC, you want us to run a documentary site? Oh, and, you know, a few months later, you want us to run a horror site? Sure, we can do this with literally the exact same Docker image, just spin up an entirely different site. Having the ability to be flexible for the stuff that matters for your business is way more important than having the maturity to know how to do all the things, however widely or broadly you wanna define that, is my opinion on that.
Michael: [00:54:56] You could even extend that into, if I’m going to bring up an open source project, but it’s going to take me 3 weeks to do it, even though I’m not developing or creating something from scratch, if I could have paid somebody or even gotten a proof of concept to the earlier point, if I could have paid somebody to get me that in 2 days because it’s not core to my business, that’s most of the time a good business decision. It’s kind of what you’re saying, right?
Matty: Look at email. There’s no reason to run your own email. It’s stupid. I’m sorry. But, but, but no, stop. There’s no reason. No, no, stop. There’s no reason. It’s sort of like, to paraphrase—
Bridget: No differentiating business value.
Matty: To paraphrase Pat Noswald, modern DevOps, we’re all about coulda, not about shoulda, right? Sure, you could build your own bespoke, awesome pipeline, but is that actually helping you sell shoes if what you do is sell shoes? No, right? Again, it’s about core competency. It’s about business differentiator. And I think, like, to your point about, do I pay somebody to come and do it? You pay somebody to do the thing you’re never going to have to do again, right? So, like, what you don’t want to do is pay somebody to come and write all your automation because you’re probably going to change your automation. And if you don’t know how to do it, then you’re kind of screwed. You know, now you got to go back to the vendor. But if you’re like, hey, I need to get, like, my cluster set up and I’m never going to build clusters again because I know, or I’m going to do it once every 5 years, then yeah, just pay somebody to come do that shit, right? Because you don’t really care how it’s done. It doesn’t matter how it’s done. And I think that’s the hardest thing is smart people want to do fun, smart stuff. I was at, when I was at Apartments, we were, you know, I remember having a giant fight with a couple of the dev leads who wanted to write their own AuthZ and AuthN for our internal customer service app. Now, number one problem, why do we have our own customer service app? Why aren’t we using a CRM? Because guess what? We rent apartments, we don’t run a CRM. But okay, move on from that. Second of all, why the hell don’t you just use— and we’re a Microsoft shop— like, use Active Directory? Well, we don’t want to, we could do it better. I’m like, really? There’s a team of hundreds of people at Microsoft that does nothing but this. You’re a .NET developer building a rental site, but you think you can actually build a better— I mean, again, it’s just silly. It’s hubris, right? And it’s, and it’s, it’s a combination of hubris and desire to do cool shit.
Bridget: [00:57:21] So, um, I’m telling you, resume-driven development. It is.
Michael: It’s totally—
Matty: we’re gonna have a whole show sometime when I’m gonna bring on people I worked with at apartments, and we’re gonna all vent about the resume-driven development that we had to support when all the people left after it got built. But I do think— so Bridget got a chance to rant.
Bridget: That’s another show.
Matty: I ranted, Bridget ranted. So Doug, take us out with your final rant.
Doug: Well, I have a rant, but I just— to react to what you said about that you, you should pay someone or have consulting come in when it’s something you’re only going to do once. I think, I think, or they— and, and sort of that you don’t care about or whatever, or that you want it to get done but you don’t care how it gets done. I think, um, consulting can also be helpful if you— if the consulting company has expertise in something that you, that you need to learn how to do, and that if, if they’re willing to, to sort of work with you and sort of help you jumpstart that knowledge, whatever that is, and work with you and partner with you, not just like huddle off in a corner and do the thing and then hand it to you, but sort of work with you and you’re willing to dedicate engineering hours to working with that company. So that was my one thought on that. I think as far as freemium, we paid for Shopify at Nordstrom and then we found a lot of value in that relationship. And a lot of value in paying for it because the support was really, really good. And just the other things that the add-ons were stuff that we didn’t have to write and that our customers of Chef expected, things like, you know, a nice UI for the— a web UI for the Chef server and things like that. Those were expectations and we didn’t have to write those. So, but I think there definitely can be value in that premium model and paying for things.
Matty: [00:59:10] So, Yeah, I mean, I guess the final way to think about that is inside Chef, did we write our own search provider? Right? Like, I mean, no, we use Solr, we use Elasticsearch. It’s like, use the thing that’s smart. So this has been an awesome episode. This is our first experiment with guest hosts, and I think it went swimmingly. So Michael, thank you for the idea, for kind of kickstarting this episode happening. For being an awesome guest host. I hope to do it again sometime. That’s super rad, and we’re going to run ourselves into talking about some community and event stuff. Remember, if you have an upcoming conference you’d like to see promoted on the show, you can fill out the handy form at arresteddevops.com/conf. We’ve got discounts on a lot of DevOps Days, including Madison, most recently. Dates have been announced for Sydney, so you can check that out at devopsdays.org.
Bridget: [01:00:10] Yeah. If you want your DevOps Days Down Under, December 1st and 2nd. I think that’s summertime, right? Ask Matt Rae, he would know.
Doug: Sounds right.
Matty: The discount code to try is ADO2016. That would be for anyone that are in 2016. We’re going to have to come up with a new one for ones in 2017. I bet you can guess what it is. Also, we have discounts on the upcoming O’Reilly conferences, Security and Velocity. The discount code ADO2016 will get you 20% off there, and you can go sign up for them at conferences.oreilly.com/security or conferences.oreilly.com/velocity.
Bridget: Those are pretty fun conferences. We also have a lot of open CFPs. Strangely enough, a lot of DevOps Days CFPs closing August 31st, a mere 2 days from now. So we’ll see when we actually get this out on the podcast feed.
Matty: That’s true, but if you’re watching it live, and you can always see the upcoming CFPs at devopsdays.org/speaking, which Bridget just implemented last week. So yay, that was cool.
Bridget: [01:01:15] Awesome. So where we’re going to be, I got to tell you, I’m super excited. On Wednesday, August 31st, I am driving up to the Canadian-Minnesotan border, and it’s 5 days of no cell signal, let alone internet. Camping, canoeing, Boundary Water Canoeing Area, it’s amazing. I’m very excited about that. And then I think the next place people can see me is probably Velocity New York and DevOps Days New York, where I’m going to be doing a panel and an Ignite talk.
Matty: If you’re watching this live or looking at the YouTube, which will be up there shortly, I’m going to be at DevOps Days Chicago tomorrow and Wednesday. So, if you’re there, come say hi. I will be one of the people in a purple shirt running around like a crazy person.
Bridget: You’ll be one of the people, like, emceeing and running it and whatnot.
Matty: Yeah, hiding from questions. So, yeah, for checkouts, Michael, what do you have for our listeners to check out?
Michael: Well, I have 3 things. My wife, Annie, and I are on the organizing committee for DevOps Days DFW, and that is September 15th and 16th in Grapevine, Texas. I’m going to emcee that as well. It’s the first DevOps Days in Dallas, so I’m really excited about it. We have great speakers and it’s kind of a good, good thing for our community in Dallas, so I’m looking forward to that.
Bridget: [01:02:41] I’m excited about that one. Yeah, great. I’m not going to make it to that one, but I think I have a coworker speaking there. Isn’t Kotei going to be there?
Michael: Yes, he’s speaking at the very end. He’s giving his DevOps for Normals talk. Nice. Yeah. Second thing I would point your listeners to is this book called Toyota Kata. You guys heard of that book? Oh yeah. Yeah, it’s a good book. I heard it on a podcast and started reading it. It’s really great about iterative coaching and getting in a mindset where you’re, you’re not just trying to come up with a grand vision, but you’re really trying to bring people along a journey one step at a time and to be really clear about measuring and understanding that journey in the broader context of a company culture. And then the third thing that I’ve really gotten into recently is PBS Space Time. It’s a YouTube channel, and they get into all sorts of cool physics things like black holes and time travel and even quantum mechanics. It’s really, really awesome. I have it subscribed, and my phone tells me whenever there’s a new episode, like once a week, and it’s about 10 minutes long, and I almost immediately watch it because it’s a fantastic YouTube channel.
Matty: [01:03:59] That just makes me think of Inspector Spacetime from the show Community. Awesome. Doug?
Doug: All right, I have 2. One is that I’ve been looking for time to check out Chef’s new open source project Habitat a bit more. It seems super cool. I’ve seen a couple demos of it, most recently in Portland last week, and excited to try it out for real. And then Adam Jacobs’ DevOps Kung Fu talk from ChefConf 2015. It was amazing, and it drove some good culture discussions at Nordstrom last year, and just recently recommended it to someone last week. So, excited to recommend that to people. All of his talks are good, but this one was particularly good, in my opinion.
Bridget: Cool. And we did just have Adam on talking about Habitat too.
Doug: Wow, there you go.
Bridget: [01:05:00] So, you can check out that video episode.
Doug: You combine your peanut butter and your chocolate there.
Matty: Exactly.
Bridget: Good stuff. Okay. So, I want people to check out an article that, I think, a blog post that my coworker, Kotei, just wrote. About calculating that ROI on DevOps, Agile, whatever, just because I feel like inside large organizations, that’s a conversation that a lot of people want to have. And they really want to talk about cost, maybe, as opposed to value, things like that. So, Cote is a good writer, and if you go to cote.io, or the link will be in our show notes, it’s C-O-T-E. So, I think that’s pretty interesting. And then something else, not tech, that I’ve been paying a lot of attention to lately, because going camping, um, is the Boundary Waters Canoe Area is— I have found it is part of the Superior National Forest because I thought it was a national park. It’s actually not. So like national parks and national forests aren’t the same thing. This will take you down a giant Wikipedia rabbit hole, let me tell you. Um, and then the National Park Service is, uh, celebrating its 100th anniversary, 100th anniversary, which is why you hear all that thing is about like, you know, national parks for free in this last week and stuff like that. But national parks themselves, as opposed to the Park Service, are not actually only 100 years old. So like Teddy Roosevelt and like the Antiquities Act and all sorts of stuff. Again, that’s the West Wing tie-in. I guess that’s the third undocumented thing is of course we’ve been watching The West Wing because election season. So, um, yeah, there’s, there’s a lot of interesting stuff out there to read. So we got links in the show notes.
Matty: [01:06:33] Great. So I’ve got, I basically just have one, although I’ve got another one I just thought of. But anyway, a tool that I think is pretty cool is this thing called Wakatime, W-A-K-A-T-I-M-E. They call it the Fitbit for programmers. So it’s sort of like RescueTime, but it’s basically just embedded inside your editor. So you can figure out what projects you’re spending how much time on and what languages and all sorts of stuff. It’s been kind of fun. So it’s cool to check out. And then also you said you’re spending time watching The West Wing. I’m now currently obsessed with Homeland. I know it’s like old news, but as much as you think I’ve got my finger on the pulse of pop culture, I’m always behind on stuff like this. So Homeland is cool and you should all watch it because it’s super interesting and it’s not what I thought it was going to be. I, based upon someone who told me they liked it and what that person likes, I thought it was some weird network procedural and then I watched it and that is so not what it is. So it’s amazing. And you know what else is amazing? That we have a newsletter. You can sign up for it at arresteddevops.com/bananastand. It is a good way to know about upcoming podcast episodes and cool news with DevOps. I hesitate to say it’s the best way, but if you want to help us bring more content, you can contribute to us at patreon.com/arresteddevops. And we also have a bunch of cool new Arrested DevOps merchandise available at store.arresteddevops.com. Arrestedevops.com. We’ve got a bunch of new t-shirts, uh, the Bike Shed t-shirt and, uh, other things, and they can be yours.
Bridget: [01:08:06] All right, so thanks to our sponsors. Be sure to visit them at arrestedevops.com/10thmagnitude, arrestedevops.com/hired, and arrestedevops.com/datadog. Thanks, Michael, for hosting and Doug for joining us.
Matty: Sure, you’re welcome.
Doug: Glad to be here. I appreciate the opportunity. Thank you.
Bridget: Nice. And to all our listeners, if you’re enjoying Arrested DevOps, apparently visiting arresteddevops.com/itunes and leaving us a review in the iTunes Store is a thing that makes more people listen to us. And we’d love to know what you thought of the episode if you leave us comments. This episode will be at arresteddevops.com/open-source-ops.
Matty: And, you know, we’re on the Twitters @ArrestedDevOps, so tweet at us or tweet at me, which is basically what says the same thing as. If you’ve got ideas for feedback or ideas for new shows, you can type in shows@arresteddevops.com into your email machine, which hopefully you’re not running for yourself, and let us know. So yeah, I’m Matt, @MattStratton on Twitter.
Bridget: [01:09:10] I’m Bridget, @bridgetkromhout. We’re Arrested DevOps, and remember, there’s always DevOps in the banana stand.
