DOP 287: Automating Dependency Updates with Renovate
45:17 Share

People went from having no idea what risk they had to companies being able to tell them pretty accurately, you got a lot of risk. And then finally, when you had automation, then you were able to actually start reducing risk. This is DevOps Paradox, episode number 287, automating dependency updates with Renovate. Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darren and Victor, pretend we know what we're talking about.

Most of the time, we mask our ignorance by putting the word DevOps everywhere we can and mix it with random buzzwords like Kubernetes, serverless, CICD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often since they might make us look incompetent.

The truth is out there and there is no way we are going to find it. P.S. It's Darren reading this text and feeling embarrassed that Victor made me do it. Here are your hosts, Darren Pope and Victor Farsal. Victor, how often do you sit around and manually update the dependencies of all your products? I mean, you work in Go. To me, that is the most painful way to do dependencies.

as someone coming from Java, right? We're talking about not only Go dependencies, but in my case, we're talking about images, for example, right? There are Helm charts, there are customized, there's a bunch of Kubernetes things that is not even Go always, right? And to answer your question, how often do I update dependencies manually? 100% of the time. I 100% of the time approve pull requests manually that update my dependencies.

So you have a little bit of machinery going on to help you with your dependency management, or maybe a lot. So on today's show, we have Rhys Arkansan. Rhys works at Mend on Renovate. Rhys, how are you doing? Hey, very well. Thanks, Darren. Thanks for having me on. So does Victor's response surprise you at all?

I mean, he's using machinery. Should he be using machinery or should he just be doing it all by hand? I mean, it is 2024 after all. I mean, obviously I have some familiarity with Victor's setup, so I wanted to ask a clarifying question. So Victor, you said you manually approved pull requests, but are you implying that you have automated pull requests to get it halfway there or that you're creating the pull requests yourself? No, no, no. Pull requests are created by Renovate actually, but I manually approved them, right?

Mm-hmm. Yeah. It's almost like, I mean, basically the answer to is it automated in my case is yes, but I'm just messing with that. It's manual operation to approve it. Automated, but not fully automated, which is a very valid use case.

Actually, I had it set up to go directly to the mainline without any pull request or anything like that. And the reason why I switched to pull request is not that much because I don't trust my own automation. And when I say automation, I don't mean for the dependencies, but tests and all the other things that I require for something to be merged. But because I want to know when something is new so that I see whether...

I should improve something in my code. Maybe there are some new features. I want to know what's coming in a way. I think the key point is there's many different ways. There's no one size fits all. But I do have some kind of recommendations. So one recommendation is for people to be realistic. If you get automated pull requests, updating your dependencies, and you always click on them,

them. Like if realistically you're not going to go digging down into source code and release notes, you may as well kind of be honest with yourself and say, realistically, I may as well put that one on auto merge. Like if it's patch updates or whatever type of updates you find yourself using,

always just clicking, you may as well auto-approve those. Another use case where manually approving is, I'll say, undesirable for some people is where they have their own internal packages. So updating dependencies is not always external or third-party dependencies. It can sometimes be internal. You build base images and then you have this chain

Victor mentioned Helm charts, things like that. So yeah, especially in the DevOps world, you might have a Docker file that has dependencies that you update, that builds, gets pushed to a registry, that then goes downstream into Kubernetes manifests, you know, Helm charts, customized templates. So there might be times where once you've done the initial work, like updating a base image,

You might want that just to flow through without needing you to approve those. So those would be some cases where full automation is, well, in the case of internal, you could say that's reasonably safe. In the case of third-party patches, you might say, well, it's pragmatic. I want to go back to the way you set that up there. If you're not reviewing the upgrade notes or the patches, you should just auto-merge, i.e. YOLO, right? To me, that, I mean, yes, that's what we all do.

But should we be doing that? It's a good question. So one of the challenges is that a very high percent of updates, especially patch, but including most non-major updates, a very high percent

are fully compatible, non-breaking. In theory, in most of the ecosystems we talk about, especially Go, for example, it is quite rare for people to make a breaking change, accidental or otherwise, in a non-major release. And we see that reflected in the statistics.

But people are worried about that black swan event, whatever, that one that breaks things. Maybe it breaks your signup form and you lose a few hours of signups in a high volume app or something like that. One of the extra things that's part of Renovate and a free part of Renovate is what we call merge confidence. And so what we do is we observe at scale the possibilities.

passes and failures and the mergings of versions. So what Victor might be approving is a pull request that actually says this is a week old. It has 17% adoption and it's passed 98% of pipelines from Renovate users that we observe. That's a lot different from YOLO. That's kind of using essentially crowdsourced data to give what I call crowd confidence. When we

found a way to gather that data and expose it in that way, it was a pretty significant milestone because people went from maybe having a feeling of YOLO to then having a feeling of, like I said, pragmatic confidence. It's interesting that you said success rate of pipelines, right? I guess that for many people still simply don't have any validation of, automated validation of their source code or application, right? So it's

The way I interpret what you just said is kind of, hey, other people who know what they're doing, they validated this thing.

So maybe it's okay for you to do it as well. It's a little bit like that. Yeah, everyone's jumping off a cliff. Certainly, that's not the intention. But there's a few nuances to that. And one that we're pretty lucky about is that I would say dependency automation, user renovate, we're still in the early stages overall. There's still a lot of people who haven't even heard of this as a concept yet.

maybe a few hopefully listening here and might be interested after this podcast. So we're still in the early stages and one of the nice quirks that makes this work is that

The types of teams who adopt dependency automation and renovate into their projects are often the teams that do have good pipelines, quality tests, and they do continuous integration, continuous delivery. So we're kind of writing a little bit off the backs of those users who have the confidence of their tests, not just for automation, but continuously.

for when their developers push changes. Maybe even a developer manually changes a dependency. So we're fortunate to have a lot of those kind of early adopters, you know, high velocity, high quality teams. And I think that's what makes the data pretty accurate. And the other thing, it's not quite as simple. So as an example, we also have the ability to trace rollbacks.

So even if people updated, the rollback is like the number one sign, right? Negative sign, obviously. So it's not just a one-way kind of confidence. We also can know if people have regrets. So that's another aspect of it. But rollback can be for many reasons, two of them being I updated my dependency, put it into production, and it doesn't work as expected. I'm going back.

Exactly. That's the reason I'm talking about. Exactly. But rollback could be, at least from a statistical perspective, it could be, I updated my dependencies, I tested it up, it doesn't work as expected, it's not getting the production and rolling back.

But both of those are very strong negative signs that something about that update was off. And then what you'll see is that everyone else benefits from those early adopters and rollbackers, right? Because what it means is that we will not have a high confidence in that update. Essentially, anybody else considering that update will then know to have some caution or at the very least, you know, hey, don't go jumping off that cliff, you know, just because we said so. We're in fact saying caution, you know, at the top of the cliff.

So why would then somebody update the penises early? Judging by that, it would be in everybody's interest. Hey, wait for a month until other people validated this thing and be a late adopter. And...

I mean, I know that the month is not late, Adopter. People tend to wait for years. Yeah, exactly. Yeah, I mean, I'd say it's like the classic kind of curves, right? You've got the very early Adopter, the early majority, the late majority. Yeah, you're right. I mean, in a way, the people who do choose to do that are blazing the trail for the rest of us. Personally, I choose to, it's almost like a radio delay button. I choose to have a seven-day delay. So I wait for an update to be seven days old.

and then raise them. And then they often, we do have auto-merge setting a lot. There are people though, who are happy to have their projects always up to date and maybe unintentionally, they do a great service for everybody else who either, you know, waits, waits a week, waits a month. What's the origin story of Renovate?

Why was it a problem that needed to be solved? So the first declaration was there was some prior art in the area of dependency automation, obviously very early stage, fairly low adoption. I was working on a startup of my own and we had a problem in production. We were having errors reported by our sentry monitoring to do with our authentication, very obscure, strange errors. And we really didn't

racked our brains for close to a week trying to work out what was going on. And then eventually a developer was working for me, identified it. He said, oh, a week ago, he said, I upgraded the Firebase SDK because they had a new feature we needed. Turns out they broke something accidentally in that release. And the sad thing is they patched it almost immediately. We just got unlucky. We upgraded right at the wrong time when it was essentially a broken latest release and

And because we had no process in place for updating, you know, we just updated ad hoc. Like I said, we needed a feature for that particular one. In that case, we got caught and we spent, you know, if you think of time and money and user impact, that was really bad. And I, at that point, basically said, okay, never again.

Fortunately for me, unfortunately for the others, the two tools I was aware of at the time didn't support monorepos and they didn't support logfiles. So I essentially wrote a script to automate it just for NPM, just for GitHub.com.

I open sourced it partly as a search engine strategy. I used to name my open source after, well, I was building a real estate site, I should add. So I'd name my open source after real estate terms like condo and renovate. I would share them to tech blogs and newsletters to get backlinks to my tech blog. And when Google sees backlinks that say condo,

condo and renovate instead of dependency updater and software, it kind of tricks it a little bit into boosting your main content. So I did that unlike the one before that, which was called condo renovate actually got some people really interested and people popped up in the repo, you know, finding bugs, asking for features. And I felt a little bit of a thrill and guilt.

combination then I'm like, okay, well, I can't be insincere about this. So fixed bugs, you know, someone wanted GitLab added and did a bit of work to research it and added GitLab. And essentially, just it just took off from there. I eventually actually like pivoted my startup away from from real estate tech to, to renovate. And that's how it came to be.

That's usually how the startup wins happen. It's not the first project or product. It is the second or third. Yeah. And scratching an itch. Even like Slack, for example, wasn't Slack like an internal communication tool when they were building something else? And then they get absorbed by a behemoth named Salesforce. Yeah. That's not why we're here today. Boy, but that would be nice.

It sounds like the process with her is you scratched your own itch. You fixed your problem for yourself. People started enjoying it. Yeah. And then all of a sudden,

Renovate gets acquired, quote unquote acquired? Kind of, yeah. So I just, I found it really thrilling to have developers using it. I had literally been building real estate tech. You know, you do things like you're looking at heat maps and you're doing user session reviews and, you know, the classic kind of creative product manager, you're watching people click in the wrong spot and saying, no, no, why are you doing that? You know, and you adjust things and

make things more obviously clickable, things like that. And then suddenly it was almost like a voyeur, right? You know, you don't know who these people are really. And then suddenly those people like in your face saying, hi, I'm using it. This is really great. It'd be even greater if you did this or something like that. And I really liked that thrill. That was what kicked me off. The turning point was that someone popped up at one point and said,

And I think it was actually someone who needed, you know, monorepo or lock files or something as well. Right. And he said, this is absolutely perfect, but I don't want to run my own software. I'm small. I like to run, have services. And he said, I would like pay you.

If you ran it as a service, even though it's for free, it's open source. And that was like actually a real turning point. And I started thinking about it and I realized that, yeah, I mean, a lot of people don't want to be running their own pipelines and things like that. And, you know, running Renovate as a service would be like a viable business, hopefully. So I then not pivoted really, but just converted it into a, you know, open source first, but hosted service second service.

There came a point, maybe after a year and a half, where suddenly this topic got really popular. It was quite surreal when I was in the audience at a GitHub event where they announced their acquisition of Dependabot, which had had a bit of a

an idea about before that but to see you know the CEO of GitHub and and things like that talking about how important dependency automation was yeah I realized it was going to be like a big space and at that time I wasn't my interest to like take large risk take funding risk other people's money or anything like that I'd already been working with the team at Mend a bit they'd been interested in the software so we worked out that you know Mend had that

had the size I was interested in and the joint interests that it would be better for me to join them than try to go it alone in a pretty contested space. I'm always curious about open source projects when they grow. If they're successful, they grow, right? And require more time, effort. How likely would it be for Renovate to exist without funding kind of based on completely...

contributions, let's say, right? It's a good question because like my own personal financial motivations to turn it into software as a service actually came quite later in it. It already was building up in use before that. So, you know, it did kind of exist as a moderately popular open source tool before there was any, you know, incentive there. I'd say it's definitely possible. It's challenging. You know, there's a lot of right place, right time. In fact, you know,

you know, when I was considering whether to turn it into or attempt to turn it into a business,

I mean, half my doubts were like, but if this is such a good idea, why is no one doing it already? Like, you know, I had to really go through all of the, you know, why, why is everyone missing this? This seems so obvious that this should be just like continuous integration, say, you know, that type of automation, this should just be part of software. Why is no one doing it? Hard to judge, but I do think so. I think projects like Renovate can exist, but we wouldn't be as successful if we didn't have the ability for people to work on it, you know, on a salary too at times.

So was then Dependabot almost like a validation that this is something? Yeah, yeah. It's a funny feeling because I did not know about Dependabot when I started Renovate. I mean, I literally scratched an itch. So first of all, yeah, I just wrote a script almost. When I decided even to commercialize it, I didn't know about Dependabot.

And by the time I discovered them, which is actually when their founder reached out to me saying hi, I kind of thought to myself, I don't think I would have gone down this path if I knew there was someone else like competent and talented with the same vision. You know, like I didn't set out to compete. I set out to build something that was needed. And then I continued because it seems like there was an open space. So it was validation that...

that I wasn't crazy or going down the wrong path if others thought it was great. And then the GitHub acquisition of Dependabot was obviously like the full validation of this as an important concept in software. I'm going to go back to the reason why you created it. I'm assuming you had tried the competition.

No, no. So at the point I created, and by the way, I think Dependabot probably didn't even support JavaScript at that point. They started out in the Ruby space. I had used one of the two existing services. They were both services, not open source previously, but I'd had to drop them when

And, you know, I realized that monorepo, well, I adopted monorepos, but also when I use lock files and, you know, a service that updates, if it updates like your package JSON without your lock file, it's actually like broken. So I couldn't use them. So in the end, it was like I had no choice. So I understand lock file not being updated. That's fine. Let's get into a holy war here. Why do you want a monorepo?

Yeah, so I was building a service that had database, backend, frontend, pretty simple, three components. And I found that even at a small scale, myself and a couple of contractors I had working for me, it was just kind of painful to update the backend and sort of release it or build it into an image and then update the frontend, for example. Kind of amusingly, I'd say dependency automation like Renovate is potentially now one of the tools people could use to not need

you know, monorepos, you know, because when you do publish one thing in one area, you can have an almost immediate update somewhere else and test it and things like that. So this type of automation maybe makes non-monorepos more feasible too. I was about to say that kind of like, why do you need monorepo, man? If you have

dependency solution. Isn't that one of the main reasons you did it in the first place? A little bit, yeah. It was sort of so that all my dependencies in a way weren't dependencies in that sense. They're all in one place. And I guess I haven't actually used a monorepo since. Okay, good. We'll move away from monorepo. I don't want to get into the Google level of monorepo, but a lot of people go straight monorepo because Google does it, and that's a bad reason to do it. It's not an invalid reason to do it, but it's a bad reason to do it.

Yeah, I guess you don't want to go down the, if you're speaking of things Google does, but you maybe aren't big enough to need it, then you start talking about things like Kubernetes itself even. Yeah, build your own Borg. Yeah, we've talked about that before. Most of the time people don't need Kubernetes. There, I said it again and again. No, I'll correct you there. Most of the time people don't need to manage their own Kubernetes cluster. Okay, fair enough. Yes.

You know, you can use Azure Container Apps, which is beautiful and simple. And there is Kubernetes behind and you don't even see it. I think what we can all agree on today, and then we'll move on from this, container images are fine. How the container images turn into containers, don't do it yourself. Unless you have no choice. And there's probably 10 people in the world that have no choice. We're talking about Renovate. You built it because of the pain you were having.

How many of you, you meaning the dependency management tools, there's Dependabot, because you mentioned their name, Renovate. Is there anybody else really in the space? Yeah, so I alluded to competition earlier, and so I'm glad you came back to it. I don't want to be – well, it's a hard one to answer because I don't want to dismiss it. There are other tools in the space, but there's no ones that appear to have –

you say, a momentum behind them. I wouldn't say this is like intentional, but I think that the combination of Renovate and Dependabot has like sucked a bit of the oxygen out of the room now because you look at it and you think, well, okay, you know, GitHub is giving away dependency automation essentially for free and massive scale on

On the other hand, Renovate is open source. It's a very, through normal metrics of an open source project, it's a very open project. It has good velocity, has a very wide support. People add new package managers and registry types to it all the time. I think that if someone was to start, like for example, if someone was to start a new

I shouldn't jinx myself here, but they ought to start a new open source dependency automation tool. The number one thing everyone would just be like, but why would you do that? Like, I mean, Renovate is there. Like I said, it's open source. It's very modular. You can add anything you need to it. So I think the combination of that, that you have a very large commercial provider offering it as a free service, and then you've got a pretty healthy open source project means that, and by the way, both

both of those are, you know, free, right? I mean, whether it's open source, whether it's the hosted service I help run at Mend or whether it's, you know, GitHub's ultimately talking free. So you're like, I'm going to come and compete really hard against a couple of healthy projects for free.

And I think the result of that is when I say that oxygen's a bit sucked out of the room, it's not like people are like, oh, that's something I really want to do. They'll look for the overcharging or underperforming areas of software before they go for something that looks pretty healthy and is not really like, you know, a cash cow. I see projects that use both Dependabot and Renovate. That's what you were just alluding to there. Why do they need both?

What is the compare and contrast, or the Venn diagram of this, to get the whole? So it's not too common to use both, because I think developers ultimately want, I won't say a single source of truth, but a single source of pull requests, and they configure once.

Where you might see it happening is that an enterprise customer, especially of GitHub's, might say that they have Dependabot on for security fixes. You know, that's their corporate policy. But meanwhile, you have teams within that company who, for whatever reasons, you know, want to use Renovate and some of its features Dependabot might not have. So that's like an example of where people might say, okay, I mean, we...

keep the corporates happy by, yeah, we tick a box, we have Dependabot, but we also ourselves renovate maybe for the non-security updates. Now, of course,

Sometimes it's the same update, right? I mean, they may end up having an update to... Let's say if tomorrow Lodash released a security fix because someone finally found a new CVE, they'd probably get a pull request from Renovate and Dependabot and have to decide which one to take and then the other one would get closed. You mentioned security, which in my head is one of the main reasons why I would keep my dependencies up to date, right? Because most of the time, the updates are not really giving me anything in terms of new features, right? Or better...

More often than not, it's security, right? Especially patches. Is there some kind of relation or collaboration or something like that with security tools so that, hey, there is a high level of vulnerability detected by whatever. Let's confirm now this update or make it happen somehow.

Yeah, for sure. For sure. I mean, an easy way of describing is that your security update, like a vulnerability fix or a CVE fix, if you like, essentially that is pretty much the most high priority dependency update you can do. So category of update, but it's the high priority. For some people, it's the only type of update that they do. For some people, they decide that despite automation, dependency updating is still a pain. I don't see enough value in it, you know.

And so what they will tend to do is to be a little uncharitable. You know, they let their dependencies get outdated and they wait for a fire alarm, right? They wait for that alert that says, hey, hey, big problem, big problem. You need to update right now to at least this version. And ideally, they hopefully have an automated pull request, whether it's from Renovate or a commercial provider. Where it differs a bit is that, like, Victor, in your scenario where you try to keep up-to-date

When you get a security update, it is probably like a patch or maybe two feature releases at most or something. If you've been keeping up to date and you'll be able to look at that release notes. And maybe if the creators of that package are hopefully following best practices.

That security fix doesn't bundle a bunch of other high, how to say, stability risk stuff. They don't say, oh, we rewrote our entire backend, also fix this critical vulnerability because they may have broken stuff, right? So hopefully you look at it and they say like one line SQL injection fix or something like that. And maybe you'll even click through the source code. Yep. I see the diff.

And you'll be able to update it. So you'll have updated and fixed that security before you finished your first coffee of the morning. Picture another team that doesn't update dependencies. They'll get an update and it'll be like, okay, you have 27 feature releases between you and the fix. And they're in a really tough spot because then they have to choose between basically rushing an update without validating it, you know, without doing enough testing as they really should.

27 feature releases. So they can rush it to be safe, or they can delay it and say, there's no way we can test this all today. We have to remain vulnerable until at least tomorrow. So, you know, as you're saying, there's a rock and hard place, right? So if you are using outdated dependencies, you're doing the least work normally, but you really introduce high risk

of this situation where you've got to make high-stress update fast. And that's the difference between proactive updating and reactive fixing when it comes to security. I guess there must be also a relation between users who use Renovate or Dependabot or similar tools and the frequency with which they're releasing things. DoraMetrics high-performing teams...

You release once a day or a couple of times a week, you're more likely to use it. You release once a year and those companies still exist and kind of like, we haven't updated anything for 17 years. Yeah, there's a high correlation between like high performing teams and dependency updates. At the opposite end, you have teams who they'll add an open source dependency when they need to, you know, oh, adding this new feature, I had to get a library for it. And then they may just leave it forever. Yeah.

They may be using also, you know, deprecated APIs, even unknowingly. They don't know that that API is there. They keep adding more and more technical debt on top.

So yeah, there is a very high correlation. And I'd also say that that type of user helped a lot because for me building Renovate, there was a lot of people who came in with amazing ideas because the correlation there, there was really smart people who sometimes would drop into a completely unknown code base to them and contribute a really great idea or refactoring even. I think that

When you do have something that attracts the early adopter types, you can really benefit in ways you don't anticipate to. Do you remember any of those amazing ideas?

Whoa, you're putting me on the spot. I mean, one that comes to mind, I wouldn't call it an amazing idea, but it blew me away at the time. I was actually on vacation, vacation from my own startup, but I was on vacation and a guy popped into the GitHub repo for RenovAid and he said that like, oh, hey, I was thinking like, because I had actually been writing tests and he said, hey, I'm

I think that you'd be better off if you adopted the Jest testing framework. And if you don't object, I'd be happy to basically set it up for you and convert all your tests over. And it really blew my mind because it was the first time I'd really been working in this type of open source. I was like,

sure, that'd be great. And sure enough, within the next week, he'd refactored it and adopted best practices for Jest. And these days, although Jest isn't necessarily that kind of favorite or popular to everyone, the Renovate project has 100% unit test coverage. And we enforce that for every fix, every feature. And it's one of the reasons why we can also move fast. And that origin was someone who was a high-performing developer, dropped into the code base and

Made a really good change. So let's continue with that story. You had somebody come in from the outside. I'm assuming that was prior to the mend, quote unquote, acquisition of Renovate. Yeah. Prior to any commercialization as well, even. So now that it's commercial, as this guy or girl is listening to us right now, it's like, well, dang, I should have gotten some coin out of that. Because now it's commercial. I mean, what's your thoughts on commercial open source?

That's funny you mention that because there's an extra bit of that story that I wasn't sure whether to add on there. When I decided to run RenovAid as a service, as well as open source, I went down that path. I switched from an MIT license to an AGPL with contributor license agreement.

That was really the only way. It's not a fully defensible mode, but it makes it defensible. And it was interesting because what I needed to do was to track down all the people who'd contributed before that and essentially ask their permission, get them to retroactively sign to use that code.

And so he was one of the people I had to get in contact with and say, Hey, look, I, and I was very open. I said, look, I'm planning to change it from an MIT license to an AGPL license. And that's so that if somebody else does say commercialize it, at least they have to, you know, there's a good chance to have to contribute back. They can't just kind of take everything we do in the open and,

contribute nothing back. Meanwhile, the contributor license agreement would allow me to potentially make my own modifications to it, you know, to run it as a service without needing to just give that away for someone to then run for cheaper than I can. I'm happy to say I had like those universal support of that. People were like, well done. I love Renovate. Thanks for building it. I really hope you're successful. Like without exaggeration, that was the universal feedback to that. So it was a joy, joy, happy, happy instead of what do you mean you're taking my work for free and

making money off of me. Yeah. And then to maybe extend it a bit longer. I mean, there's a lot of commercial open source to varying degrees. I think one of the secrets to being successful when there is a commercial element is that it's got to be blindingly obvious to anyone who has doubts that what you open source is like sincere open source. There's a term I use, sincere versus insincere.

To me, like insincere open source is like, say, the open core, like where people open source like a part and they may even call it the core. But if the reality is they have no interest and they may even, in fact, essentially put up barriers to having people actually run it themselves as an alternative to the commercial, you know, they're kind of like it's out there, but like good luck running it.

And that might be software where you've got to go and fully compile it and build it for Windows or something or Mac and things like that. That's not really, you know, that doesn't fall under my definition of sincere open source because you're not sincerely happy if people run it

completely for free, don't even know who it is without permission. We've always, and thanks to my employee men for that, we've run it very sincerely all this time. In fact, I would say that probably 99% of the people running Renovate themselves do so with the open source version. And I probably don't know about 80 or 90% of them because like I said, sincere open source, they run it without permissions whatsoever.

You know, without, what do you say, needing to ask permission to run it. It's open source. You download it, you run it.

I don't know what the figure is right now, but like the renovate open source Docker image on Docker Hub, thanks to Docker for hosting it, it exceeded a billion pulls in like 2021 or 2022, maybe 2022, something like that. You know, that's a massive use. And that's why I like can say with a straight face, you know, like that's sincere open source when you have billions, a billion plus people pulling it. And you're seeing that as a good thing, not trying to change your model or something like that.

Taking a look at the Renovate GitHub repository, you've got the standard, hey, here's the star up into the right drawing, I guess. It looked to be a fairly linear grow. No, it's not a hockey stick because I don't think it was a logarithmic chart. So you were saying you had billions. You did say billions. Of docker pulls. Yeah. My question to that is, okay, we had this thing back in 2020 that spun the world. And did you...

see more than or did you see just i mean if i look at just usage it sounds like there was probably a big spike where are we at now in 2024 yeah so i think i'm looking at the same same one as you the uh the star history and chart there and it is increasing faster than linear it's not quite it's not hockey stick as you say it's not quite exponential there i don't know i don't know the correct term

Too long ago since I did the math. But if you draw straight lines at every period there, I think you'll see that overall the number of new stars accelerates. I do have a statement about stars. I've never stated it before. I'll go ahead and state it now. Stars are like getting a drink at Walmart. 50 cents and you can have one.

Yeah, I read that. I read that too. To my knowledge, no one's ever bought stars for a good time. We don't see any signs of that if you look at that chart. There's not even any tiny blip. That's what I'm saying. Yours look – because it looks more organic, that's why it feels more legit, I guess. Yeah.

Yeah. By the way, although actually if you really go on Zoom, because I still now, now you bring back memories, you know, when it was just every waking moment almost was consumed thinking about it, planning it or coding it. And when someone tweets about you or something like that, you know, I check the get up notifications first thing. I actually still do. I literally still do. Like that's the first thing I check when people would tweet about it. And occasionally, if I could call it influences, people with an audience would tweet about Renovate

or even better if they worked for someone you know and they'd say, you know, I'll make one up because it wasn't quite true. Like they say, oh, it...

at Uber or something like that, right? Back then you could see bumps. You could see bumps. Given my history where I actually started it to try to get search engine boosts, I also would successfully, most times, I'd post a picture of the bump when someone had mentioned it. Let's say the victors of the world would mention it and I would highlight it and I would put like an arrow and I'd call it the victor bump from yesterday, say. And it was really great because most of the times people found that charming and then would retweet that with

which meant that if their audience missed it the day before, you know, they would see it the next day or two days later when they retweeted my shout out. Or even maybe they saw it the first day and thought, eh, whatever. But they see it twice, they think, oh, Victor seems to like this. So that was actually another little strategy I had in the early days. But, yeah, when you look at that star chart now, it's pretty hard to see much. Yeah, I mean, that's, you know, that's a sign that,

something is big right when i don't couple of thousand extra views does not really show on any chart in a way right

Yeah. Gosh, it's funny because my CEO one time we were talking about, I forget which, I don't think it was star growth because that's not saying folks, I think we're talking about installs or something like that. And I forget, he had a very, he was saying, I remember at the time that my assumptions about it were like in a way wrong. He was talking about, you know, viral growth. He was saying, well, what this is a sign of is like, you know, that it's word of mouth and not marketing or something along these lines. So it was like, we were looking at it and saying, it seems that this growth operates differently.

It's a factor of the existing install. That's right. I think you're saying it's a factor of the existing install. It's greater than linear. And what that implies is that people seem to be finding out from existing users because it keeps going up more. Like he's like, we're not spending more on marketing. We're not marketing it or whatever. We're spending more on marketing. We're not like, so if you see that it's like three times more growth per month now than it was two years ago, that's a reflection of, you know, the install base having also grown, which implies that it's like organic references more than marketing.

Who doesn't need to use Renovate? I'll go ahead and say people who don't know how to write automated tests. That's a possibility. I mean, I'm very biased on this. My goal is not that everybody should be using it in best practices and this and that. My goal is that a little or a lot, Renovate can be adapted to what people need. And I don't think there's many people that never update a dependency.

Even if you sort of will say you do it manually, I'd still prefer that they look at the renovate dashboard and they go, yeah, that's the one I wanted. And they tick that box and they get an automated pull request. The lock file is updated. The release notes are there. Like even if essentially they're manually updating, like nothing is automatic by default, I still would want them finding value from the release note retrieval, the confidence scores and things like that. Actually, I had a conversation a short while ago, maybe two months ago.

with a team that said, we cannot do this because it's too dangerous. We don't know what will happen, blah, blah, blah. We cannot upgrade. And then I asked them, okay, so, but when you started this project, how did you choose which version of your dependencies you're going to use? And then they started scratching their heads, kind of the latest at the time. And to me, that's so in a way silly, right? You have zero criteria, no criteria, what you're going to start with.

But then all of a sudden you start being afraid. You start with unknown for you unknown, but then you start being afraid that unknown should not continue. Yeah. Thank you for bringing that. I love that one. Because I also say, because we're like, some people say, oh, but like upgrading to latest, that's so dangerous. And I say, yeah, but...

You started on, I'm like, developers aren't scared of latest versions. They don't hate it. You start, I don't know a single, okay, I'll give one example. No one starts a new project and is like sitting there picking, now I'm going to take the third most release or something like that. No, because you have no reason to know why that one is any better. Maybe the latest one fixed something in the third latest. The only time I have seen people, so I have to, you know,

Because people listening will be like, I know a reason. Okay, sometimes you might say duplicate the dependencies from an existing project to a new one. That's like a fairly rare case where you're like, okay, we've got this set and I'm going to start with them. But yeah, when people add a dependency, like, okay, I need a library to help me talk to Redis or something. I'm going to add Redis caching. I need to find the Node.js library for Redis.

They'll find, you know, what is the probably most popular library and they'll install the latest version. They won't even think about versions. Frankly, they'll say like npm install node-redis and it'll just be the latest. And they know that.

As soon as that's done, they're suddenly cautious that the latest version is dangerous. Especially, you just said Node.js, right? Especially Node.js, unless it changed, I haven't been working in it for a while. When you chose that library for Redis, you probably chose 575 other libraries that that library uses that are completely, you have no idea. You just know that half of internet is all of a sudden in that application.

Yeah. You know what you just reminded me of? You know, there's this joke about, it's often, it's, I don't know, I don't think I'm offending anyone here, but, you know, there's a joke about, you know, someone who says, like,

Like I control what goes into my body or something like that. And then we laugh and say, no, no normal person knows all of the food chain and what goes into that chicken or whatever you're eating. And frankly, even what was sprayed on the lettuce. I mean, this idea that people know what's going into their bodies. It's sort of similar. It's like people are like, no, no, no, no. I hand select my dependencies. It's like, yeah, what about the other thousand?

that came with it you didn't hand select them good you just offended both carnivores and vegans all in one sentence i like it equal opportunity offender today yeah oh man the views will be through the roof though with this controversy mend again you were we were saying renovate was acquired actually you were acquihired into mend so that's that's because renovate

At that point, was it still MIT? Or you were AGPL because of this? No, I'd switched it to AGPL. I'm not going to get into the arguments whether AGPL is real open source or not, but it is. So let's just say it is. What does Mint do? What is the step up? So I could use Renovate, self-host it myself, but I don't need to because you had a service. Now, effectively, Mint...

is the service that you used to have, correct? Kind of, although Mend does a lot more than just renovate. So Mend is in the security space. That's why I sometimes call myself an accidental security professional. Essentially, both GitHub and Mend bought dependency automation tools for security reasons. That was a stage of the industry where companies got good at telling you you had a vulnerability, but then it would still be up to the developer to go off and fix it.

it. And so these tools were brought in as a way to automate what we call like remediation, automatic fixes. And that had a huge effect on the risk levels of companies. So they, you know, it was like this migration. Appeal went from having no idea what risk they had to companies being able to tell them pretty accurately, you got a lot of risk. And then finally, when you had automation, then you were able to actually start reducing risk.

So what MEN does is not just the updates, obviously, which Renovate drives, but also the scanning, the identifying of vulnerabilities, things like exploitability prediction scores and that type of stuff. And since I joined, we've expanded. We do first-party code security as well. You know, the classic SQL injection, things like that, warnings and container scanning, various things like that. So Renovate these days is essentially a component of a larger suite.

And if people wanted to just try out the renovate part, they can. Absolutely. Yeah. So our strategy at the moment is that we either already have or building out apps to all of the host of platforms, GitHub.com, you know, PitBucket Cloud, Azure DevOps, where the mend free plan is basically renovate.

you know, which is like, you know, because previously we used to run Renovate as a standalone app. We still have it like that on GitHub, for example, but now we're making it so that essentially the mend free plan. So for people who are interested in Renovate, you still have this, you know, it's fully open source. It's like I said, you can run it in one line. It's a Docker run command or an MPX command. It's very sincere open source. But if you're interested in having it run as a service, you even can get that mostly for free. Yeah.

So all of Reese's contact information is going to be down in the episode description. Reese, thanks for being with us today. Thanks very much. It's a real pleasure. We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and a link to the Slack workspace are at DevOpsParadox.com slash contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast.

Go sign up right now at DevOpsParadox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.