Will Kelly is a technical writer who joins the adventure to discuss bridging the gap between open source, development, and DevOps. He explains the personal and technical skills needed to help folks understand the need for using Open Source software and how developers and DevOps practitioners can communicate about the security concerns around complimentary practices of the two groups with the realms of their jobs.

Hey, everybody, and welcome back to another episode of adventures in DevOps. This week on our panel, we have Will Button. What's going on, everybody? I'm Charles Max Wood from dev chat.tv. Actually, I I've changed that.

So I'm top endevs, top endevs.com. You'll see that shift somewhere around, you know, whenever this comes out. Might have already shifted because there's a little bit of time shifting with the podcast. So anyway, yeah, we're focused more on helping people become top end developers and build the careers that they want and get the outcomes that they want. And typically, what that boils down to is being especially good at your job and being able to outreach to the community.

So that's what I'm helping people with. And some of that soft skills, some of that hard skills or tech skills or however you reckon it. But yeah. Anyway, I am rambling, so I'm gonna stop. We also have a special guest this week, and that is Will Kelley.

Will, do you wanna say hello and introduce yourself real quick? Hello, everybody. My name is Will Kelley, and I'm glad to be here. We are glad to have you here. So we got started, and we invited you on because we saw this article you wrote, DevSecOps, an open source story.

Do you wanna just kinda give us the 10,000 foot view of what it's about and why you wrote it? I wrote it because I began to see more interrelationships and parities between open source software and DevSecOps, both from a cultural perspective. They complement each other also operationally, and that's what led to the article. It's a, it's a unique intersection as I see it. That's only gonna get more attention in light of recent supply chain breaches and president's executive order on cybersecurity.

So that's where the article comes from. I gotcha. It is interesting just to see how things have evolved, and we find ourselves talking more about, yeah, DevSecOps than I think we we ever have. And I think it's gonna be a continually escalating area of concern, I guess. I agree.

I can actually see I I mean, from writing about the topic for the past couple of years, I can see actually DevSecOps subsume DevOps at a certain point where they're just gonna fold together. So eventually, it's gonna be last step with DevOps talk, more DevSecOps. And and that's the more high profile breaches, the more people have to be concerned about compliance and security. It's it's on the horizon. Mhmm.

Well, I think some of the DevOps concerns will always be there. Right? I mean, there's a certain baseline, a certain level of, how do I put it, a certain level of work that's gonna have to be done that's traditionally DevOps that's outside of the realm of DevSecOps. But, yeah, the stakes are going up so quickly with DevSecOps, and it's becoming more and more common a problem that, yeah, eventually we're going to I don't think it'll ever completely obviate the need for DevOps, but I think it'll eclipse it. Yeah, exactly.

I think in the future, people are going to be talking about DevSecOps, less about DevOps and dev and they're just gonna yeah. It's naturally gonna eclipse each other. I mean, I'm already starting to see some vendors start to use terms interchangeably, and that's only gonna and that's only gonna continue now. Right. So you wrote this article about DevSecOps and open source.

And I'm curious, was was there something that prompted this? You know, some stories, some events, some I don't know. I think as a writer, to reach audiences when you're writing on a technology topic, so many of the topics have been treaded over so much. You have to look for unique intersections. So one of the big intersections that I was starting to see was you had the the use of open source is only is only on the increase.

I mean, I've seen some stats as many as 90% of enterprise software, and includes a lot of open source code, but also as well as the rising concerns of security. So, it's gonna be to me, it was a natural intersection where there was gonna be more concerns about security. There's still open source has is growing. They have a strong and robust community. There's still stakeholders out there and decision makers out there who may not feel completely at ease with, you know, free software in their enterprise.

And there's also having been on teams that introduce DevOps and DevSecOps into or into organizations, The cultural aspects are also very important. And I saw a lot of nice sort of compliment I saw a nice complimentary nature between open source culture and DevSecOps culture. The open collaboration, sort of the consistency of action and principles, the accountability and responsibility, as well as the automation that focus on streamlining processes and what's important. There was less I come from a time of waterfall SDLC that it was long hard, but it's nasty to get through. And DevSecOps and DevOps prior to to that, sort of take that away for both commercial and even public sector or organizations.

And then, I'm also starting to see some parallels of probably enterprise open source adoption and the growth of Dev DevSecOps. I mean, the thing that I'm looking at right now is what's going to be the role of open source program offices, which is sort of could be an internal governance body over open source inside a large company and DevSecOps. So, they're intertwined multiple in multiple ways, as I see it. Interesting. Will, did you want to chime in?

I kind of just took off with this and then set Will to expounding heaps of knowledge. No. It's it's interesting because you bring up a lot of good points. One of the things, you know, you mentioned that enterprises are concerned or a lot of times hesitant when using free and open source software. And my a lot of my experience is with early stage startups.

And one of the things we've encountered there is whenever a startup goes through an exit, either through, going public or getting purchased or something like that, Several of the startups I've worked with, we've actually had to go through and review all of the software that we've used, all the open source software, find out what the license for that was, whether it was the MIT license or whatever the other licenses are, and then give that to the attorney so that they could understand what the legal obligations and implications of using that were. And so I'm avoiding self harm. I'm avoiding self harm. I've been through this. It's not fun.

I know. Right? Don't hurt yourself, Chuck. Yeah. And and, like, so The traumas of the past.

If I had a an enterprise company worth 1,000,000,000 of dollars, yeah, I can see that I would be a little gun shy about jumping in with some software that someone else wrote. And that's why I've been sniffing around the topic on open source program offices because that would be under their charter and purview on on the licensing side. I mean and you're exactly right. And it's still gonna be murky to people outside of the engineering group. And when you throw in the agility of dev sec ops, everybody's gonna go there's bound to be somebody that's gonna go, woah, hold on there for a second, cowpoke.

And Yeah. It's it's funny, though, because you you talk about a lot of people not understanding it outside of the engineering team. And just to clear clarify a little bit, so most of the work that I've done has centered around Ruby on Rails, which is an open source web framework. And I've been there where we get in there and we put a bunch of stuff in on our rails app. And then, yeah, somebody outside the org goes, you put that library in.

Yeah. Is that open source software? And we're all looking at them like, we're running Ruby on rails on NGINX and Linux, and you're concerned about this tiny library when everything that we touch from the second we deploy is open source. And you're raising an interesting point. And I think as we spoke about before we got on air, I comment DevSecOps and DevOps and open source for that matter from a different perspective.

I'm from the writer and content side. So Oh, I think I felt a cold wind when you said that. Okay. Could be. But I spent more time on engineering teams than I probably have in a writer group during my career.

Fair enough. That's the one point, the points that you bring up is why I've always tried to stress in my articles and other projects is the importance of communication and education. You need to do that for DevSecOps processes and chances to come along with that. And if enterprises are growing open source adoption, the education and communications also has to extend to that. So the decision makers don't get too spooked.

It's this goes back to sort of the interrelationship I I see between DevSecOps and open source culture. It's openness. And the licensing aspects of it, that's just that's just one aspect of it because there's one group that engineers and content people always sort of wanna try, poor boy, and that's the legal department. But, eventually, they're gonna have to be a collaborator as well. It's not something I covered in my article, but you're gonna have to probably pay attention to that because the speed and agility of Dev SecOps, there's not gonna be sort of the, let's sit and wait until the project is done.

Iteration. That's so true. Iteration. So but the advantage of that iteration, iteration, iteration is you can use those versions to educate your legal team. You can use that to educate your non technical managers and executives.

You can give them more granular visibility into your processes because of DevSecOps. But, what you have to do is make open source part of that development story. Mhmm. If I was, if I write a follow-up to this article at some point, it's probably gonna be around that is how do you merge a DevSecOps story and a DevSecOps transformation with open source. And that starts with communication and education.

And, and you have to use the openness and collaboration to tell your story and spare your executives and management from surprises, but also use that to make sure that people are paying attention. Somebody's just going to nod their head or check marks something in a review process. You have another version down the line to go, this is what we're doing. This is where open source fits in. It's all about the visibility.

It's it's funny because you talk about this and yeah. I mean, I've been in a position where we sent stuff over to legal, didn't hear back. And then when we finally hear back from them, they're like, okay. Well, we have these questions. And the context is so far gone that we're just go what what are you guys even talking about?

And then when we finally figure it out, we look at them and say, well, we deployed that 3 months ago. Oh. It's Well, I spent most of my adult work and life filing up on reviews. And one of the things I saw with DevOps and and later, Dev Secos was like, wow. There's another chance to follow-up with somebody.

And I mean Yay. Story you're telling, it's it's fairly common in my Oh, I know. I know. Alright. Alright.

Oh, yeah. Yeah. That's fine. Further down down the line was, oh, I have some problems with that. Yeah.

Yeah. And and we've gotten that you engineers always do this. Right? I was taught never to say that. My first the first engineering group I worked in, BIDS did give me that love of the land.

Now they they gave me great lessons and the culture and how to go a little bit in data. So yeah, it's not something you'll ever say, but unfortunately, that's something that's something that's too often said. And it's interesting to see what the impact of DevSecOps is going to have on that. Mhmm. Especially for software that's gonna potentially hit a 3rd party on it at some point.

Yeah. Fair enough. Yeah. Our response was always, well, you legal folks think we just gotta sit around for 3 months while you figure this crap out. So I've worked in some organizations where they do operate at a different speed.

Yeah. I I have to. And it's really nice. I I was on one contract, though, where the legal support had been a software engineer in a former life. Mhmm.

Wow. I bet that helps. That that helped a lot. And he was a great intellectual property person. I mean, it exists out there, but it's probably a unicorn, I'm guessing.

No. I'm unicorn. The the last it it's funny, though, because that's just gotta be former software developer, now an attorney. That's gotta be a unique set of courts. Yeah.

There's so many follow-up questions for that. I know. Right? Again, I live in the DC area where the patent trademark office is around. Oh, fair.

So the feeder pool for the legal profession might be a little bit different here. Yeah. Yeah. Fair enough. I was gonna say you you threw out one little hidden gem in there that I really want to to focus in on, especially since a large part of our audience are DevOps engineers.

You were talking about giving this information out to executives or, like, bringing executives up to speed and, like, educating them in how open source and DevSec ops, and I think it probably extends to how modern software is delivered in short time cycles. You know, how do you recommend the people who are actually down in the trenches, get that information out to the executive level so that they can minimize those surprises. That's interesting and something that I've had a lot of that I've had a good bit of trial and error on during my career, especially for my current mission. Me too. Mostly error.

Again, coming from the technical writer side, you have to factor at some point during your DevSecOps adoption to bring in a content expert, understands DevOps, DevSecOps, modern software development, you know, has been through a couple of organizations, knows the audience, engineering group, and embedded with them, and also has experience with delivering content to executives and outsiders such as business and cults. And I might be a little bit biased in that, but something going back to something we were joking about earlier was that person can be a buffer or sort of help the engineers. They focus on what they need to focus on, but also make sure that the key points as they see it, that we emphasize and educated through the executives and stakeholders are covered. The additional benefit of having that content little person is they can talk to both the audience that will be consuming the content and the education as well as the engineering. The trick there is, is, is to find a balance of somebody that's documented processing for is ideally working in DevOps and DevOps environment.

Personally, the technical I've always saw that the technical writer role has never really had a seat at the DevOps, DevSecOps. And the role and positioning I'm describing is it's a way to get that and it's a way that it's the best investment of it. Because you're helping everybody out. The more you're saving an engineer from a needless question, the more they can focus on what they need to be focusing on. If you have somebody who's developing content, who's working to educate people on the business side, they can handle that sort of level 1, level 2, level 3 questions.

And then if something's definitely engineering related, they can go, Hey, I, you know, I need some engineering support here. It's a deflection move and it's something that I don't think enough organizations focus on. The other area, the other thing where I've seen organizations be successful on that is solution architects and somebody who exactly intersection of business and technology. So, if, if an organization I've worked in organizations that worked on the traditional engineering and programmer team model, Other teams that had solution architects, some were a mix, not somebody else who can play a role in that. And, in the case of those solution architects, and probably in a lot of cases, the writer, that person can also help with sort of that open source education where somebody on a business side go, well, I'm not sure how I feel about this free software stuff.

It's I, in the years I wrote on DevOps as, as a topic, something that, you know, I always saw was DevOps is sometimes is missing that internal champion or that internal advocate. Companies folks are really quick to have an advocate that customer facing or industry facing, but in large organizations, especially as fast as technology is moving today with DevOps, DevSecOps, the cloud, it's moving too fast for one person. And organizations need to focus more on what I call complimentary team, but as well as being able to package up that knowledge of that, of those complimentary teams for that internal facing content, that internal outreach and education about DevOps and DevSecOps Where there there are a lot of there are so many advantages to proclaim that when it's packaged up and communicated, wow, I can have more of a look into progress of my projects. I get better reporting on on the security. I'm not waiting 12 months to see the final version of of the product.

That's there's a lot of stuff to be there's a lot of room for that sell or that advocacy. And writers and solution architects are positioned for that. Some engineers may be inclined to do that, some may not. But DevOps and DevSecOps, you know, one of the foundations of it being sort of breaking down silos, there's also silos with the business that we all have to pay attention to. Yeah, for sure.

There's a hidden part of software engineering that is the sales and marketing of what your team does, and I think it's often underrepresented as a skill for a software engineer or a DevOps engineer. But you can really see cases where it's done well in, in places like Netflix. Like, whenever you talk about Netflix and DevOps, everyone instantly recognizes and understands what you're talking about because they've done such a great job of selling and marketing the DevOps practices that they use. It was interesting when I was writing on the topic DevOps, like, a lot of the feedback from the editors, what they were hearing from the readers, looking for articles that they could escalate up in the management. Yeah.

This is how we adopt DevOps. Look here. Here's a framework where see that we're not gonna break stuff. And that was a role that articles were filling some work organizations, but I think that's still an underselling of it Because what you write in an 800 to a 1200 word article may not be one size fits all. But that story, over the years, I've become a big advocate of sort of what I call framework storage.

I'm talking about DevOps and DevSecOps when it's going out to nontechnical readers where they can see the transformation and progression. They can see where they fit in. They can see where they'll see benefits from it. That's I definitely agree with you that the internal selling and marketing of DevOps and DevSecOps, there's so much more work to be done there. Well, I think that's true in just about any technical role.

People that I've worked with in the past anyway, they kind of intrinsically understand what the value is of what they do, and they just assume that everybody else sees it too. And in reality, those other folks are just looking at it from a completely different lens, and so you've gotta be able to put it into the terms that they're thinking and losing sleep over and caring about so that at the end of the day, they go, oh, that that's really valuable because it ticks these boxes for me as well. Exactly. I mean, it's what's in it for me. I I mean, the readers of a lot of my past articles were the business decision makers, and and a lot of them are are still there are a lot of people out there.

And, and I heard from them when I was writing on the, the topic a lot was they were still trying to understand how it fit into the business. And it takes everybody to help crystallize that. It takes the engineers, it takes the QA, it takes program management, it takes the technical writers. I'm I'll I'll even dare say change management if your organization has that. The key thing is you need to sell DevOps and and by extension, DevSecOps is a new way of doing business.

Waterfall SDLC, in my personal terms, comes business prevention. Yeah. I keep it halting me because I still have nightmares on my waterfall dates. Well, it's interesting too because in some ways, it feels like it can naturally fall that way. Just give you an example.

I mean, everything that we build, we're supposed to have designs for at a time. Right? Like graph graphical designs, UX designs. And, they get they get that to us about half the time before we get started on the feature. Right?

Which means that half the time, we'll finish the functionality, and then we'll go back and we'll cram it into whatever design they gave us. But so to a certain degree, there is gonna be some progression that looks like a waterfall diagram with with the features you're building. And if you if you can make your team work that way but still maintain some of the agile concepts so that you can adapt to change and people over processes and all the stuff that that comes out of the agile movement into DevOps, and you can maximize some of that and still do some of the stuff that feels waterfall ish, you're you're gonna be so much better off. But it seems like once things kinda move beyond whatever structure your team decides that they need to have in order to get the work done, and this is why I like agile is because you can adapt, A lot of times, things just fall apart, and it's it's hard to know exactly what to do in those circumstances where it's, hey. Look.

This is starting to become a problem when it happens and not make people become defensive because, effectively you're pointing out this part of the process that you're in charge of isn't working. Well, it's interesting be because I set up a chapter of my career reverse engineering documentation for lack of a better term. That meant something was already built. The process was broken away from, and you sort of had to fit things back into a process. And going back to my pre DevOps and DevSecOps life, even into DevOps and DevSecOps, I've never I've always been a believer that organizations have to modify and mold their development processes to fit their realities.

And that's a cross functional effort that comes from the engineers, the program management, product, product marketing, and everybody because you never wanna be in a situation as a part of the nation, whether it's a DevOps or DevSecOps, where you built a process that you can't support, that there's always a lot that that there's always a a break from it because process is broken. Yep. So bringing this back around to open source, what, I mean, how, how do you measure whether or not your process with open source is healthy? I've given that a lot of from a DevSecOps perspective, but when I was preparing for this call is it's going to be organizations that are going to want to look towards the economic aspects of it, of course. But you also want to look at it from the security benefits perspective, see if anything is measurable there, also see it from from an adoption perspective.

I mean, we've talked you know, there are gonna be issues sometimes with open source licensing, but us have to look is bringing an open source solution near DevSecOps pipeline. Is it is there the documentation available to support developers having to work on it? Is there internal ownership over that open source software? Whether it's the lone developer who's an advocate of it, whether you have an internal sort of open source tools team, or you're a large enterprise with an open source program office. There's measurement means a lot of different things to a lot of different people.

And part of the adoption of open source, this is something that why I I came to the topic of open source and dev SecOps is you have the additional measurement tools in there to do the small projects, to do the proof of concepts, you know, and learn from the data that that that your tool chains and your registries generate. I'm nodding my head. I I do like the idea behind, yeah, just paying attention to some of the things you brought up and then having the conversation about it. Yeah. It there's so much more data and analytics and information that you can take advantage of in a DevSecOps pipeline that is going to help tell your open source story.

It's going to be able to show the developers fun on the team. Are we on the right path? Is it the right solution? It's going to show executives above it who are like, 'Ah, not so sure on this free software stuff.' You know, you have to collect the hard data first and metrics and then, it's gonna be cases where everybody's gonna learn from it. But, in cases of when you have a development team that's tapping into their information appropriately and they have a writer or a solution architect package up that information just the which in just the way that your executives or or business stakeholders need to see it in a language that resonates with them.

Keeps reminding me of, when we talk about this person who is, like, the the liaison between the 2. I keep thinking back to the movie Office Space where they're interviewing. I don't remember what the character's name is. They're like, what would you say you do here? And he's like, I talked to the customers so the engineers don't have to.

What the hell is wrong with you people? Oh, thank god for those people. I know exactly. Right? I mean, it was a funny point in the movie, but it's a role that you absolutely have to have.

It's true. And I think but like I said previously, the role of the technical writer has not really been part of the devs of, like, the real full DevOps discussion thus far than where I would like to see it. And that's a role that somebody like them could fill if they have the if they have the technical chops, sort of the process chops and, and in their conscious of process and audience. Another interesting trend that I'm starting to see is the rise of the DevOps product marketing manager. And I'm wondering what kind of, I'm wondering what kind of influence that that may have in the future of the DevSecOps adoption.

Granted they're gonna be vendor centric. They're gonna be it's gonna be first about their, you know, their employer's solution. But a lot of those products, marketing skills are transferable to some of those communications and outreach problems we've touched upon. Yeah, for sure. Just trying to think through anything else that we should talk about here.

I think we had a couple of interesting things we haven't touched upon yet, Software bill of materials. I think that's going to I see that that's going to come in vogue again, probably not again, but I think that's going to get renewed attention for open source software as well as commercial software that's going to enter the pipelines. So think of it this way, in the case of an SBOM for an LSS project, the LSS project is not going to generate that. So when you're intaking or onboarding open source software for your projects, that's gonna fall down to an internal responsibility. That internal responsibility could be the developer who wants to use that open source project at a smaller, you know, in a smaller scale organization.

However, in a large organization with an open source program office, that would fall under the one of their responsibilities and that software and SBOM that's stored away, you know, internally. And I also think that OSS procurement itself, I think that's, that's gonna become a new skill set. Gonna gain renewed attention to large enterprises. Has it's probably the ultimate cross functional or dysfunctional team that's bringing in your developers, your cybersecurity team, as well as your back office teams like legal and procurement and everybody else. That that raises other chances or, you know, we're we're an we're an engineering team.

They have to make sure that their communications and their open source and their DevSecOps story is quite educational and resonates with other parts of the company. DevSecOps gives the tools and the processes, you know, to help do all of that. Yeah. I think that's a really good point on the OSS procurement. I it's something I try to advocate whenever I work with different teams.

If you see an open source library that you'd like to use, it's worth the time and effort. The things that I focus on, which are, you know, look at the look at the history of that project. You know, go to the git repo, see how many people are contributing to it, what the release cadence is, and try to give some weight to whether or not this library or package that you're gonna use has a good chance of being supported and updated and maintained for the, for the future that you intend to use it. And that's all stuff that falls under some sort of a pyramid office or, or a framework because it's gonna be counterproductive with how fast things move. These start of intake an open source library on on the sly, you know, or, well, I'll just do it and ask for forgiveness later and then ends up stagnant, or you go through the problems of the integration and then something else better comes along when you've done more of your homework diligent upfront.

Right? Now question for you is how do you see the involvement of developers in the open source come community? Let's say you're working on a development team where some where some the members are active in open source projects. How can they sort of contribute to open source procurement and that open source sort of outreach to the business? I think the the first step in that is to identify the requirements of what, like, what things you're looking for to be able to deem an open source package as as suitable for your environment or not.

You know, because in a lot of the scenarios, just thinking back to my past, we found a package that seemed to meet the technical requirements, and there weren't any real business requirements that that we had to follow again. So I think that would be the first first step is identifying what the business requirements are, you know, that it has to have a certain number of maintainers, it has to be a certain age. One of the things I know would be of importance is we can only use open source software that's one of these particular software licenses because some of the open source licenses prohibit you from modifying it or selling the works that you create from it, which can impact your ability to to sell your company. I think open source licensing is gonna become a new specialty. I think that's just gonna be a new area of expertise because I I'm still trying to wrap my head around it and which means a lot of other folks are.

Yep. Yeah. Especially whenever you look at some of the different the different open source licenses that are available from my non legal perspective, they all look the same to me. But if you give it to an attorney, they'll be like, oh, god. No.

There's so many differences. Yeah. Yeah. Okay. I would say so.

I always try to avoid the licensing rabbit hole personally. It's like, just because I'm a writer doesn't mean I'm a contract expert. Yeah. Yeah. That's true.

Experience in that. And sometimes even I've read them in the past, I'm left feeling Well, it's interesting too because sometimes they're just weird things too with the licensing. One example is, you know, going back to a rails example. And this was it made a splash in the Ruby community because one of the dependencies for Ruby on Rails wound up it turned out that they had overlooked something, and they they had to change their license legally to a GPL license or something like that. Right?

And so, of course, then it meant that Rails, since it incorporated that dependency, also had to change its license to GPL. Right? And so everybody freaked out, and Rails went in and backed it all out and talked to the library owner and stuff like that. And so it it does. It gets messy not just from the standpoint of because Rails has an MIT license, which means as is do whatever you want with it.

Right? So so yeah. So, I mean, everybody freaked. Right? Because it's like, well, I don't want my stuff to be GPL.

Right? So everybody backed out all the stuff and they found a workaround and said, okay. You can use this version of Rails. It doesn't depend on this dependency, which makes license stuff. And, anyway, it was really, really interesting.

But, yeah, that's the other thing that I don't think people really think too hard about. So they're like, oh, well, my top level dependency is licensed the way I want it to be. And they don't think about the dependencies until the dependencies come around to bite them in the rear end. And I think the smarter, more forward looking organizations are gonna use SBOMs, sort of that open source procurement, open source program, offices to to be a little bit more proactive about that upfront, but it's gonna take a lot of learning and Mhmm. All hands being slapped, Bill.

I I mean, software dependencies, large enterprise software, that could be a rabbit hole. And Yep. At least I think at least now we're at a point where where the tools and processes are getting there, where companies can be a little bit more proactive, a little bit versus reactive about it, but it's gonna but it's gonna require a change in thinking. And that change in thinking is gonna be through DevSecOps, open source, improved open source, governance inside the enterprise, but it also both of those areas of expertise have to be made accessible to the business side, whether it's, the vice presidents, whether it's the business stakeholders, whether it's a legal department. And that's a lot, a lot of work with some people that still has to be done.

And it'll be interesting to see how that all plays out in the next couple of years after all these high profile breaches. I mean, working in the DC area like I do, a lot of organizations around me are affected by the executive order on SOC on cybersecurity. So SPON, supply chain security. But you're not seeing the HIPAA world or the PCI PCI DSS world sort of step out in light of the executive order. I mean, there's there's bound to be a trickle down into the commercial world at at a certain point, but hasn't hit the head on yet.

Yeah. It was interesting. I hadn't seen the, that executive order. Did you I had neither. Oh.

Not until I read the article and I was like, oh. Right. Right. Because interesting thing about e t and public sector enterprise software in the public sector is I live in one of the wealthiest areas in the United States. And, yeah, some of it's because of politics and everything else, but a good bit of it's because of proprietary software.

A lot of people around me. With the government moving to cloud, going to open source, that's all changing. And the executive order is it's looking you know, it's it's pushing for a a look inside things that that this town just has not offered the government in the past. And I've always said when it comes to the cloud and publics in the public sector and enterprise software, if if you peel away the bureaucracy, peel away the partisanship, if you peel away the politics, the United States federal government is just one large compliance play and security play. And there's actually things that the Feds can learn from the commercial world and vice versa.

And the executive order could be one of the pieces falling in place to to help make that happen at some point in future. But perhaps I'm being overly optimistic. Oh, I have words to say about the government and overly optimistic, but, I'll keep it to myself. I live in the it's Yeah. Yeah.

I know. I know. I I live around them, you know, so it's it's a case of the in my area, there's a lot of people who go back and forth between commercial and public sector, especially when it comes to cloud and and DevOps and DevSecOps. Mhmm. Makes sense.

Well, is there anything else that we wanna make sure that we mention or cover before we do picks? Nothing I can think of. Okay. Let's go ahead and do some picks. Will, do you have some picks?

Oh, why do I do? One of them just came up on the fly during our podcast today, because I know that the movie office space is actually kind of old now. And I don't want to think how old it is because that's going to make me realize we're not going to see Matt here, but if you're listening to this and you haven't seen the movie office space, you just got to drop whatever you do in right now and go watch office space. It's going to redefine the rest of your career. It's like, I'll be back in an hour.

Have you not seen it? I haven't seen it. Call you Bob man. Call you. Yeah.

Right. It's the career manual for software engineering wrapped up in a movie. And I'll, I'll just leave it at that. The other, the other pick I have. So I was on YouTube the other day and saw a YouTube video with, Joe Rogan interviewing Brian Green and Brian Green is, he's an American theoretical physicist deals a lot with like the origin of the universe and, and like Einstein type stuff, you know, the theory of relativity and those kinds of things.

And I've always been kind of interested in the things he has to say. And I, I usually don't watch Joe Rogan stuff. Cause if you want to watch something from Joe Rogan, you know, it's like a 4 hour commitment or something because he just keeps going on. But I did watch this one and it was just, I started watching it in 5 minutes into it. I just set aside the next 2 hours to finish watching it because I thought it was really fascinating.

So I'll, I'll put a link in there. It was, Joe Rogan and Brian Greene chatting about the beginning of the universe, the end of the universe, aliens, relativity, all of that kind of stuff. It was good. Nice. Yeah.

I found that some of Joe Rogan's stuff is terrific. And some of Joe Rogan's stuff, it's it's fascinating, but not really stuff that I want them to sit through 4 hours to pick up. And so, yeah, that sounds like a good one. Yeah. I I love the guest that he has on there, but it's just like, man, I my wife can't get 2 hours of my time.

There's no way Joe Rogan's going to. So true. Yeah. I love that he get kinda gets everybody. Right?

I mean, all comers from all different groups, opinions, walks of life. You get some really, really interesting perspectives on there. And then I love how, like, he gets people on there that I'm thinking I'm gonna hate this episode because there's absolutely nothing this person has to say of redeeming quality. And I'll sit through 2 hours of it and go, that's some perspective that I really hadn't gotten anywhere else. Right?

So Yeah. I'll have to check them out. Yeah. Sorry. I keep chiming in on your stuff, Will.

Are there anything else you wanted to pick? Nope. That was it. Those are my picks for the week. Alright.

I'm gonna throw out a few picks. First of all, I am gonna throw out just a pick, for my podcast boot camp. I've been coaching people for the last 6, 7 months on starting podcasts, so I'm, sort of tangentially responsible for some of these folks getting their shows out. There are 3 or 4 dev shows out there that I've been involved in over the last few months coaching the hosts on getting them out there. So if you're looking at raising your public profile, if you're looking at kind of taking your career to the next level, and that could be junior developers or senior developers.

I was I was brand new developer when I started podcasting, and it made a huge difference in what opportunities came my way. But it also was really helpful when I was freelance finding clients. So if you have any of those reasons or you have something else to market a course or things like that, I can definitely help you. The boot camp is gonna start on the 21st. Don't quote me on that, but around then of September 2021.

So, come check it out. It would be 4 weeks. In 4 weeks, we'll have your podcast launched, and you're gonna be sounding terrific, reaching the people that you wanna reach and making the difference you wanna make. So go ahead and jump in and, get involved there. The other pet project that I have going on is JavaScript picks.

It's more aimed at the JavaScript Jabber audience. But once I kinda get that grinding along and working well, I do intend to launch something similar for DevOps. And so it's gonna be a learning directory that includes podcasts, videos, courses, books. I mean, you name it. Right?

But then it's also gonna have tools, libraries, techniques, you know, blogs. You know? So all that stuff too, you know, all the technical stuff, and people can come and write and review stuff. You can list any projects that you have out there that people can use. And I really just kinda wanna make it a one stop place where people can come and say, I need this problem solved.

Right? I want whether it's I wanna learn this. I wanna know more about this or whether it's I need a tool that will do this for me. Right? And then it'll say, you know, okay, well, you can use Varnish or you can use, you know, whatever other load balancer, you know, hey, you can use, you know, this or this or this.

Right? And then you can get the ratings and reviews, and then you can go look and see what learning resources there are for it. So that's that's what I'm building next. And then I I have more plans after that. I I should sit down.

I talked through most of the master plan, with Jeff a few weeks ago. So you can go back and listen to that episode, but I'm gonna put that out there. And then as far as, like, not Chuck stuff picks that Chuck's gonna pick, so I finished, what was the book? Ready Player 2. So if you read ready player 1, which was a terrific book, the movie was pretty good too even though it didn't really follow all of the.

Anyway, so so we got 2 great stories with the same characters is what I'm saying for the the movie and the book. Ready player 2 wasn't as good as ready player 1, but it was good. So if you really like ready player 1 and you want you want more of kind of the same kind of thing, then pick up ready player 2. Just don't get your expectations that it's gonna as high for ready player 2. And then the book that I'm reading now has just been fascinating.

It's Masters of Doom, and it's by David Kushner. And he he kinda tells the story of where the video game Doom came from. Right? And so it Wow. It it talks through where the founders came from and, you know, how they built their company and stuff like that.

And it's funny too because I never put together that the people that made commander keen were the same people that built doom. Right? Oh, my god. I did. And, you know, so it talks about all of the the stuff.

And so you've got the business people and the tech people and the, you know, the artistic people and, you know, where they were at and what they wanted and what their expectations were halfway through the book, but it is really terrific. It's a fascinating book. There was some turmoil around around that game. Yeah. Yeah.

The first chapter or the prologue, I think, it talks about how John Romero and John Cormac, They both showed up to a gaming convention and kind of acknowledged each other's existence because at that point, they weren't friends anymore and had split the company. So it kind of says, hey. You know, these guys were the titans of video games. And, you know, and so here's the story. Anyway, it's really fascinating.

So but, yeah, it's it's really, really good. So I'm enjoying that. And then other books, I pre ordered the last Expanse book. And so, of course, now I have to be able to send to all of the rest of The Expanse books. And so I I'm back on Leviathan Wakes, which is, book number 1.

The TV series is really good at 2, and they actually stay fairly close to the book as much as you can in the miniseries that, you know, represents a book apiece. So, but I'm I'm really enjoying it. I'm getting back into that, so I'm gonna pick that as well. Yeah. Stay tuned for more stuff for me because I have big plans for top end devs, but yeah.

Anyway, those are my picks. Other Will. Will Kelly, how many, do you have some picks for us? Picks for us. One is Wire.

Haven't had a chance to watch it. I highly recommend it. Unfortunately, last weekend, one of the actors from the show, Michael k Williams, died of an of a suspected overdose. That's a loss of that's a loss of a great talent. But The Wire as a story and I'm speaking to somebody who was born in Baltimore.

It does tell just such a a rich story of hard and inner city life that I'm gonna say I wanna talk about. And it's an incredible story. It's an incredible series that really doesn't have a hero. Just not everybody is an anti hero in its into that story. Another pick of mine is Ted Lasso.

One of the things that when the pandemic and isolation has gotten me down that's always picked up my spirits has been Ted Lasso. I'm trying to figure out a way right now to pitch a story around sort of the management principles in Ted Lasso and how that might apply to DevOps and DevSecOps. But, still trying to work through that that idea. And, my last pick is opensource.com. The site of where you found my article on DevSecOps and open source story.

It's a great site that with a range of open source topics, tutorials, lot of coverage on DevOps. I highly recommend the site, little bit biased, but the good thing is it's such a cross section of so you're gonna hear so it's a range of voices across the site. I've always learned a lot from us, and and, you know, that's how I got here. Cool. If people wanna connect with you personally online, so hear from you, see what you're working on, whatever.

Most people they give out, like a GitHub, LinkedIn, or Twitter. Follow me on Twitter at my Twitter is at willkelly, w I l l k e l l y, all one word. Awesome. Well, thanks for coming, Will. This was really fun.

Thanks for having me. You guys really put me at ease. I was in a minor state of panic before it started. I really made the. Now thank you for that.

It's all good. It's all good. We we're pretty chill around here. So So yeah. And probably just like a lot of folks in in the guest space.

And I hope that as far as unlocking my own self, you know, I hope podcast will help out. Yep. Awesome. We're gonna wrap up right here. And until next time, folks, Max out.