Warren Parad is the CTO at Authress. It is a User authorization API for software makers. He joins the show to talk about Open-source Software. He explains how open-source software is used in enterprise organizations, what functions it serves, and what trade-offs and difficulties come with it.

 
On YouTube
Open-Source Software & Its Maintainability With Warren Parad - DevOps 147

The Adventures in DevOps podcast is a show that explores the exciting world of software development and operations. Each episode features interesting guests from the world of technology who share their experiences and insights in a wide range of topics related to DevOps, including continuous delivery, infrastructure automation, and the culture of collaboration. Whether you are a seasoned veteran or just starting out in the field, the Adventures in DevOps podcast has something for everyone. Tune in to learn, be inspired, and stay up to date. on the latest trends and best practices in the world of DevOps. I'm your host, Jonathan Hall, and today in the virtual studio with me is Jillian.

 

Hello. And that was a very nice intro, Jonathan. Where did that all come from?

 

Thank you, I just made it up off the top of my AI head.

 

Oh wow, that's great. We'll have to talk so much more about that.

 

And with us today we have Warren. Hi Warren.

 

Hello, I'm Warren. I'm the CTO at Authress. I can talk a little bit about that. It's

 

Yes.

 

sort of a tech company that builds SaaS products, authorization, authentication as APIs for software makers to get over those difficult permissions and access control challenges. Hopefully we don't talk too much about that today though.

 

I was about to say that's great, because I never want to have to code any of that stuff ever again.

 

Well, you know, then we can spend the whole time talking about that. That's only like been the recent part of my journey though. Before that, I worked in a little bit of healthcare and e-commerce and been all over the place, mostly in the U.S. But in the last few years, I actually moved to Switzerland and that's a great place and we could spend the whole time talking about that too.

 

Well,

 

Let's

 

let's...

 

talk.

 

yeah. Sorry, Jillian, I didn't mean to interrupt you there. Continue, please.

 

I was just gonna say, well, let's talk about what you want to talk about. That's what we're here for.

 

Yeah, what are we talking

 

Yeah,

 

about today?

 

so, you know, I wasn't sure. There's always so many things going on, but with recent controversies and whatnot, I felt like open source was a great topic to sort of jump into and discuss. And it doesn't require a lot of in-depth knowledge or blog reading to get on the same page with that.

 

Cool. So maybe you want to talk to us a little bit about what your relationship is with open source. Are you a contributor, a maintainer, a consumer? How do you interact with open source?

 

Uh, yeah, I guess all of the above, unfortunately. Uh,

 

Ha ha ha.

 

so... I think probably early on in my career, I definitely got the hang of GitHub and got rejected from their private repository program. So you got experience with posting yourself in the open web and having other people see it potentially. But I think working at any sort of enterprise company or even smaller ones, you are forced to interact with the libraries and packages. You're just not going to be able to build everything yourself. So you've got to go out there and find it. And I think the quality is just a little bit better than Stack Overflow when it comes to pulling code in and starting working on it and whatnot.

 

adjust a little bit better. That's a pretty low bar though. Ha ha ha.

 

Well, you know, that's actually really interesting because I think, you know, this is like one of the myths that like, it's just so much easier to pull something out there in the world and come in and it solves whatever problem you've got at some scale, right? And it's true, right? Like definitely can help get over to something. But I feel like in the next five minutes after you start using it, you start asking all the questions like, wait, how do you do this correctly? What is like, what are even the parameters you pass into this? What is the interface? Then you start reading the documentation, which is, no one's updated that in months. So you jump in there and. that's a whole other experience. You start to become an expert with whatever that is. And like, okay, maybe I could just change this to add in a parameter to make it do exactly what I need to do. And that's when you become an expert in that particular library and you hate the code there. I mean, I think there's a good old joke here that like no engineer laughed and a new one came in and was like, wow, my predecessor, I love their code that they wrote.

 

Ha ha ha.

 

I think you know, when you didn't write in at someone else's, there are just so many challenges. And some of these older libraries that have been around for a while, they have the patterns from. the history of whatever the language were that significantly changed. So at my company, we do a lot of like JavaScript type script, uh, stuff, just cause we just up in the web space and there's a lot of our users focus on that. Uh, we have other languages too, of course, but, and JavaScript's evolved so much over the now like the LTS version is 18 and that's, you know, over quite some time and so things have significantly changed. So you go back and you look at a library that hasn't been updated. And it's like, I'm not even sure I know how this code works anymore.

 

That has been my experience with JavaScript. I've learned it a few times, and every time it's completely different.

 

I think I can identify, yes.

 

I mean, I think a similar thing happens with other languages. I don't have as much experience, but like I've done a lot of Java and C sharp and some other languages and. There have been huge changes in there as well, which just make it a challenge to go back, like significant things that are different between C-sharp versions, conversion to.NET Core, and then back to whatever standard is that Microsoft decided to do. There are like fundamental library differences. You can't just like cross compile and get it up and working again. The code looks the same, so it's deceptive in that way. But I think that's pretty common. And I think that's one of the core challenges that if you're working at a, company, you have maybe even the tools you built yourself, which is its own sort of problem, but it's maybe consistent in some way that you'd be able to go somewhere.

 

I think JavaScript might be worse, although this is probably just my own experience. And part of that, I mean, obviously the ECMAScript 6 change or whatever was a huge one. And JavaScript doesn't even look the same in certain ways. Function definitions have changed fundamentally. I shouldn't say fundamentally, superficially.

 

Yeah.

 

If you know what it's doing, it's pretty obvious what it means. But until you do, it's like, what? This isn't a function anymore.

 

Yeah.

 

But if you consider the frameworks, at one point we were writing straight JavaScript, and then along came jQuery and changed everything. And then jQuery fell out of fashion. And then, so if you consider each of those sort of milestones, there's a lot of change. But yes, if you look at libraries, what libraries in Vogue, and whether it's C Sharp or Java, or whatever language, Perl or Python or whatever, that changes all the time too. So

 

Yeah.

 

yeah, I mean, you kind of have to keep up to keep up. There's really not a shortcut, is there?

 

I mean, that's a good one because actually I recently found a couple of highly used libraries. One of them is got and another one, I don't even go out there and find, I'm sure you can find complaints that, oh, they no longer work with common JS, which was like the standard strategy for imports anymore. So now a lot of them are searching the modules and you have swaths of users complaining that, hey, like I can't import this anymore. I need to be using some sort of babble or bundler or. transpiler to even make it work out of the box because modules do not directly interface with non-module code in a straightforward way Maintainers are complaining. Oh, yeah, you know we did this because people wanted it and we're not going to maintain two versions of our software Because that's a huge challenge. So it's definitely sort of this well You can pull something off the shelf But as soon as you include that library you become de facto a winner like you're responsible for your own software you don't know what the maintainer's gonna do or the direction they're gonna do. You're gonna potentially have a problem down the line when they change something and now you're on the hook for, well, do we use the older version and then make it our own or do we switch our library at this point, which you can't swap out an HTTP client or some other functional provider and just expect the interfaces to be the same.

 

Right.

 

I think here one of the questions often comes up that, like, you know, should you even use open source? I think there's a security angle that people are bringing up. Like, I think it was a couple of years ago, especially with like who your dependencies are to start publishing things like S-bombs,

 

Mm-hmm.

 

software buildup materials, so that your customers know if you're potentially affected when they find out about security vulnerabilities before you do. I don't know where that's going. I think there's some interesting aspect to it. But I think it's a good reminder that open source isn't necessarily secure. But I don't know that S-bombs are going to be the solution. But there's like tons of these SNICs or Amazon's got one for code scanning. There's tons of providers out there that you can go and look them up that promises to review your software or the dependencies and find whatever security vulnerabilities are actually there.

 

I remember when I was fresh out of high school, so this is 1999, I think, I was working at an ISP. And Linux existed, but it hadn't taken the world over yet, but it was certainly known among IT professionals. And the ISP I was at was using open, no, it was BSDI, using BSDI for a lot of operating systems. And I remember asking one of the co-founders, why didn't you choose Linux? And his answer was, I didn't want open source. I want somebody. who is contractually obligated to fix a problem if I find one. Now, of course, we know now in retrospect, maybe this didn't exist then, but by now, certainly you can get those contracts even for open source. But I think that's an interesting way to look at things. And the security angle is also interesting because you can hear, I always hear both sides of the story. One is, open source is insecure because, and you know, you can look at these NPM bombs that we've seen or whatever. But on the other hand you hear people like Linus Torvalds and you know people in his or What's the guy's name Anyway, it doesn't matter. Making claims like, you know, with open source, more eyeballs means better security. So I can see both sides here. It's a really interesting question, and I don't think there is a single right

 

Thanks for

 

answer,

 

watching!

 

but maybe we can find it today. I don't know.

 

Well, I can share some of my experience, I guess. So. I think there's like a lot of software which is insecure. You brought up the Linux thing. I love that conversation, which is sort of a separate one. And I remember at more than one company I've been at, they had some sort of regulation and their interpretation of the regulation was, we are gonna clone every single library and package on the internet that we use internally into an internal artifact registry. And I love that they think that this was a solution for security that you wouldn't get, as you mentioned, the JavaScript bombs. And I think it's clear, two seconds about that, that some of these maintainers recently, to support war effort or whatever their reasoning was, they made a change to their library, which suddenly started spewing out nonsense on the command line or to log files or whatever, corrupting what was there, and had some actually real world impact, negative impact to some organizations that they didn't intentionally want to have any malicious perspective towards, but ended up having that. I do think the eyeball answer is a good one. It's much better than trying to implement security protocols yourself. Like I trust NPM to do security scanning way more than I would trust a smaller organization that doesn't have the capability or expertise cloning that in and pinning versions. Things are gonna move, things are gonna change faster and what was potentially insecure before. Like let's say you jump from HTTP2 to three or TLS, you still want 1.2, you can go to 1.3 library, they're using open source version, but if those need to be vetted internally, you don't have the world's leading experts in package vetting.

 

Right.

 

Maybe you do, right? And then by all means, clone those packages internally and go to town. But I would go work for that company that's running it, which of course now is Microsoft. I feel like when it comes to open source, it's hard not to name them. I almost say they who shall not be named. But good decision or not, I feel like they're definitely at the forefront in a lot of ways.

 

Yeah, I mean, unless your surface area is so small that a single person or team can understand it, which is rare, then yeah, that's just a it's a it's a losing game, in my opinion.

 

No, definitely.

 

Well, Will has joined us. Welcome, Will.

 

Yeah, I, um, I

 

Thanks for watching!

 

joined and heard you talking about running bulletin boards at an ISP and thought I joined like back in time or something.

 

Yeah, welcome to 1999.

 

Nice. It's good to be back. Holy shit. Stay away from the future, man. It's just not fun there anymore.

 

How are the flying cars there in 2015?

 

Right?

 

So we're talking about open source. Yeah. And the security aspect, I guess, is where we were

 

Thanks for

 

right

 

watching!

 

there. So.

 

I mean, this I think comes up a lot for us specifically because we're in the security space. So what we're end up using and building is important. So what we can, I think we're like expert implementers in a lot of ways. We look at the crypto space, not cryptocurrency, but cryptography,

 

Real crypto.

 

whatever.

 

Ha ha ha.

 

Yeah, real crypto, right? The underlying, I mean, it's really interesting because. There's a lot of inspiration you can take from the decision to back money with crypto. Right. Like what are they using and that they claim is secure from the brute force attack from the entire world, like totally public. Like people say, oh, yeah, don't encrypt your secrets and put them on the public internet because someone could break it eventually. And then they have access to your secret. Well, hopefully you're rotating it at least once a year. But even if you're not like the Ethereum ledger is out there. Right. You can go guess all of those. private keys if you want. And we go and we look at it, like we evaluate, okay, what are they actually doing there? It's like, okay, well, they're doing something actually pretty intelligent. And if we look at what companies are doing that have... you know, quote unquote, they're supposed to have good security posture. They're nowhere near that level, nowhere near that level of expertise. So we do implement a lot of different strategies and like a lot of our, one of the things we evaluate on, like our competitors on, like someone will ask us, hey, have you ever used quote unquote, you know, you know, name a random competitor in the authentication space. And it was like, okay, great, you know, let me, let me break down for you what they're doing and how easy it is for someone to crack their security given enough time. And they're not that advanced. They're still way more advanced than anything you'd build yourself. So that's sort of an interesting aspect. There's a comparison of the do you use a SaaS product versus open source? Is open source more secure or a company that is focused on it?

 

Let's talk about that a little bit. I think that's an interesting angle. And I think maybe we should start with definitions, because in my mind, open source and SaaS are not exclusive necessarily. But I remember a conversation I had recently with somebody else. Um.

 

you

 

who I think he put a LinkedIn poll, he asked, what is SaaS? And two of the options were one was a business model and one was a distribution model. And they both got relatively equal votes. But his point was it's actually not a distribution model because SaaS, we often think of SaaS as something web based, but it doesn't have to be. And I remember I used one of the first companies I worked for in my career, we sold a SaaS that was installed on physical servers. You know, we would install the software on a server and mail it to you, and you would put it in your data center. But our licensing, our business model was SaaS. So I would like to hear from you when you talk about open source versus SaaS, what do you mean? And then let's dig into the nuances there.

 

Yeah, uh... I mean, I guess you can't use any more. Like it used to be your software is private, but I think we see companies like GitHub or GitLab and just a number of other ones. I want to say part of Honeycomb stuff, just anything that runs as an open source model, they take their software, they build it not totally in public and then run the licensing or subscription on top of it, or they have a managed version that you pay for, but you know sort of what they're running. So we can't use that as a de facto aspect.

 

Mm-hmm.

 

I think there is something about the service you're offering. So it doesn't matter what you're running, but you're selling something, right? So, company that. It's the service that's the software. So, your customer's software, or technical at least, probably software engineers, and they're using it as a component of their own product. Maybe GitHub itself is a SaaS model and its products are open source libraries. Maybe that's a stretch, but I think that's aligned here. So

 

Mm-hmm.

 

like we have open source libraries that our company contributes to. I do a lot of open source development. So I find like a lot of libraries out there that I don't wanna touch or don't do exactly what I want. And it's not a good story to try to get them fixes implemented or improvements that are necessary. Well, I can just have a whole talk about that, I guess. You know, it's like you find something and you really like it and you start using it and you use it for a while and You start finding a bug one or two that affects your product or whatever you're building and you have to go in and somehow Work around it some libraries some languages offer opportunities to fix those other ones You really need to change the source code. I think some of the things are stylistic like this is confusing It needs to be different. One of the things we fork not too long ago was a open API that exposes your open API specification for APIs in a visual way. And so a lot of that is a user experience. So while the functionality could be similar that we needed, the whole UI had to be changed. It just wasn't well maintained. Also, we hated Swagger at the time and like we wanted something better. And that, yeah. I mean, we had used that, like I used that like three different companies before it got sort of taken up by open API. specification foundation or what the opening API initiative. And then we're just like, there has to be something modern that we don't have to pay for a developer portal that we can host simply in a AWS S3 bucket. And there was some things, but we ended up pulling a bunch of things together and making it our own and then open sourcing it because we're not a API. We don't sell APIs. We sell a product that it has an API, but that's, you know, it's not a management portal. And that sort of goes along things. Like we found one library where we do serverless and we need like cold starts are a huge problem. And we pulled in a library and it had like a five second startup time for static library. And it's like, okay, well, you're not gonna fix this problem by going to library and trying to change it. You will break implementation. Someone will say, oh, we want the huge startup time on the front side. So we ended up forking that and making a lot of changes. And then halfway through the process, we realized actually this library is terrible, terrible. Like what are the other competitive libraries out there that we can go and try to see? And none were that great, but we did find a different one and we ended up forking that off and then re-releasing that. And then we have stars on GitHub that go for a long time on this. So we are unfortunately in that space. And then all of our customers are like, we used random language, throw it in here. I think we have eight or nine SDKs in different languages. And each one is, I mean, it's not a lot of open source, but each one depends on frameworks that are written by those. And every single one of those has completely different understanding of how you should have just a simple SDK, a simple HTTP library. Like these are simple things, and yet everyone's a huge challenge to deal with. you asked about the difference between SAS and open source. I hope we're getting closer

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

to that answer.

 

We could just ask chat GPT.

 

Yeah, that's how he introduced the show. Let's see what's working now.

 

Yeah, I mean, like I said, controversy, I mean, there's that one that that's sort of new, I'll call it a controversy. I don't know if it is technically, and there's like the GitHub Copilot program. So for those that don't know, GitHub started releasing auto code generation via AI, sourced from files on GitHub without the license. So like, you can't say, don't give me code that was generated from licenses that I can't use, for instance. Which is,

 

That

 

I

 

sounds

 

mean...

 

like it's going to have some interesting repercussions. I don't know what those can, like, I don't even know what those look like, but I mean, yeah, I know, I know, like, that's kind of a big deal in my line of work is that we have to, you know, scan the software and make sure that underneath the hood that there isn't some dependency upon a license that can't be used, right? It's pretty much all going to be like Apache or MIT or something like that. Even, you know, like. I don't know, even some of the licenses that are sort of open source, but the one that says, oh, you have to contribute back, things like that can't typically be used when you're designing a product, right? So

 

Yeah, one

 

that

 

of the

 

is interesting.

 

GNU set. Yeah. I mean, I don't know what's gonna happen there, right? I mean, I think it's probably on its way out if we've already hit the next level of technology, which is chat GPT. I mean, I have to say, like I knew where open API was from the previous GPT-3 models, just text generation, content generation, but like this is just a whole nother level that is just surprisingly good compared to where they were before.

 

You would think that of all people Microsoft would probably be sensitive over using code and software licensing and the potential legal ramifications of that. Because, you

 

They're

 

know,

 

only

 

they've got

 

sensitive

 

a bit

 

as their

 

of

 

care

 

experience

 

code.

 

anymore.

 

in that field.

 

Like, I think they're just kind of over that at this point. Like, ah whatever, we bought GitHub, like we're good.

 

I like the sentiment. I think there's this joke that has been around forever with a graphical representation of the internal organizational structure of different companies. And I do think that the Microsoft one is a bunch of different completely disparate areas holding firearms towards each other.

 

Hahaha!

 

So I... And I haven't worked for Microsoft, so I have no experience to know whether that's true or not. But if you look at that, or companies like Amazon, how they become very effective, they are pretty segregated. It's actually burned Microsoft a couple of times because they're like login portal, the login credentials, authentication. They have five or six now. LinkedIn has its own, then there's GitHub, and then they have Live and Outlook and a couple of different Azure ones. They allowed back doors into each other. And so live was like an old version of live was vulnerable and it allowed a count takeover in Azure a couple of years ago due to this. So for better or worse, I can imagine it staying segregated at least a little bit.

 

Yeah, I like, you know, I think at the end of the day, while we always have technology problems and actual technology difficulties to face, there's always like also the people problems as well that seem to kind of cause more trouble in my experience. Right, like especially these kinds of ideas with having the open source libraries that maybe lots of people rely on or depend on, there's like a team or a person or a company or whatever behind that and they built that library for a specific purpose rather. And at some point they're probably going to change directions or do something that is not optimal for your use case. And it's like, well, what do we do then?

 

I think you nailed it. Like that's actually a huge aspect. Like these libraries don't exist. for no reason, the best ones maybe with someone in their basement writing something for fun. But I feel like a lot of the open source is definitely driven by companies with some goal in mind. Like I'll say it, ours, yeah, it's definitely brand awareness and advertisement. Like you start using these products that we put there that are free, they're not our core business model. And you will learn about our services, what we offer and how they integrate. And companies are definitely doing that. And I think there is this myth that you can just go and contribute to an open source library and it will get pulled in or can report a bug and it will get fixed. I think you're lucky if you get closure on whatever your problem is, because I found most of my pull requests stay open for years, issues. Like if it's certain companies who I won't name names, will auto close in 30 days. And I'm like, no one's looked at this. And yet you're saying because no one's looked at this, it should be, I'm like, if this is a real problem, at least acknowledge it. Or if it's not a problem, be like, no, you know, Because you're absolutely right, Jillian. The direction of the company is super important. Like when we pull, if we were gonna buy a product from a company that wasn't open source or whenever you buy anything, I think people do realize they need to evaluate the company that's providing it. What's important to that company? What direction they're going? I mean, you do it for non-software related things. I definitely do it, part of my responsibility is to do it for tech related things. If we depend on this company, irrelevant of the size of the company successful? Do their values align with ours? Do we want to pay them money for this or not?

 

Well, that kind of leads to like an interesting change that I've seen, maybe like more in the open source data science space, because that's where I am, where there was a really big problem for a long time of software being created. And then the people who created the software, like it wasn't a part of their, you know, their day job, maybe they were doing it, you know, labor of love, maybe it was like a job that they had and they left. Maybe they were PhD students who weren't being, you know, paid enough to eat, all these kind of things were happening. And then there was major software that people were really, really relying upon. And it became like it accumulates bugs or isn't able to be built on a newer system or whatever. And it was like, well, what do we do about this? What is kind of maybe society is too strong of a word, but the tech community, well, what are we going to allow to fail and whatnot? And if these are things that have to be here, and we have this kind of open source model, which in some industries it has to be there. If you're doing public research, the software is supposed to be public anyways because it's being paid for with taxpayer dollars and all these kind of things. But what is the solution? And it seems like in the data science space, we're gonna build this open source library and it's gonna be a source of shameless self promotion, which I'm here for. You can go to Bioanalyze and see all my shameless self promotion.

 

Yeah

 

But then a lot of these... Libraries have like companies behind them and then that's how the software continues to be maintained and built But then of course you do still have this problem where you know I could purchase the the enterprise plan of the software for the the support and the shiny things and then in a year they could Decide to completely change the direction and I guess I don't know what you're just kind of out of luck then

 

You know, I think it's one of those

 

sucks

 

problems

 

to be you

 

that it's exposed because of the model, but not a new problem. Right? Like nothing stopped any of the companies that you depended on in the past from going under or changing direction. But suddenly it's open source and you start asking yourself these questions. I find it happens a ton for me in my work. The migration from monolith to microservices, people start questioning, oh, well, now we have this problem and that problem. And I'm like, you always had these issues. Like you

 

Yeah.

 

just decided now is the moment to start complaining about the fact you don't have a solution to that. But yeah, I mean, obviously those those libraries can go under. Maybe the good thing for open source and be like, yeah, we always depended on this. We always were responsible for making sure it worked with our software. At least we don't have to contact a company and get them to fess up their source code. Like it's it's just there. I can go and pull it in and start using it. No problem.

 

Yeah, definitely. I mean, if you discover a problem with GCC or something, maybe you don't have the skills, but you could acquire the skills or hire somebody who has the skills to fix it. If you were using Borland C++ and it had a bug, sorry, dude.

 

I love you brought up that example. There was, because I tried to do this not too long ago. One of my least favorite Linux commands is LN link. And I always got the order of the parameters wrong. And I'm like, well, from a user experience standpoint, the order doesn't matter. One of these things exists and the other one doesn't. This is the real file and the link. And I went and I filed the issue and we're having discussion with the Linux maintainers of the package that manages this. And they're like, No, you're wrong. You're like, I think this is simple and people should understand it. And I'm like, I don't know what to tell you. Like, I can't remember this every single time. I have to do it. I have to look at the documentation. Which way is it? And it's just, there was just a mindset thing about the expectation that was built around this. So yeah, just going and fixing open source. It

 

Mm-hmm.

 

seems like it's easier than it really is.

 

It's funny that you bring that example up because it's been 30 years for me and I still can't remember the order that they go in.

 

I always get it wrong.

 

You know, okay, so I actually, while I was having the discussion, I found the epiphany, which was it's the same order as copy is. So the real thing comes first.

 

Yeah. Yeah.

 

Okay.

 

Or move, they're all the same. So move from real location first. And since then, I haven't had a problem.

 

All right.

 

It's good to have these nice memory devices

 

I think

 

as

 

that

 

things

 

is the

 

move

 

money shot

 

on.

 

right there. That makes this episode worth listening to.

 

Right?

 

All the way at the end, right?

 

Yeah.

 

You come for the open source, you stay for the learned lessons.

 

We have to put that in the show notes.

 

Right?

 

Listen to the whole episode to learn how to use LN properly. Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Hahaha

 

Great. Ha ha ha.

 

I'm glad it's not just me.

 

It's not.

 

We can use that. It took me 30 years, but you'll get it in a one hour episode.

 

Hahaha

 

Adventures in the Linux command line. Here we go, episode one.

 

That could be a whole show.

 

Hahaha

 

That should be a show. Next week.

 

You know, you have to find someone that's fit for that, right? You know, I like it when people bring up Linux and open source thing because they're like, well, what should we use that? When should we use open source or when not? I'm like, libraries are great. You know, whole services stay away from. Because whatever you pull in, you're going to become an expert, like 100%. Like it doesn't matter what it is. It's just an easy way to skip to the part where you already built it. But then you're going to support it and maintain it. And when it comes to a service, like that's really a crux of your organization or your technology stack is going to start depending on that, which could be a huge problem in a lot of ways. And then I usually, the example gets thrown at me like, what about Linux? Right. I'm like, well, tell me about all. who runs Linux as a desktop and isn't an, it hasn't become an expert in everything that could possibly go wrong with that operating system.

 

Yeah.

 

For

 

I know

 

real.

 

it's my second job.

 

Yeah.

 

So you touch on a topic that I think is, I've been reading about, and it's gonna be one of my picks later on actually. But I just finished reading a book called A Seat at the Table, which is about IT management in a post-Agile world, I'll say, that's my phrase, not the author's. But he has a chapter about the build versus buy decision. And he makes the point that you should almost always build rather than buy. And his argument is that if you make the buy decision instead, what you're not really choosing not to build, you're choosing what to build. For most IT applications, you buy something and then you spend all your time building an integration around that thing.

 

you

 

I think that's similar to kind of what you're saying. You know, you could choose an open source tool, but then you have to spend all the time supporting it. You know, it's or as Microsoft used to say back in the day, Linux is only free if your time is meaningless or time is worthless. Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Hahaha

 

Wow, I mean, I think that's true for open source. I don't think it's true for SaaS. I think that fundamentally, when you're buying a product, it's about finding what makes it better. fits for you. And if you don't do a good job evaluating it, yeah, sure. I think the integrations you build around it is an important factor to deciding on whether a SaaS is good for you. If I found out that our customers had to build a wrapper around what we had, I think my CEO would fire me. Like that seems like a huge problem for those. And it definitely

 

Mm-hmm.

 

happens frequently. But I mean, I think what you're really paying for is the experts on the other side who are committed to doing that explicitly. It's not an implicit agreement, like open source is, that's running it, that someone may do this. Like you are paying real money directly to get that support. So I think I would welcome like, hey, users, you know, if you're an authorist customer out there and you're like, oh, we had to build this thing, like, please come tell me. I think there was a chapter in the Platform Revolution book that absolutely stuck with me, which was this notion of when all of your customers are doing something, that's the right time to capture that value, to pull that back into your core offering. That if everyone has to build the same wrapper around what you've got, change your product that offers the actual new interface as the core feature. Or at least take ownership over that open source piece of technology and have a Docker container out there can go and deploy easily with whatever that thing is that you're uncomfortable being part of your ownership. So I don't think I totally agree when it comes to the SaaS spot. I think the other thing I would say here, which is decide what your core competency is as a company.

 

Mm-hmm.

 

So if it's in this space a bit, yeah, don't go and buy it or even open, I mean, start with open source that you can find and then start altering that and selling it if the license agrees and it's not, you know, that prevents you. I mean, also don't build your own database. But you know, if it's your core competency, yeah, definitely start that process of building it. Become the experts. Learn the problems and every single one of the pain and suffering to go through that because it's your thing. But as soon as it's outside there, unless you don't have the money, like you said, and your time is worth less than the cost to do it, yeah, go for the SAS, definitely. area. It's like, oh, we're struggling with this. We're building this new thing. I'm just like, step one, step one, figure out everything you're doing right now today that you couldn't just buy off the shelf and integrate. And you will get back so much ROI on that, on that input. And then later down the road, see that you're paying this company millions of dollars or tens of millions of dollars, or in case of Amazon, billion dollars and be like, wait a second, can we reduce our costs then? You know, upfront predictive cost reduction is not agile, right? Wait till you have the problem before investigating and I think the advice is would be better go the other way.

 

You reminded me of an interview I heard not long ago with Simon Wardley of Wardley

 

Worthy

 

Maps

 

mapping.

 

fame.

 

Yeah.

 

Thanks for watching!

 

He was on the No Nonsense Agile podcast, which is one of my favorites. If I recall, he was talking about a situation. He was at a conference or something in a group of professionals who I think were integrated with Salesforce or some other big enterprise service. I don't remember what it was. I don't want to pick on Salesforce if it wasn't them, but it was something like that. And they were all doing custom integrations. And so we just asked them, why are you doing custom integrations? They said, well, because nobody else has our exact business needs. So we started drilling down and asked them, what are your business needs? It turned out like 80% of the people had the exact same needs. Now, I don't know why Salesforce or whichever company this was doesn't just do that thing that 80% of their customers need. Well, I do know why. I can guess why. They're making money selling custom integrations, but...

 

Yeah.

 

It's a sad situation

 

Yeah, that's right.

 

if that's the case you're in, right?

 

I

 

What if that's my business model?

 

Yeah, well, your community is worth something, right? If you have a bunch of consultants that come up and advocate for your product over the competitors, like that's good for your business model in a way. So there's a relationship there. Like, do you wanna put your primary advocates and evangelists out of a job because you pull

 

Right.

 

that in? Now, and again, I don't know if it's Salesforce, right? But Salesforce I know is highly configurable. And so you are on the spectrum of highly opinionated to highly configurable.

 

Mm-hmm. Mm-hmm.

 

you lose value when you become more configurable because it doesn't offer the works out of the box solution.

 

Right.

 

And I think solutions like that would get better, provide more value by canning a bunch of different common strategies and providing them like a service on top of the service, if you will. So here's a blueprint for this sort of pattern. Here's a blueprint for this sort of pattern. And it's a one click auto configure every all the underlying resources, the whole platform, but the experience that the user gets is, well, this is exactly what I wanted.

 

Yep.

 

They just bought Slack, so, you know, and

 

All right.

 

there's a question that I have in my mind is, is Slack getting worse? because they were on that path or are they really getting worse because Salesforce bought them? You know, was it inevitable or you know, what's going on behind closed doors? And we know, I don't want to say this and it'd be wrong, but I feel like the CEO just decided to leave or something. I don't know. There's a story there, right? So clearly this was coming. There have been changes. They started going down the path of having their own cloud platform to run Slack apps, which I can't imagine anyone was actually asking for, but I'm not the product,

 

Good,

 

Well,

 

right?

 

the

 

you

 

chief

 

know...

 

product owner of Slack.

 

I wrote a Slack bot back in 2016 or so.

 

Yeah, I'm

 

So

 

sorry.

 

I was really excited when Salesforce bought Slack because I could suddenly put Salesforce integrator on my CV.

 

Yeah, yeah, wow.

 

Yeah.

 

Ha ha ha.

 

Oh, wow, well, you know,

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

I don't know that's a good thing. Like,

 

Yeah!

 

It's a double-edged

 

there are,

 

sword over here.

 

yeah, I mean, it depends. You know, the recommendation I give to a lot of inexperienced engineers is, you know, make the resume for the job you're applying to. So, you know, I can imagine that could be valuable some other places, but if I saw that on one of my engineers,

 

Ha ha ha!

 

I would certainly have to question what they thought their job was gonna be when I

 

Ha

 

hired

 

ha!

 

them.

 

I think that's a really interesting parallel though, just talking about Slack and the way that they've evolved over the years to open source, because you see this, at least from my perspective, I work with a lot of startups. I see this a lot where a startup starts off, they've identified their target market, they have their niche, and they focus on that, and then they start adding stuff on top of it, and adding stuff on top of it, and there's like this. There's this philosophy that you have to keep adding stuff on top of it and building new features. whether your customers are asking for those features or not. And then five or 10 years down the road, you've got this thing that no longer does the thing that made you successful. And then you go through this rebranding marketing exercise and try to figure out what went wrong. And nobody ever comes to the conclusion of, oh, well, we stopped doing the thing that our customers really liked. Or the thing that our customers really liked is now buried six screens down. And I think that's similar with open source applications or open source libraries as well, where they start off doing one more thing, one thing well, and they gain adoption in that. And then you get this what if game. Well, here's a pull request that what if we did this and what if we did that? And over time, it evolved to where it's now not this library that you used it for, but it's this whole suite of libraries that. does the one thing that you wanted and like 15 other things that you could care less about.

 

You know,

 

I find that,

 

I- I- Sorry, go ahead.

 

I was just going to say from somebody who, I write and maintain a lot of open source software and that's actually something I personally struggle with because a lot of the reason why I'm in open source software is because I feel like it's the most ethical and democratic and it's the way of creating the most opportunities for the most people even outside of the technical problems. I think open source software is probably one of the closest things to a meritocracy. was available, at least in the job market, was incredibly helpful to me. So when people make pull requests or feature requests, my initial response is always like, oh, yeah, that would be great. Of course I want to do that. And then I found, especially in some of the projects that I'm on, maybe they're just not as widely used, or maybe that's just a completely different direction, I think, than anybody else wants. And it's like, well, Can I really spend all this time and build it and maintain it and this and that? So I've got to, I don't know. That's just my little perspective over

 

Well,

 

here.

 

I think what you're saying actually is you're the chief product manager for that open source repository. And I think I'm doing the same thing for what we've got. Like often we'll get someone that comes to the pull request. I think it happened today actually introduced a new feature was like, hey, this doesn't support this new thing that just came up. I'm like, I looked at it. It was like one line code change. And I'm like, does that really work? And then I like tried it out and it worked. I'm like, wow, that's fantastic.

 

Hehehe

 

And I merged it in.

 

Yeah

 

And I decided that that was part of the direction, though, that the library was going, that it needed that feature. And I can imagine there aren't that many great cheap product managers out there. Can you imagine every single open source engineer? Wait, should I be pulling this feature in? Should we be doing this? Is probably not the most common question they're asking themselves. So you can definitely get in that sort of, but... It is what it is.

 

I've seen so many libraries that just look like every pull request is accepted. Maybe debug it or something, but like, oh yeah, let's add 16 new methods to this class because you might want it with capital or lowercase or mixed case or camel case, whatever. Every possible combination of everything, just throw it in there and make it work.

 

Yeah. Well, I mean, there is something to be said about libraries that make it easier for user experience, like the LN, you know, which direction do the parameters go, right? And I think some of the libraries you'll see, they like they try to guess the number of parameters and then like, which parameters did they enter? And they do this. And there are some that great, you know, they try to make it, you know, that adds overhead, definitely. And

 

Yeah.

 

expanding the bloat, like you could have a regular library and then like the wrapper library, which like correct some of those issues. What you said, well, really brought up to my mind. There was a book by Stephen Lin. who's a Wall Street investor called, I think, one up on Wall Street in like 1980s or something. And it was revolutionary. He used this word frequently that I stole from there, diversification. So you take

 

Hahaha

 

something and rather than diversifying and getting the benefit of that, it's like you had a core competency, a core idea, something to really go after. And then you started adding these other things on for whatever reason. You probably wanted more money. It's usually the driving

 

Mm-hmm.

 

factor, at least in investments.

 

Yeah.

 

I think it happens here too, right? You know, what is your business doing? When I do hear some of my peers say, oh, we know we're expanding our engineering department by a factor of two in the coming years. And I'm like, what mistake are you making? Like, I...

 

All

 

I... I...

 

right.

 

Yeah, you never

 

I...

 

want more engineers around like, oh, that's such a terrible fate.

 

Well, you know, I think it's the it's the mythical man month problem, right? Like you aren't going to go faster. So the only conclusion is you are you are trying to do twice as much like you're pulling on a new product that you have already tested. You've already vetted and you're like, we're going to do this with our business and now we're going to have two businesses that are running on wonder under one umbrella. And I think that can work to some scale. I think there's a mistake, especially with the race to become the next unicorn that you have to be scaling up as fast as possible. It's not something that we do. after investor money and fundamentally, it just doesn't make sense because like, we don't need more engineers to accomplish what we've got a good deal on. And I mean, obviously the right number is important and not going further than that. Like whatever it is, like we have our mission, whatever our vision is we're going for it and how big it is. And it's not size, like size is not an end goal. Like I want to be the CTO of a hundred. thousand person company? No, I don't. That's not where I'm going. And what do you do when you get there? Right? That's you get to go to sleep at night and be like, did I accomplish what I what I set out to do? I love the managers that are like, I, I did my services supported $10 million per per year transactions. And I ran a 200 person engineering department and I'm like, Okay, but you failed my behavioral interview. So

 

Hehehe

 

But I had some really innovative agile meetings.

 

Ha ha ha!

 

Yeah.

 

That's always the story.

 

Vasco Duarte, who's famous for his No Estimates book, likes to say on LinkedIn every now and again, you know, the reason you scale is not to add engineers, it's to do more work with fewer engineers. And

 

Mm.

 

I like that, you

 

That's good wisdom.

 

know, and yeah. The whole industry we're in is about automation, which is about

 

Mmm.

 

less human labor. So why

 

Yep.

 

do we get excited when we add more human labor to the equation, you know? I don't get it.

 

That's why it's the best feeling, by the way, like when you can just get rid of a whole bunch of code. Like, ah, I love that. I had an upgrade like that a couple of weeks ago. It

 

I thought you were going

 

was,

 

Yeah.

 

to say when he get rid of a bunch of people.

 

I

 

I

 

mean,

 

was like, oh no, don't say it, Jillian.

 

like, no, see, this is why I won't hire people anymore, by the way, is I'm just like, no, like, I don't have like the peopling skills for this kind of thing.

 

Yeah.

 

Like, no, no, no, no, no, no. But you know what? I think that's kind of an interesting, Warren, what you brought up with like the companies and the growth and these companies that take the VC funding and they're expected to grow by these ridiculous factors. And it's just, it's always like, oh, let's, it's like a train wreck that you can't look away from, right? Because

 

Well,

 

what

 

it

 

other

 

is.

 

industry expects that?

 

Well, I mean, I think it could be a lot of them. It's not necessarily an industry-specific thing. I think it's correlated with the software industry or the hard engineering or soft

 

Yeah,

 

engineering.

 

it could be I'm just paying more attention to the tech industry,

 

Well,

 

right? Then

 

I

 

I

 

mean,

 

think it's

 

there

 

a confirmation

 

could be.

 

bias.

 

It could, it could definitely could be, but you don't need to scale up like a manufacturing physical location to increase where you're going there. And if you look at it, of course there's like, what is VC funding, right? It's this train that left the station and VC funding just increases the velocity. So fail fast or successful. So that train is either going to crash or it's going to be successful and all you're going to do is make that happen faster. So there is some merit there is like if you want to start that train, leaving the station and go after it, like it can be a thing you go after. And there's a very cut and dry, this is the approach you take, you go around seeds of funding, you convince more and more people to invest in your business until you get to the point where it does become successful and the founders crash out. Sorry, I said successful. What

 

Hahaha

 

I mean is the investors are able to take their money out because that's what success

 

Right?

 

is. It's not...

 

Yeah.

 

I mean, IPO-ing doesn't mean you were successful. It means that the VC and visual investors were successful. But anyone who's still there, like, you know, it might as well be called whatever sort of not

 

But

 

appropriate

 

what if they pay

 

situation.

 

me to leave? I mean, that still might be a success from my point of view.

 

I think you touch on an interesting point and that is that everybody defines success differently. And that's why you would have these things, where some people are trying to have a team with the least number of engineers and others want to hire a thousand people because their version of success, maybe not their company's version, but their version of success has them managing a thousand people. And maybe that's legitimate in some sense, maybe that's the next step on the ladder they're trying to climb. Or maybe it's just ego. boosting, but whatever it is, for some reason they've defined success as managing tons of people.

 

It may not be even them, right? Like, I feel like if you're in the BC area, you're taking that insight from your investors potentially, and they're the ones telling you that you need to scale and that's what success is for you. So you're going to maybe take them at their word because you don't have sufficient experience. Otherwise, I don't know, you would have known better in the first place.

 

Right.

 

And go after it. And it is in some way, right? Like the founders are keeping some share and if it does IPO, they're just as successful, right? They do get an exit potentially. and the founders are there, but you know, I think, Jillian asked the important question, you know, what are we doing to society? Is this even the right approach for us to, you know, have companies like this? And I think I read a paper recently about like, why billionaires are always wrong or something like that, or shouldn't exist, I think is what it said.

 

All right, what's next? if we tackled it all. We can edit

 

They're...

 

this part out.

 

Yeah, we

 

We

 

did

 

can

 

money, we

 

gather

 

did security.

 

our thoughts.

 

Money is a good one actually. There is the cost of managing the software, which I think we talked a little bit about, but I see some of the competitors in our space, the authentication, authorization, whatever, that. they're using libraries or they get tons of funding to be able to support their library management, their open source strategy of getting external engineers in and getting customers that way. And then they sort of maybe lie about why those customers came and used their stuff, right? Like, Oh, they're using our open sourcing. That means they're using our actual product. And I don't think they would have been successful if, if you just look at the actual product, like it's just not there. So it's like, you know, how do you even compete with a company that's getting VC money? their product is terrible, they're going through the steps of getting bigger and bigger only to cause the weight to crush their actual customers who they never really designed for. I think, you know, open source also has that problem, right? The security is an aspect we talk about. Scale is another one, right? A lot of libraries are not designed to scale, right? Like, they're there to solve a very specific problem, which concurrency, those engineers haven't heard of that before, or data multiple levels down. It's not designed to be resilient, right? Like our software, 5.9, like that's our SLA. I mean, we go, we contract out for more than that. But realistically, what open source library is sitting out there is like, this is a 5.9 open source library. Like if you install this, it will never have a bug ever. Like they're not promising that. Definitely not.

 

Right.

 

That's one of the really interesting aspects of data science or software that comes out of the data science space.

 

Sì.

 

Most of it is not written by software engineers. It's written by scientists, by their data scientists, who learn just enough code to be dangerous

 

Yeah.

 

and need to solve some kind of very specialized problem that they understand and that the engineers don't. And so they get forced into doing this code that they didn't want to do in the first place, by the way. They were like... Why do I have to do this? And they do this, and then you end up with the software that everybody relies on and isn't, you know, I don't know, it just ends up having maybe some strange conventions or they don't know what a load balancer is and they try to code it themselves. I see that one a lot, or they create their own system of threads instead of just using a threading library. There's a lot of just weird little things that happen because... It's not written by software engineers. But it solves a problem. So that's the thing. Like it's solved, that people use it because it solves the problem that it needs to be solved. So

 

Oh,

 

interesting

 

there's definitely,

 

people problems.

 

there's definitely a, you know, how much will this software be used going forward? Like there's a difference when I'm doing the advent of code, which is up right now. And that should never, that coach never see the light of day anywhere and stuff that goes into production, which. has everything, every bell and whistle there should be. You know, you bring up the data science thing, and one of the things that came to mind a while ago was the code you write, is it a reflection of like how you think and who you are? What sort of aspects are important to you, aesthetic quality or whatnot? And just how you think about your own space, like do data scientists, can they not actually write code? Well, maybe they can, but they think about it differently. So the code they write may be inconsistent with code that a software engineer would write. I mean, obviously the business director is different, right? The reliability of that has to be different. But frequently problems I would hear in some of my former experiences were, this takes eight hours to run or 24 hours to run. And I'm like, there are some simple solutions here. that it will still take the exact same time. But instead of it crashing randomly once every seven days, like when it does crash, it can just pick up in the middle and resume. And that's like a head exploding moment. It's like, wow,

 

Hey, hey,

 

you can do

 

stop,

 

that.

 

stop coding me out of business here, okay? Like, listen.

 

We'll have to edit that part of the episode

 

Yeah,

 

out.

 

that's right.

 

That's a...

 

That's right. Don't be giving out the secret sauce over here.

 

I'm removing it. Yeah, I don't know that you know, that's me all day long I get I you know, I have people listening to me and be like wow Warren You should write that down. I'll be like yes and everything else my content backlog is really long I haven't gotten through it all yet the next time I have some time I'll write something up But I start little wikis on on github or obsidian or whatnot and try to share them and it's just the list goes on and on It's just like, is anyone actually gonna read this? Try it. Medium blog posts on these different things like Warren Rantz. I don't think anyone actually wants to read that though.

 

Yeah

 

You never know who's that the kind of like, it got famous for a minute blog on programming. It was, what was it? It was like, like programming sucks, keep drinking. Or it was something like that. And

 

Yeah

 

I just remember that, that making the round. And it was basically just like rants about software engineering. So you never know. You never know what's, what's going to hit with the people.

 

That's definitely a good point. I get followers like every couple of weeks. They're just like, I don't know who this person is or what they found that was so enlightening here,

 

Hehehe

 

bookmarking that or coming back to it later. I'm like, I'm glad there are people out there that are finding my stuff and be like, wow, that's really insightful. There's a bunch of other communities that I'm a part of that I see people questioning the same thing or running into the same engineering or management problem. And that sort of triggers me to rethink over all of my thoughts, go back, like, what do I think about this actually? And then get triggered. to write something down. And now I have this article and the next time someone complains like, I don't understand why, you know, fill in the blank. I'd be like, you know what? Actually, I have this article I wrote just for this exact purpose. Let me share that with you. And maybe that gives you some insight. I start with the... Sometimes I get triggered, right? That's always the best. You know, someone says something that's just like, wow, some other company is doing this thing. And you just start writing stuff down. Eventually, you're like, you know, this could be a blog post and have to spend then a ton of time fixing it up. So it's appropriate for the public before releasing it.

 

That's what a lot of my documentation is. Like I'm triggered about something and I'm like, listen, when you encounter this, don't do this thing that you're thinking of doing, do this other thing. And it's kind of like obvious that, no, maybe I should have like gone for a walk or

 

Yeah

 

had some tea. You know, gone for like a more chill solution.

 

Wow,

 

It's like

 

I feel

 

a

 

like that

 

Snickers

 

happens. Ha ha

 

commercial.

 

ha.

 

Ha ha ha!

 

Wow, yeah, no, definitely. I feel like it happens every single time I review some code that I get in the mode, like, wow, you know, there's like some fundamental rule here that like I have taken into my existence because I don't know, I read the Gang of Four, you know, design patterns, or I was burned by it probably in my past, right? There was some enterprise software I was working with that did something that was just atrocious in some way. And I never wanted to do it again. Like I found, I never thought it would happen, but a bunch of years ago, I was working on a monolith solution company and there was some re-entrant code. Like there was code that called a bunch of other functions which called itself again and wow like it wasn't intentionally recursive. It just like it happened to do this and it never got fixed. Like the five years I had seen it then I left I still was running there that code. I'm like this can't work correctly like no one can actually undo that. Like you need to go in be like okay what is this actually supposed to do and dive in and then try to fix it. That's not a fun experience.

 

On a slightly tangential topic, like every software engineer I know has like real specific triggers, like real, real like niche and specific, specific triggers that they will, they will tell you about in

 

Don't say triggers,

 

case you want some.

 

I can't stand that word.

 

Hahaha!

 

I mean, I think we can say that there may be, and I don't know if this is true, maybe there's a correlation between those that are in the software engineering or adjacent space and those sort of people that have like autism spectrum disorder. And so I can imagine, you know, myself included, when I see something like that, it's like, that's totally wrong. I can't believe you would ever write something like that and force me to look at it. And it's there. And then someone else, you know, it comes up to me and be like, wow, like, I really hate, I'm changing all these things because I hate all of them. And I'm like, take a moment, you know, take a deep

 

Right.

 

breath. I know it's important to you,

 

Listen,

 

but I want

 

it's

 

you

 

very

 

to see...

 

justified when it's me. It's

 

Oh,

 

less

 

yeah.

 

justified when it's

 

Oh,

 

you.

 

yeah. Oh, definitely. But, you know, I think the advice, especially for inexperienced engineers, was always... You should see the difference between it being valuable for the company and valuable because you want to do it. Like you should trust your intuition because it's valuable, right? It's telling you something. It may not, other people just may not see it the same way. And so figuring out how to sell that intuition as valuable was a huge thing that at least helped me a lot in my past because I definitely got... I try to think of a different word so I don't get

 

So you

 

Jonathan

 

don't trigger

 

yelling.

 

Jonathan?

 

Heheheheheheh!

 

Well you should

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

use the same word so you know that's a sort

 

I

 

of

 

know,

 

self-enforcing

 

I couldn't help

 

prophecy

 

it.

 

there.

 

Well that's okay. Actually, that word is fine now. It's a different one. You'll know when you say it.

 

Oh, it's temporary. So like,

 

Yeah.

 

it's the word

 

Alright.

 

of the day that you're not allowed to say. You're talking about like the challenge of some of these libraries. We were recently because of the press of pass keys everywhere, which if everyone doesn't know, it's sort of like this system for integrating the FIDO2 standard U2F, like via UB keys or anything like that, across the different devices or sharing them or using them for, sharing them and using them for login. And we were implementing it as part of our solution, providing some way for providers, for service providers, so your whatever app that you're building, platform can support pass keys to log in. And we're like trying to figure out the libraries, like, okay, we're not the first people to do this. We know that Apple has an implementation, that there's some other ones out there. There's actually a whole list. And this should be easy. And we're like going through open source libraries. Okay, it's using a standard format. It's called CBOAR, which compresses the data. Great, there's a library for that. It's outdated five years, 10 years ago, like still hasn't been updated. So the data format, while it's standardized, there's RFC for it and there's libraries. Those libraries haven't been touched in forever. Not necessarily a bad pattern. Although there's a lot of, like what the actual data is, is important. So the format, you don't want just that library, you need to extract that in some way. And so we found a bunch of U2F libraries, which didn't work, right? Like three or four of those, just totally dead. At least you can go on GitHub or GitLab and see the issues and someone will be like, this doesn't work, is this maintained? And that's your indicator to

 

Right.

 

run very far away. And then we found a bunch of other ones by our competitors that had open-sourced things that weren't actual libraries, they're just wrappers on their APIs. So it sort of faked it. And like with the WebAuthn stuff, you need a client-side library. You can't live without that, and you need a service-side library. Something open-source

 

Thanks for

 

that

 

watching!

 

just wraps an API isn't going to be sufficient. And so we pulled three or four things together, wrote a bunch of validations, and threw in our service. And my CEO's like, that thing right there, go release that. That's advertisement as part of our thing. And it's like, it's not ready, right? You know, we're still getting users on board on that and seeing if it works out. And then maybe in a few months from now, it will be there. But until that point, there'll be no shortage of usage of these old libraries and pain and suffering by the engineers that are told to implement this standard and run in the same hole that we do, but because it's not their core competency, they don't have the motivation to push through that. challenge really of the open source world.

 

That's cool though. I'm so glad you guys are like, you know, like, okay, we built this and it's useful because of this, this, and this reason. Let's open source it. That used to be like a way harder sell, I think

 

Yeah.

 

than it is now. So if nothing else, you know, I think the open source community has come a very long way and just, I don't know if we've just like kind of beaten people in a submission, like, yeah, too bad. It's going to be open sourced

 

Oh,

 

or

 

definitely.

 

if they believe in the open source, but whichever way it is, I'm happy that, you know,

 

I

 

so

 

think

 

much

 

that's

 

software

 

part of

 

is

 

it.

 

open source these days.

 

I also think there's a change in mindset. You used to think software was special.

 

Mmm.

 

Yeah, we don't think that anymore, do we?

 

And now we realize that what's special, especially for a SaaS, isn't the software per se. It's the management of the software, which is, I think, a big part of the point that Warren's making tonight. I say tonight. It's night as I record this, probably not for anybody else and probably not as you're listening, but it's night as I record this.

 

It's 7.44 for me, so I'll

 

OK,

 

call that

 

OK,

 

night.

 

great.

 

Yeah. No, definitely. I think I don't understand the management, but like there you have these interconnected pieces that how you align them together and then deliver them as a unified package, the organization of that just like you're not you're not connected together the silicon based transistors to build a computer to deliver your software, you know, you took some computer components and put them together. And that became a thing that you're selling the value on sort of the value added tax nature and European Union sort of thing, right? It's that connection that that is offering the value, the finding of those

 

Yeah.

 

open source libraries and pulling them together is the product. Yeah, definitely.

 

Well, we have been talking for about an hour. It's probably time to start to wrap up. Are there any last points that we should discuss before we move on to picks?

 

You know, the thing that I think was on everyone's mind like right now is the chat GPT, and I feel

 

Yes.

 

like we would be a mess if we didn't say a couple words about that.

 

Yeah, so for the record, the intro I gave at the beginning of this program, those weren't my words. That was completely chat GPT. So you can either credit or blame the chat bot for that. But what do you want to say about it, Warren? What are your thoughts?

 

You know... I think the current sentiment is something like, oh, fear for finally software engineers will lose their jobs. But I, for one, am really, I don't say ecstatic. It's quite surprising how far it's come since the last iteration of what we've had, which was GPT-3, which is the content generation, automatic content generation. And so obviously it's doing some of that. But it's pulling in a lot of things that you just wouldn't be, wouldn't expect it to do, questions or sort of continue the conversation like internal state. I think that's come a long way actually to the point where you could I could actually see like as you pointed out for this program generating those sorts of things for real. I'm using them.

 

I think the people who need to fear for their jobs the most from chat GPT are middle managers who never say anything. It's really good at spitting out intelligent sounding nonsense in other words.

 

And it's good for them then, right? Now they have a tool that they can just enter it in, whatever their manager says, and they just have to repeat that. I think

 

There

 

this

 

you go.

 

is genius for them.

 

There you

 

I

 

go.

 

think actually it's worse. I think every innovation subjugates the either impoverished or lower classes in this way, that this is a tool that is going to be used by the most experienced, most well-funded individuals and organizations out there to become more advanced, whereas the ones that to this technological resource will get further behind.

 

Yeah, that's true. I agree.

 

Yeah, that's what worries me about like all the AI stuff. I mean, I guess I guess it's only like semi related. But when during the pandemic, when like a lot of the stores were like, well, we're just going to start to have completely automated, like robotic checkouts like Walmart and stuff. And if you really go and look at that, like Walmart, there are places where Walmart is the major employer of like entire towns. You know, like maybe if you're if you're from like a city or something, you may not realize this, but you go out to, you know, like the Midwest of the you know, are places that are less populated, maybe don't have like, you know, a lot of hospitals or tech centers or something like that. Some of these stores like are, you know, the major, the major employer, you know, like when factories left, it's the same kind of idea. And how are we all going to deal with that? I don't know. I don't know. I don't have any answers. I'm going to buy some land and pitch a tent. And that's, that's my plan.

 

I see this dystopia incoming. Technology is both accelerating good, positive, as the Earth is getting destroyed, just asymptotic divergence here. So we'll end up with that perfect god machine, right? At the same time, humanity is over.

 

I think that's the basis of a couple movies.

 

I would be remiss to end a conversation about AIs replacing developers without talking about Star Trek.

 

Which episode?

 

Elementary Dear Data, the episode where Jordy

 

With the

 

tells

 

Android

 

the computer

 

phone.

 

to create a holodeck character capable of defeating data. And

 

Oh

 

Ah,

 

yeah.

 

with Morty Artie.

 

exactly.

 

Hmm.

 

This just goes to show, of course, Star Trek is real, so we know that this is a real life

 

Yeah.

 

lesson to be learned, right?

 

Naturally.

 

This goes to show that even when you have really smart AI that can do programming for you, it still depends on good input, and you still have to give it good instructions. And someone is going to be... paid to give it those instructions.

 

I think, I think the, I always, you know, each of those things in the episodes, I was like, I, should I challenge like, was that a good ending for an AI? Would it have gotten stuck in a bottle? I don't, I don't know, right? Is that, is that the, the end that we, we hope for sentient beings to be convinced that they live in their own world, simulated reality?

 

question.

 

Yeah, and I think that just kind of sums up my thoughts on the whole chat GPT thing. And I don't get paid to write code. You know, I get paid to solve problems.

 

Bingo.

 

And when you shift your perspective like that, there's always going to be problems. Maybe I don't write code to solve those problems. There'll probably be a lot of people happy about that, myself included.

 

I was going to say, my clients, like if they could have a solution where nobody was writing code, they would prefer that. Like,

 

Yeah.

 

are

 

I love

 

we not

 

what

 

under?

 

Daniel North says about that. He calls software is like surgery. When you need it,

 

Yeah

 

you need it, but you want the minimum amount

 

That's

 

possible.

 

good.

 

Yeah.

 

Wow, I've been using a

 

And

 

garden

 

heavy drugs.

 

analogy.

 

Wow. Ha ha ha.

 

I mean, I think people have to become experts in whatever the tools are that they have available to them, right?

 

Yeah.

 

The bot just being one of them, right? And I think, you know, somewhere in my mind, there's this lie I'm telling myself where like, no, I'm still better than the AI,

 

Hahaha

 

right? Gotta forget about that, right? Have to find new skills. I think Randall Monroe has the next KCD here on like what? AI hasn't beaten us and like on one side it's like tic-tac-toe and I think on the other side humans still winning is like seven minutes in heaven.

 

Yeah

 

Let's take it to pics. Who wants to go first? Will,

 

All

 

you

 

right,

 

joined us late. Do you have a pick?

 

I do. Actually, I have a seasonally relevant pick because by the time this drops, we're going to be close to the Christmas season. So my pick is holiday-oriented. One of the things that's great for the holidays is everyone getting into the holiday spirit. Everyone's a little more cheerful and nicer to each other. And I think a big part of that is watching holiday-themed movies. So my pick, I referenced it a couple weeks ago and then forgot to pick it. but I'm back with it now. My pick is the go-to holiday movie of the season. It has William Shatner in it. It's got some kid that looks like the kid from Home Alone. And it's got an epic battle of Santa battling Krampus. It is the Christmas horror movie. So it's got

 

Is that the

 

everything

 

title?

 

that you, that's the title, a Christmas horror movie. I think now that you say that, I'm second guessing it.

 

Hehehehehehehehehehe

 

I should probably

 

A Christmas

 

know what

 

horror

 

movie.

 

story, I think.

 

A Christmas Horror Story, that's it. But yeah, it's got everything that you want in a holiday movie. So that's my pick.

 

How do you know what I want in a holiday movie, Will?

 

because it has something for everyone. It's got

 

Oh.

 

romance, action, adventure, blood, gore, candy, holiday lights, Christmas carols.

 

Candy, you got me a candy, that's what I want in a movie.

 

There we go.

 

I do not do any horror movies in the slightest. Like I just, nope,

 

But it's Christmas,

 

nope, I'm going

 

Jillian.

 

for the Muppets Christmas. No, I want the Muppets

 

But

 

Christmas

 

it's Christmas.

 

Carol, okay?

 

It's a Christmas

 

I

 

movie.

 

want the Muppets Christmas Carol and cookies and Legos and like, I don't want none of this gory nonsense. So we'll

 

Will

 

just

 

I get

 

have

 

in

 

to

 

trouble

 

agree

 

if

 

to

 

I

 

disagree.

 

make my wife watch this with me? She hates horror movies too, she's like

 

I'm gonna

 

Jillian.

 

say yes. You know what, I'm gonna answer for her and that answer is gonna be yes because every once in a while, my husband tries to get me to watch like some kind of thriller

 

I think

 

or something

 

I'm just going to tell her it's a William

 

and you

 

Shatner

 

know, and then I

 

Christmas

 

cry.

 

movie and

 

Yeah,

 

we'll go from there. She likes Star Trek,

 

No!

 

that's

 

so.

 

what I did.

 

You know what?

 

And

 

I'm gonna

 

if

 

vote

 

she doesn't

 

that's a bad

 

get the

 

idea.

 

joke, it's her fault for not listening to this episode ahead of time.

 

Right?

 

Do anybody's spouses actually listen to the show? Like, I know mine doesn't.

 

Alright Jillian, what's your pick?

 

So I'm gonna go for the shameless self-promotion, this pick. Damn it, I forgot what one of them was. I had two, but now. I know it. Like.

 

It was you, Jillian. It's a self promotion.

 

Oh, I know. Yeah, okay. So I have some work opening up pretty soon, and I've been really interested in kind of this evolution of companies that are trying to create like small, you know, small, very specialized apps and deploy them, scale them, get them out to their customer base, which is typically scientists because because that's what I do. So if you're running a company like that, and you just want somebody to, you know, bounce ideas off on. That's kind of what I'm looking for. You can go find me at dabbleofdevops.com. There's a link. Or I have a whole bunch of open source libraries at a project called Bioanalyze. Go get them while they're there. That's what I have to say about that pick. Since we've been talking about open source software and its maintainability, I'm just gonna throw that out there.

 

Yeah.

 

And then I guess my fun pick for the week is I have been reading the Wings of Fire. It's like a middle grade series with my oldest daughter and they... how at first it was like a novel and then they produced a bunch of like graphic novels that are basically the same story. They are so fun. I love the fact that like, there's so many graphic novels out there, especially for middle schoolers, because I just feel like that speaks to me both like mentally and emotionally is the middle school grade level, but they are really fun. So if you're kind of looking for stuff to read with your kids, I don't know. I like them. They're good. Wings of Fire, there's dragons, there's action, adventure. There's no horror well. And that's.

 

Is there candy?

 

I don't think so, no.

 

I'll

 

I don't

 

let

 

think

 

Is

 

it,

 

there's

 

there

 

but

 

any

 

I'm

 

Santa

 

out.

 

candy.

 

battling

 

I'm

 

Krampus?

 

out.

 

Nope. No,

 

See?

 

pretty sure there isn't. It's

 

See?

 

drag- but there's dragons battling other dragons, so what do you- like, what else do you even need?

 

Santa battling Krampus.

 

I don't know. She does make a strong point there, Will, about dragons and dragons. Alright Warren, do

 

I

 

you

 

think

 

want to

 

that's

 

go next

 

gonna have

 

or

 

to be

 

me?

 

a fight

 

I'm

 

for

 

fine.

 

another

 

Thank

 

Hahahaha

 

you.

 

show.

 

I can go. You know,

 

Alright.

 

I think my company is going to have some sort of PR piece dropped next to the beginning of next year about the whole authentication authorization space for B2B. I know our CEO has been working really hard on that. It's difficult to find good PR agents and know what to publish and content is hard, right, as you all know, during this podcast. But I actually think, you know, and I think we're looking for, you know, small and mid-size companies that are struggling with login, authentication, and complex permission things. be, maybe this has probably been said before, I love space, just anything there, and for the longest time I've hated the notion of dark matter because for anyone who doesn't know, dark matter is just this term that's assigned to, we think there's matter out there but we can't find it, so we're just going to call it dark matter, and it's always bothered me that that was the term, not like, oh we don't know. It was always, there's a term dark matter. And I think that got a lot of people confused. And with the successful release of the James Webb Space Telescope, which has been fantastic, I have a reminder every month to go on the website and download whatever pictures are available because these are stunning. full desktop photographs of huge quality. They're great, they're better than anything you could take anywhere else. So that's part A. And part B is, I think it's been enough to almost justify what the matter is and where it's out there that should be coming to conclusion soon. So I am really looking forward to getting rid of the term dark matter or replacing it with whatever we discover really is.

 

I hate

 

い

 

the term dark matter too. And my prediction has been, and I'm not an astrophysicist, so my prediction means nothing, but my prediction has always been, we're gonna discover some fundamental law of gravity or something that's gonna be like, oh, there's no dark matter. It's this other thing, completely unrelated. But whatever it is, I'll be glad when they stop calling it dark matter too.

 

you prefer to go back to the the ether right that that's the term that you want

 

Oh

 

stuff. I think they could just call it stuff and it

 

WONDER!

 

would be like just a script, right?

 

I mean,

 

Like...

 

they actually, so there was proof that was done, that proved that there is nothing in space that we aren't seeing. So if there were, we would be able to detect a slight deviation in the photon wave patterns on the incident interference when they come back. So there's actually a whole experiment done that proves that there is nothing in the absence. So like, where is it basically? The other conclusion is that the Big Bang never happened There is some other explanation for what's going on and the universe isn't really 13.8 billion years old or however scientists decided to calculate this relative time in an absolute way, which also makes no sense. So I'm hoping those scientific quandaries get resolved and we don't end up with, oh yeah, we are in a simulation.

 

We are really just the result of a chat GPT-6 output

 

Virtual machine?

 

somewhere.

 

Yeah.

 

Yeah, exactly.

 

It's

 

You

 

the

 

know,

 

internal member.

 

I use the phrase dark money a lot. It was like whenever my bank says,

 

Oh.

 

dude, your account's overdrawn. I'm like, no, there's money there. It's just dark

 

Hehehehehehe

 

money. You just have to look harder

 

I could see

 

for

 

the utility

 

it.

 

in that. Yeah,

 

Yeah.

 

yeah. It's like my

 

transfer

 

Dart code

 

money

 

that

 

from

 

I wrote

 

some

 

last

 

of those

 

week

 

other

 

that

 

accounts,

 

fixes

 

it'll

 

the bugs.

 

all even out, it'll be fine.

 

Right?

 

I have two picks for the week. I already gave a hint to one of them. It's the book, A Seat at the Table, IT Leadership and the Age of Agility by Mike Schwartz. He writes it for CIOs, not per se CTOs, but it's more or less the same thing. I mean, basically, his viewpoint is for internal IT organizations, not those building products for other customers. But almost everything in the book is still applicable if you're a CTO or work in a product. facing IT company. Really good insight. He likes to talk about lean, agile, DevOps. And he gives some fresh views. Like he says some things that would piss off some Agilists, which I think is kind of a fresh view to not sort of tiptoe around the hardcore manifesto thumping Agilists out there. So it's a good book, a really good book. It's funny. I listened to the audio book. I think he narrated it himself and he does a good job. Or maybe he doesn't, I don't know. But whoever narrated it did a great job. So I highly recommend the book. It's a good book, especially if you're interested in tech leadership of some sort. If you wanna become a manager or CIO or CTO, I highly recommend the book. My second pick, I actually hinted at this too, is a podcast, the No Nonsense Agile Podcast. It's one of only two agile podcasts I regularly listen to actually. I used to listen to many others and I kinda just. started weeding out my list as they started repeating. And I got to hear the same old boring talk about how big your story points should be or whatever nonsense for the week, that just repeated nonsense. I feel like the Nonsense Agile podcast does a really good job of having fresh guests on and good topics. And of course I was their guest, which is why I have to pick it this time.

 

What?

 

So episode number 63 was me talking about continuous delivery, but they've had some really excellent guests, much better than myself, honestly. Simon Wardley. Dave Farley, Brian Finster, many, many others. So I highly recommend their podcast. I haven't heard an episode I didn't enjoy. So I highly recommend the No Nonsense Agile podcast. And

 

Right

 

that's

 

on.

 

my picks for the week. Any last words before we sign off, guys?

 

It reminded me of this book I just finished that was highly recommended called Formula Science of Success by Bharabasi, I believe. And there's some quite interesting conclusions there about who actually becomes successful and how that happens. So I think there's a lot to be said about the luck aspect,

 

Yes.

 

which is unfortunate.

 

Yeah. Great. Well, thank you for coming on, Warren. It's been a fun

 

Yeah.

 

conversation. A lot to talk about. A lot of good topics. So

 

I enjoyed it.

 

thanks for everyone for listening. We will see you next time on Adventures in DevOps.

 

Talk to you next week.

 

Bye, thanks for having me.