The Changelog: Software Development, Open Source - Automated dependency updates (Interview)

Episode Date: March 23, 2018

Rhys Arkins joined the show to talk about automating dependency updates using Renovate. Renovate is an open source tool to keep source code dependencies up-to-date using automated Pull Requests. We talked about who’s using it, the languages and environments that are supported, self-hosted vs SaaS and how that plays into supporting this open source, auto-merging, being a GitHub App and in the GitHub Marketplace, and building this as a business on someone else's platform.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. Error monitoring is by Rollbar. Check them out at Rollbar.com. And we're hosted on Linode servers. Head to Linode.com slash ChangeLog. Hey there, this is Adam, and I want to tell you about our friends at Linode, our trusted place where we host everything.

Everything that we do is on a Linode cloud server. Head to Linode.com slash changelog, get one of the fastest, most efficient SSD cloud servers out there. Nearly a half a million customers trust Linode, as we do too. Once again, linode.com slash changelog, and now onto the show.

All right, welcome back, everybody. This is The Change Log, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of Change Log. Today on the show, we're talking to Rhys Arkins about Renovate app, which is automated dependency updates. It's flexible, so you don't have to be we talked about renovate's configuration who's using it the languages and environments that are supported self-hosted versus sas and how that plays into supporting his open source auto merging being a github app and being in the github marketplace and also building this as a business on someone else's platform.

So Renovate is a project that hit our radar because of Ping and specifically we have to give a shout out to Nicholas Young whose name and avatar rings a bell so I think he's probably submitted before who told us you got to have Rhys Arkans talk about Renovate. Nicholas gave Rhys, he gave it this compliment. He said, it's the first GitHub app that has changed how I develop software by easing the frustration

of managing dependencies for the most part automatically. And he gets bonus points for not saying automagically. One of my least favorite nerdy words. So that's quite a compliment, and we'll get into that. We're happy to have you here, Rhys. Real quick, we do want to take a quick moment before we do that

and talk about Ping and some changes that are happening with Ping. So for those who don't know, Ping is our open inbox on GitHub, github.com slash the changelog slash ping. And for years now, we've taken submissions there, ask us anything, style posts, questions, feedback. Most importantly, I think show ideas. And if you've been listening to the changelog for a while, a lot of our best shows are because of our community

who submitted the ideas to ping, this show being one of those. So we love that. We want that to continue happening. However, we've also been taking news and article submissions like projects, articles, blog posts. We love those as well. We no longer want those on Ping, however, because we've actually built a version of that into the website where you should submit instead.

Adam, you want to tell them about that? I think it can summarize best with the update to the readme, which says this is no longer the place to share projects, articles, and news because changelog.com slash news slash submit is the new URL for that. And what you can do when you go there, it will actually ask you to sign in and create an account. But the important thing is, is that you can share with us like links articles whether you wrote it or not and that gets served into change all news on our home page and then potentially

can hit change all weekly which is a highly sought after beloved newsletter we ship every single week so if you're not subscribed to that i would suggest you go to changelog.com and you will see an option to subscribe and just follow that lead and do that. So ping is for show ideas and the evolution now is to share your news through changelog.com slash news slash submit. There you have it. So Reese, let's get to Renovate. Let's hear your story and this app that at least you got one happy customer, Nicholas Young, who's changed his life a little bit. So tell us about Renovate, what it is and the backstory of how it came to be.

Yeah, thanks. And thanks to Nicholas, of course. Yeah, so Renovate is a command line tool that is also being adapted to also be a GitHub app, which is what Nicholas refers to. But primarily, it's a command line tool that is used for automating dependency updates for projects such as JavaScript and Docker files and a few things like that. And it automates it using branches and pull requests in your existing project to try to fit in with the workflow you already have. Very straightforward. How about the backstory? Why did it come to be and how did it come to be?

Yeah, so Renovate is not the first to actually do this. I was using another tool called Doppins for a project of mine, and it was a web app. And Doppins was really good, but I broke the app into, you could say, like a monorepo with Docker containers where they each had their own package.json. That meant that I couldn't keep using the automated pull requests from Dopplins. None of the tools that were available at that point around the apps supported having a package.json know, that, you know, a dependency file that was outside the root of the, uh, of the project. So I just didn't have it anymore. And a few months later, I had a problem, which was affecting, uh, up to 5% of users, weird errors getting caught, um, in my, uh, you know, century reporting. And I probably spent two days trying to figure out what was going on. It was actually another developer one day, myself a day. And eventually we discovered that it was a

really strange bug that had been fixed by Google's Firebase like a month earlier or something. And I just decided never again, you know, because that was like a really, I couldn't even tell exactly how it was impacting users. You're getting exceptions thrown, but you don't know for sure what they're seeing or what's failing for them. And two days of developer time as well. It's just, it's too much. So I decided to hack together a script. And basically, it was like a bash script with, you know, git commands, git branch, git pull, git checkout, git push,

combined with just a little bit of JavaScript to make the pull request. Just want to comment on the fact that so many awesome projects begin with, so I decided to hack together a script. Yeah. How many times did we hear that? Lots. Yeah, this is absolutely one of those cases of like necessity whatever and uh so so i worked out how it could be done but i kept again

it was like another week another week so i actually i paid a freelancer i just advertised it and found someone who wrote that and and by the time he finished it i realized that i didn't actually need to use git you know know, they actually, GitHub themselves provides like a Git API. So somewhat, you know, for no real good reason, but I decided to rewrite it then myself using pure API. And there it stood and it worked. And so at that point, it was still just a script that I was using. And I was thinking like, maybe I should open source this. And then I had the idea that I would open source it for like SEO reasons, search engine optimization, because I was working on a real estate side.

I still have it. And I had this thing where whenever I would open source something, I would pick a name that was relevant to real estate. And so I already had one project called Lint Condo, which was a lint container for Docker. And that one actually got in, you know, docker.com's newsletter and things like that. And I got some links back to my blog. Another one I released was called Home Inspector, which was, you know, was another screenshot regression testing. And for this one, then I hit on the name Renovate. And it was only when I got the name, I thought, that's a perfect name.

And that I decided to open source it. And I thought, well, I blog like an announcement about it. And there'll be a few sites interested in it. And I get some links back to the site because it's just a bootstrapped real estate site with no advertising budget. And that was basically my first reason to open source it. So it came out of necessity why I wrote it, I open sourced it for search engine optimization.

But then people actually discovered it and used it and kind of like out of like obligation or pride you know when they would say this is really cool i just need this or can you add that i started doing it when was that like what year was that that was about about one year ago that was um that was around like i think january of 2017 okay curious before you go further what's the how does the seo impact the naming like give me maybe i'm missing it what is what is the, how does the SEO impact the naming? Like give me, maybe I'm missing it. What is, what is the reasoning there for that? Well, I mean, Google still fundamentally works on, you know, backlinks, you know, like if

you're important, people link to you. Right. And, but then Google of course tries to work against like gaming of the system. You can't just spam a bunch of links or spam keywords and things like that. But like if real legitimate sites link to you, then, you know, that kind of counts. system you can't just spam a bunch of links or spam keywords and things like that um but like if real legitimate sites link to you then you know that kind of counts and that's what they use to decide whether you should be high enough or not and um but part of it though is that they also are smart and they filter out if if links seem to be completely irrelevant to what you're doing

such as in my case a real estate site but if if people link to you with an anchor that says like, renovate or home inspector or condo, then, you know, in my like theory, that should hopefully be good enough to sort of bypass that a little bit. And I didn't really see anything wrong with that because, you know, people are linking because it actually is something useful. And like, it's always fun to have a naming convention no i love it so yeah so i that was what sealed it for me was like okay i'm gonna i'm gonna release it and i'm gonna give it the name renovate and people are gonna link to my blog you know which is hosted on the same domain as my website

and uh that'll be worth it you know better than paying some seo person you know like a thousand bucks to like give me some like spam kind of links that don't look spam. Like I may as well actually do something useful. So does it actually feed back into your real estate site too? Is that part of the point? Well, it was more just that where, where, when I put it on the blog, you know, the blog saying, here's what I wrote. Cause I didn't have any renovate app.com or anything then. The point is that people would link to that, which describes it. And of course then go to GitHub and use it. But apart from that, it wouldn't really have anything to do with, I actually had a separate sort of blog page on the,

on the real estate site called like our tech to separate out like real estate blogging from, you know, open source work. So here's a, here's a big picture question related to all of this. And something that I've thought about sometimes is when we talk about real estate, like, you know, domains are online real estate. And something that I'm a believer in is like owning your own real estate and not putting all your pearls on other people's platforms. So syndicate, right? So like with Change.com, we write for our website and we syndicate out to these different media, to Twitter, to Facebook, to even micro.blog. Now we're syndicating RSS, but like everything comes back to that one place. And that's really what you're doing when you blog about it with

your, on your real estate site is you're linking everything back to there. But one thing that we, all of us developers don't do is we don't host our own Git repos. We don't host our own documentation. We don't host our own stuff. And so ultimately we're giving all of our, our, the, the last mile to GitHub because we're hosting our actual things there where people are linking to and spending their time to GitHub. And I know, I think it was Patrick McKenzie back in the day patio 11 who's become kind of internet famous in developer circles slash entrepreneurial circles because of all of his writing around entrepreneurship and what have you um and he made a split testing

ruby gem years ago and he refused to put it on github or maybe it was on github as well but like everything he did was he hosted that it was open source and get all that, but he hosted it on his website. And the reason was the reasons that I'm saying. So I'm curious if you guys have had thoughts about that and, and if we're all just kind of given all of our Google juice to get up. Yeah. I mean, not, not, I don't have too much concern with that part because I think it's partly to do

with how, how closely related your source code is to like to your main sort of website even if you're going to self host you're most likely going to end up putting it on like you know git.renovateapp.com or something like that so it's still technically going to be like a separate uh domain um you know i think gith GitHub did a really great job of capturing the open source market all that years ago. And opinions differ about how much they keep doing to retain it. And you can debate for a long time about does the community owe GitHub or does GitHub owe the community? I mean, they're hosting stuff for free and they don't put ads and things like that. They don't sell you details. So, you know, you're not quite the product. Yeah. I don't know about that. What do you think, Adam?

You know, that's a good question because we link out to lots of open source and whenever I have a chance to link to somebody's landing page, which is usually their domain, versus the repo, I will more often than not link to their homepage and then in the details of promoting this new thing or describing what's going on, here's also the source on GitHub. Because I feel like, which you feel like, the hub and spoke model, I feel like people should own their content and I don't have anything against GitHub and the open source. I just feel like people should own their content, and I don't have anything against GitHub and the open source. I just feel like the legitimacy of that.

Strategically, it's smarter. Yeah, I feel like giving it to them first because a GitHub readme looks like GitHub. It doesn't look like a branded version of X. And sometimes like Homebrew, you go to Homebrew's website, beautiful looking site, documentation is clear. You can easily see that it's on GitHub. You can see all the other things they can advertise you're you're removing their ability to better communicate to their community by only linking to their rebate you know which is essentially the github repo yeah i think that's a good idea like when i so these days um i you know have renovateapp.com um which essentially is for the app part, not so much the open source.

I mean, as in it's intended for people who don't care too much about the source. They want to use the app. And I try to filter out all the stuff about how to host it yourself and so on because that just confuses people if you give them options that aren't actually valid to an end user. So I tend to adjust where I link to depending upon like the audience or what they're after yeah yeah i certainly wouldn't want to self-host my my git yeah it's a matter of convenience in that case yeah i'm not gonna do that yeah github owns that they do a great job and like like reese said you know do we owe them or they owe us us? You know, are we the product? I think the open source community is the product because, I mean, GitHub is, they're giving it away. But at the same time, they're getting so much traffic.

They're getting so much authority. You know, think about all the Google juice that's going to them, Reeves, that you're after. Like, imagine the exact opposite. Like, we've been linking to GitHub for years. Not that we're a big source for their juice, but multiply us by, you know, 10,000 other media outlets.

That's right. You know, linking to get, they're getting a lot of benefit. Yeah. It's a new system. Everybody gets, everybody gets things out and I agree.

It has to do with convenience. I guess more, I guess my takeaway from this is kind of what you said, Adam, specifically like have your own home page you know sure host your code there on i mean all the tools are there your your your clones can be off github or what have you but if you have an open source project and it's not just like a throwaway like i have open source stuff that is just throw it up on github and whatever but if

it's actually the thing that's in support of a goal of yours like it is the case with reese with his renovate and his other tools where they're trying to provide some benefit back to his business. Well, have a homepage for that and have an own that domain. Right. So if GitHub goes away or you ever want to move off it or whatever, you're not tied to that URL. You're tied to a URL that you own. And then sure. So host the source code where it makes sense

cool um well that was off topic these are the things that i think about and then i start here somebody talking about it i'm like wait a second i've been thinking about this too so yeah i well i'll put a little bit back on i'd say that with open source um i i had did actually notice that there are companies that do try to use their open source to sort of bring attention to themselves. You know, they host their open source page on their main domain or on a domain important to them. I've seen others, but I forget now, that do sort of use names that are aligned with their business. I don't know if they're like me and they're like desperate for backlinks or if they just think it's cute to have a naming scheme that reflects your company. But I think a lot of companies could probably do better to host their own

open source sub page and use that to focus them. I agree. Focus attention a bit more. Absolutely. So that's the backstory of how Renovate came to be. You created it as a scratch-your-own-int shell script. You open sourced it for Google Juice and because you had a cool naming convention going that you wanted to use. By the way, Renovate's a perfect name. So I know why you hopped on that and felt good about it. It plays very well, especially now knowing that you're in the real estate business.

It makes it even more poignant, I guess. Yeah. And from there, it required a few little rocket boosts, I think, to be where it is today at the very early stage. And one was when one enterprise user mailed me just out of the blue and said that you know like the tool was actually like really important to them right now and they'd hate to see it just sort of die and like would i consider a way of getting paid for it kind of thing like you know they want to keep see it alive and they understand and uh you know i declined that i said thank you very much it's not really necessary at this point um but that was like a really good motivator that you

know people felt that found it that useful and the second one was when another person from an enterprise posted about a year ago and said like would you object to switching to the jest testing framework because like it's much better and it would I'd be able to submit like quite a lot of tests for you if you did that. And I'm just looking at that from my mobile, I was on holiday at the time and just going, okay. So I think I literally replied like, well, sure. I mean, I can't say no to somebody promising me to add tests kind of thing, like try to reinforce, like, okay, you know, that's what you offered. And sure enough, you know, switched it to Jest, improved a lot of things. I was not a testing expert and improved the test coverage a lot.

And that was basically, I think, him thinking that, well, we use this and I don't want to see you breaking it on me. So I'm going to add tests for the stuff that I know is important to me so that you at least get notice if you break stuff that I need. But that was also really shocking to me that someone would do that. It was probably like two days worth of work maybe. And that again, kept me going. And then the final bit, which sort of turned it was that I had multiple people saying to me, even still though, they said, well, this looks really great. And this is actually exactly what I need, but I'm not going to use it. And they said like, if you ran it as a service, I'd pay you to use it kind of thing., like, if you ran it as a service, I'd pay you to use it kind of thing.

But, like, I don't want to be running another server, another thing I have to monitor the watch. And that was really interesting because when I heard that, you know, a few times, I thought, oh, that's interesting. And that's where I sort of got the idea that, well, maybe this has like a long-term future as like part service, part software. There's a couple of topics in there. It's like, it sounds like this was your, and I don't want to say this negatively.

Maybe it's just say it is the easiest way. Like this sounds like this is the first in quote successful open source project you've had. So something that's like open dries to, you know, how open source works and how to, you know, interact with the community or even take in suggestions like you know switching to jazz for testing or whatever and then also it's open your eyes to how potentially this open source thing that you created as a scratch your own itch that you never really seemed like you were like hey i can make a business out of this now has

some entrepreneurial business opportunities for you that you're now, you know, either planning or investigating, like at least opening your eyes to it. So twofold, there's like your first step into open source. And then now it can be something that can actually turn to a service. Yeah. Yeah. I mean, like I said, these are still like turning points. Like if I didn't have those motivations, it may not have, I wouldn't have put probably more time in it, would not have got as many people and so on.

So, you know, chance and luck plays a big part in this sometime. This episode is brought to you by Gliffy. Gliffy is the easiest way to visualize any idea. Use Gliffy to diagram UML diagrams, flow charts, or charts, wireframes, and more. And in this segment, I'm talking with Mike Sample, a fellow listener of this podcast, as well as the engineering manager at Gliffy who leads their drawing platform team.

And I asked Mike why he thinks Gliffy is an important tool for developers. Why I think Gliffy is important. I've been involved in a tremendous number of development projects. And invariably, you know, that process involves a lot of the front loading of imagining what a complex enterprise software system looks like. You're dealing with a lot of people, you have a limited amount of time to ship product. Both the product is complex, the process is complex, and most importantly the communication is very complex. And what I found with Gliffy and what others have found is here's a tool to visually represent very complex processes

in a way that everyone can immediately kind of coalesce around. It provides this kind of common visual language for understanding really difficult topics and a source of truth so that whenever you need to go back to a workflow or something you haven't touched in a while, it's that source of truth for you. So tell me this, Michael, who's using this tool? This is not a novel observation. I'm not the only one who uses this. It's a very easy tool to use. Four and a half million people use this tool for all variety of purposes for creating org charts and flow charts and UML diagrams and floor plans, et cetera, on and on. I use it with my own team. Whenever I worked on any large enterprise software project, I always spent a little time kind of

charting things out. Sometimes that's a pen and a napkin. You know, before I knew about Glyphi, now it's Glyphi and it's easy to use. It's on a webpage. You know, I don't have to download software. I don't have to download software. I don't have to, you know, learn some complex interaction in terms of manipulating shapes. It's just drag, drop, attach, you know, move, label. It's very, very simple and it's extremely powerful in terms of getting everyone to understand something at a very high level. All right, it's easy to get started. Try it free in Atlassian, inside Confluence or Jira or online at gliffy.com slash changelog. And as a special bonus, our listeners get 25% off one year of Gliffy in Confluence or Jira. And to get started or to find those details, it's all at gliffy.com slash changelog.

All right, Reese. Well, the front of the package says automated dependency updates. That's a very simple sentence, but undoubtedly there's a lot that goes into providing that either as a tool or as a service. Can you tell us, unpack it for us and tell us how Renovate does what it does? Yeah, sure. So one quite interesting thing is that the tool behaves basically the same as the app. The app is actually a thin wrapper around the tool. There is no fork going on or different behavior. So you could basically like uninstall the app and go back to self-hosting

and all the pull requests you have open and things like that will still be valid and updated and so on. So pretty much everything I described covers both the tool or the app. And the way it works is that at a base, it runs on a schedule. And I normally recommend to people one hour, but some enterprises run every 10 minutes. And it scans each repository for package files that it understands, like package.json, Dockerfile, Meteor, package.js files,

Google's Bazel builder as well. And just recently we added nvmrc and travis dot yaml files because people wanted to be able to upgrade their node versions in sync um and they can actually that node node node versions can be found in many different places um so yeah so it um it scans for all the files. It extracts the dependencies that it finds. It applies a cascading config to it, which gives you a lot of power, but also complexity. And then based upon how you've configured it, it looks up updates and determines what you should be made aware of.

So it builds a list of, okay, okay, this is what we need to do, checks what's already there, and if anything needs updating or creating, then it does it. And it actually does this by keeping all the state in the repository. So the tool itself, you could say, is stateless in that it doesn't need any state file, which could be corrupted or out of date. It actually uses GitHub's Git repository

and the list of branches that have been created or pull requests that have been closed. And it basically uses that as its state. And so the naming of branches and the naming of the pull request becomes quite important because they kind of become like lookup keys um but uh but yeah so um it just it runs and one difference in the web app is that it's been um you know it's been web hooked so it listens to github webhooks for every repository it's installed on and if that webhook event looks meaningful such as the person's updated a package.json file or they've updated their renovate.json file then then it runs again on demand to to update it so so then it's quite nice because if people you know edit their

dependencies all their all their pull requests get updated if necessary. If they change their config, then again, everything gets updated if necessary. And then it also has a listener for NPM JS. So it basically gets updates or notifications using a kind of subscribe notify approach of CouchDB. So it gets updates whenever any new package is updated. And we do keep a little bit of state, but it's in a way unimportant state. It looks for any repositories that had that

dependency at the last time they ran. And if so, again, it puts them in the queue. So it means that if a package you depend upon on npm.js gets an update, then you can expect to see a pull request within minutes. This gets particularly helpful when you have multiple repositories that belong to the one organization or the one project. An example is in GraphQL. There's a lot of GraphQL repositories

using Renovate and the GraphQL guys. And, you know, they'll often do an update in one upstream repository and then that flows down to a downstream one where it needs to get merged and that might flow down to another one. And thanks to the webhooks, it means that, you know,

that can be done in kind of minutes. And so it's almost like an alternative to the monorepo because, you know, at least you're not having to update it manually and in kind of minutes. And so it's almost like an alternative to the monorepo because, you know, at least you're not having to update it manually and it happens within minutes. And that's a little kind of, that's a little like a value added add-on of the app that you can't really do in like a stateless command line tool.

It would need to be, you know, alive and listening and you have to make sure it doesn't crash and all that kind of stuff that I take care of with the app. Okay, so that's not exactly the way that I was thinking that it would work in terms of the... It's checking live, so to speak, each time it's run on a schedule. Or if there's a webhook that comes in, of course, it knows that it probably sends the new version of that particular dependency. But when it does a full run on a specific project or repo that you have it's going to go to all the sources and i guess in many cases it's just npm and just check for the most

recent version of that library and it's going to do that for each of your dependencies each time you run it that's right okay with yeah with some caching and so on. Yeah, so caching definitely important there. I was thinking more of like the library's IO approach where they're basically creating, you know, a huge dependency graph in the sky of different libraries and versions. And they have all of that data on their own. And so then when you, I guess then when it runs, it kind of be pre-existing, but that would require a central light service and all that. So, okay, very cool. But then it's even a lot of unknown, you know, knowledge you didn't really need to have.

You know, Reese's version is like on demand. And so it's, you know, not- It's more pragmatic for what he's up to. And, you know, libraries.io's mission is much bigger in terms of what they're trying to do. The stateless aspect of it, where the state is really in the git repository itself um it makes some things difficult to do um but it also provides huge numbers of benefits because you don't really and you reduce the risk of kind of like corruption or state mismatches or things like that um given

that every time it runs it ensures that the correct view is there right now. So to give you an example, if there was some kind of error, it might be my error, it might have been a server-side error, like a bad response from GitHub when we looked up a changelog.markdown. So if a pull request was created

and the content of that pull request, which said, you know, we're updating you from 2.1 to 2.2 and the change log is empty um if the next time we run and that problem's been fixed or maybe the person wrote the change log then that pull request gets like patched so um because every time it runs it ensures that everything is kind of like correct at that point in time it it makes it quite like self-repairing. And if it like crashes halfway through for some reason, then there's no type of crash I'm aware of that causes any state problem that requires manual intervention. it's also i would think would make the programming model like the conceptual model in your head as you're writing that which is a complex thing to run through especially with having those transitive dependencies and everything it's more simplified because you're guaranteed a known state

at the start of every run right yeah that's all there it's not going to change as you're running yeah i got a question on that front jared since you mentioned that do you ever considering how complex this is and it's potentially always in your head race and now that it's and it's been open source and other people are contributing do you ever put a visual to some of these things that like it's difficult to talk through because maybe a visual can say like you know this is how the model works in a visual standpoint. Do you have things like that? Is that important to you? Visualizing workflows for this?

It isn't currently there, but it is quite a good idea. I mentioned earlier about it has a cascading config. You know, in my mind, I think of it as like, I try to, I use a term like ridiculously configurable or something, meaning that you can, you can control the functionality so much to the point that you can do things that are even like silly. Like you can, you can write a rule that says, you know, for like patch versions of this exact dependency inside dev dependencies in this package file, then do this kind of thing. Because it's like CSS, it cascades. You can have global rules, you can have rules per package, you can have rules per path,

you can have rules per dependency type, you can have then catch-all rules for packages. So you can use like regular expressions to define your matching rules and things like that. Because I found that so many people have a lot of like, you know, in their requirements, they have a lot of like, if else, if else, if else kind of requirements themselves, you know?

So like, they'll start off by saying like, you know, I just want to get an update every week. And it's like, yeah, that's easy. Just add, you know, like they'll start off by saying like uh you know i i just want to get an update every week and it's like yeah that's easy just add you know this preset like schedule weekly and then they're like oh yeah but like this package i need that's my own package and you're like no problem okay so add this exception to that rule you know add this package rule and then oh yeah but i only want to auto merge the minor ones not the major, yeah, that makes sense. So then you set this, you know. So when people have the freedom to describe, you know, exactly what they want, then they end up having quite, like, a wicked set of requirements, you know.

When people realize that, like, they are in control of how Renovate behaves, then they start kind of getting more and more advanced. And some people have got, amazingly complex um configuration files that renovate you know dutifully implements and honors yeah i noticed on your sales page or on your home page i should say you have a use the adjective unopinionated which seems like it's the opposite of what most softwares as a service or even you know frameworks or whatever it is. People try to sell their software as opinionated. And most of us appreciate opinionated software because it has opinions and that's like making decisions for us.

And I found it interesting that you explicitly say this is unopinionated. The reason for that is because there's so much variance in the way that people want to handle their dependencies that, like, I guess the 80% solution is not good enough. It is. Exactly. The variance is huge. And it's very almost amusing at times. Because I see people at the complete, like, opposite ends. You know, I see people that want, like, the firehose approach, separate everything. And then you see others that want to group everything together.

You see people that want to have ranges in their package JSON, and others say, no, let's lock this down to pinned exact versions. You see people that want to have a log file. You see people that say, I don't have a log file for this project. So the opinions of other people um are very wide and you know i added a i don't know if you saw this one but i added a kind of like a motto for the tool maybe about a month ago half as a joke but um it's warming on me and i'm thinking of keeping it and the motto of renovate is flexible so you don't need to be and because

that basically describes how i view with the users like yeah i don't need to be and because that basically describes how i view with the users like yeah i don't want to be in arguments with them convincing why they have to have a lock file or they should be pinning or things like that or why they should separate them so that you know one bad apple doesn't spoil i just want people to be to be able to do what they want to do and then maybe over time they'll realize ah yeah like grouping all of them together every week basically always results in a broken build because at least one thing breaks and i end up merging nothing you know so the person that at first is very resistant and say well this will be disruptive you know changes

their mind and says okay well maybe we'll just group all the minor updates then you know and then over time they'll be like yeah i'm still getting a lot of breaks and you know all this disruption they thought would happen by having separate pull requests actually is outweighed by the disruption of them having to look through a pull request with like 12 different upgrades and figure out which one broke versus, you know, if you put them separately, you know, and configured them to auto merge or something like that,

you wouldn't have that problem. But, you know, I'm kind of proudly in that sense, like flexible or unopinionated it's like you want to do it you can do it like i don't i don't want to be in the game and trying to talking you into why you should do the one way that i think is best right you let people learn on their own by by trial and error definitely though yeah and and for sure like not everybody's gonna um you know um converge on the same behavior either. You know, there's definitely still.

I was going to ask that, like, is it, you know, but is there a best practice that you know what it is and you're just letting people, everybody's going to eventually get there? Because if that's the case, then you might as well just, you know, start preaching and like get people there faster. Occasionally, yes. So, like, for example, I think that you should always have a lock file but there's some very smart people um who've written a lot of great software better than mine who think that um libraries should not have lock files because then they think that you know you're if you're not getting the random roll of the dice when you npm install like your users are then you're going to be you know seeing something different to what they see yeah for example that's their their argument

there's other things like i think that uh pinning your dev dependencies makes a lot of sense like the reason why you don't pin dependencies sometimes is because you have downstream users and you don't want to be unnecessarily restrictive of your downstream users right they may end up with duplicates or whatever but your dev dependencies never leave your project and it makes sense to be like yeah this is the exact dev dependencies that we know you know are working for us right now i've definitely been in the situation as an end user of a library trying to upgrade and the library i'm depending upon pinned their dependency right too tight whereas there was no reason for it besides that's just the version that they were on when they last released and you could go run their test suite

against the new even if it's just a patch i think it was just a patch and it works just fine and it's like if they would have just loosened that or not had it at all, then I would have been able to upgrade without having to bug them. But because they did pin it, now I need my dependency to unpin and update before I can even continue with my work. Yeah. Yeah.

What is the process of pinning? What is that? So at least in Renovate terms, that's when you install Renovate and Renovate says like, well, now that you're automating this kind of stuff, you can pin dependencies. And that would mean that for example,

rather than having like a range that says ESLint 4.0.0, you know, with a carrot, that instead you would say like ESLint 4.2.1 or something like that. And then at your choosing based on your configuration, when you want to update ESLint, you can do so and you might upgrade to 4.3.0 or something like that. ESLint itself is maybe not a good example, but a better example might be say if you use like ESLint config, like Airbnb or something like that,

because those ones are quite opinionated. And the whole point of many of the releases of those presets for ESLint is that they're introducing new rules or stricter rules, or they're catching something bad that they were missing before. So the whole point of a linter in a way is to break your build, but it's not very nice if you kind of have like open ranges in the log file.

And so users come along and run install and try to run a test and they find that like the lint fails because a new rule got introduced you know without explicit you know approval emerging so that's example of where like you want to pin that down because like nobody gains from just having like a random new version um appear in some people's computer while you know others have a have a cached older version and say no it works on my machine exactly yeah oh nothing but trouble so we've been talking specifically in the context of uh npm and package.json we haven't asked you yet if renovate supports other package ecosystems or if it's just npm yeah so the two major ones are um npm and docker um but it's definitely in you know my goal is that renovate um becomes a kind of a universal tool um universal in terms

of language and as well as in terms of platforms because like apart from github it supports already gitlab and vsts and bitbucket support is like in a pull request so my goal is to make it cross platform and cross package manager so um we've already added uh docker support um and there's requests for you know others like you know like python or uh you know java ones like you know maven and things like that so um yeah the goal is to make it essentially like a universal approach that did you have that goal from the start? Or is it at least, when I think of expanding beyond, you know, kind of where you are, I think of, well, I hope the architecture is set up to be pluggable to a sense

and not like, okay, in order to support Python, for instance, we're going to have to rewrite, you know, 60% of our code base to do that. Yeah. So it definitely was not in my foresight at the start. Like many of the features of most of the features of Renovate, they've come from users suggesting it. It's been very much like a user-driven thing. And almost every time a user wants a feature

and I figure out a way to kind of gracefully add it, I kind of breathe a sigh of relief that whatever choices I made previously weren't too limiting. So, yeah, it's again a bit of luck there. It started with NPM only. And then someone came along and asked if I could support Meteor. And because Meteor itself was really just referencing NPM dependencies, it was like 30 lines of code in about six different files and it was done um when docker came along that one came along because people were chatting in some maybe a

blog post or something you know it was in a discourse discussion something like that and they were talking about the challenges of keeping docker dependencies updated in particular um the um hashes because even though most people use docker tags you know like even if you use a tag like you know 8.9.4 for node.js um that itself that's not an immutable tag like an npm like if 8.9.4 or something gets published to npm you know that that's always going to be the same whereas in docker those are like those may be may look like a semverb but it's really just a tag and you can change anything underneath a tag um you know so the only way to have like immutable references in docker is to have like a sha256 hash which is like enormous and it's very unuser friendly and someone actually commented that like

well it's a pity like there isn't like a renovate for docker and and like sort of mentioned me or something like that and that's how docker support came about because i thought yeah that's really good because you know in when we look at like package json dependencies in a way you could argue that we're just automating something that people could do manually like it's you're you're you're automating a feasible manual job um when docker and you have these big long hashes um that's starting to get to the line where it's like this automation is now essentially making something possible that really isn't feasible manually like looking up hashes and pasting them in and not making a mistake and that's getting a bit beyond what's reasonable and that's why hardly anybody actually

uses hashes whereas now when people say use docker files with renovate and they start with even if they have like node latest even though they want to like you know do it that way at least now it'll it'll pin node latest you know at hash and so every time node latest actually changes you get a pull request that kind of tells you it's changed you can see if it still passes or doesn't break anything so you even if you want to be you know non-semver versioning you can still get updated whenever that hash is changed you know whenever that tag on docker hub um the i did some uh re sort of refactoring recently to make it a lot easier to add languages in and there's actually there's someone who's told me that uh um he thinks he can add in uh docker compose support pretty easily now given that there's already docker there so hopefully we'll see a lot more languages added

a lot a lot more quickly now that um the code is a little bit more welcoming of like outside languages and package managers yeah so you mentioned that with package.json you're basically automating something that people could do manually and i'll tell you right now that you're automating something that i do manually for for our application um which is you know i just go in there every once in a while so we have elixir app which also has javascript as all web apps have javascript somewhere in the mix and so we have a mix.exs which is the elixir side and we have a package.json and uh and i were just talking about this like keeping it how do we keep up with the jumps? You sound frustrated just describing it. Well, it's not fun work.

I do it manually, A, because I haven't seen a compelling tool that will do it automatically. So this will work for our package JSON. I would implore you to add a list for support. Or I would sign up on a list of people who will wait for that eagerly although admittedly not probably high on your list in terms of uh language um penetration but yeah um yeah it's just a task but it's one i'm i'm kind of a i don't know maybe a pedantic like obsessive control or developer kind of person and so like i want to see what actually is changing and i want to like pick and choose yes we want this update no we don't want that update um and so i probably would have like the super complex configuration yeah yeah i mean once people learn that they can

control it they start like really going for it and adding exceptions to rules and it's a whole new action yeah yeah yeah um look one of the one of the points um on the renovate repository i say like renovates approach where i tried to describe like what's my kind of like philosophy and the first point is that i believe that everybody can benefit from some level of automation yeah and like if the way renovate works now whatever reason you say that's not really for me well if it truly isn't for you then i kind of think okay but i bet you i tell me what would be for you because like i guarantee you that absolutely no zero automation is is not the best for you i mean like looking up the changelog for each dependency figuring out which file the

source you know the source repository uses for change log like you know and then clicking and then manually looking at the delta yeah instead of just like a pull request it actually captures it yeah that's why i think like everybody a bit of some level automation um it's up to me to try and make sure that like i provide the capabilities that i can do that right so there's some automation built into the to the package managers right so i don't go and look up all the dependencies and see like i run either mix hex dot outdated or yarn outdated or something it will show like the version right the differences and then what i'll do is i'll just like update one run the test suite see what happened maybe while it's running I'll go check their change log.

So like there are some tooling around that, but I'm sure I'm doing way more work than I should be. There's a couple of different points to consider here. Like one, it's the wasted time and potentially time is money. Right. So the wasted time and the money doing something manually that you could potentially automate if you feel comfortable with it, or the extreme flip side is just not doing it at all.

And it's like, I'm just never going to care. I'm just going to keep moving forward. And, you know, in your case, Rhys, you'd mentioned like you'd seen some earlier on in the story, you mentioned how you'd seen some breakage and you're like, well, what's the thing? And it's because something wasn't updated. It's probably because you were not doing it at all.

So you got Jareds who are going to do it manually until something like this comes around. You got people who are extreme and want to automate it, but they want to start extreme with the configuration. They want to highly configure it and then start to maybe loosely unconfigure themselves because they've become more comfortable with it. Then you got those who don't do it at all. But, you know, either way, you got this manual process that essentially wastes time and potentially a lot of money. I mean, can we quantify how much time and money has been wasted doing what is now, you know, automatable, if that's a word? Yeah, well, it's pretty hard to quantify, but there's certainly a lot of different ways

to look at it. That would be an interesting perspective on your site. If, I mean, that's a selling point, because if you could say yeah i'll save your organization this because you've researched you know all the just like nadia did jerry with that hypothetical number way back with open source which isn't a point i'll drive home here but look it up if you want to but the point is is like you can like to some degree get a proxy for it get a proxy for it, get a proxy for it and share that and then quantify it for each individual team or repo or project or company and, and let that be the selling point. We can save you X.

Yeah. By the way, you're right. I mean, this is getting into marketing, but yeah, I just was reading this week and I put the to-do that says like, you know, you should focus on like what it does for people, not like what the features are kind of thing. And I, that's pretty much like what you're saying now. One of my favorite anecdotes, and I've been tempted to like put this on the webpage on the, at least on the renovateapp.com is from Equifax. You guys know about, you know, the, you know, unprecedented leak of personal details. Yes.

So the ex-CEO who retired after it happened, when he testified, I think it was Congress, I forget exactly. But he basically said that, well, this was caused because one individual in our development team did not pay attention to a notice, said we should update our web server version and it's all his fault. Wow. So basically that entire leak of like half of America's social security numbers was blamed on like, there was a single developer who, you know, missed a notice. And like, I mean, that's a, that's a process failure. You can't, you can't say, you know, I'm blaming one guy because he missed an email or something like that. I mean, it's probably more than email, but the reality is that like, if you don't, you know, if you don't have automation, you are going to risk having those types of things happen to you. I mean, you know, you kind of need to keep up with patches or you'll eventually have problems. That's pretty much a solid rule.

This episode is brought to you by our friends at GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end. It supports modern infrastructure with elastic on-demand agents and cloud deployments, and their plug-in ecosystem ensures GoCD will work well in your unique environment. To learn more about GoCD, visit gocd.org slash changelog.

It's free to use and has professional support for enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. So, Reese, with Renovate and really with all dependency management management as you've found, which is why it's so unopinionated. The devil's very much in the details and, uh, you can shoot yourself in the foot, whether you're going the manual route, probably the automated route. Um, if you're going the don't upgrade route, you're definitely shooting yourself in the foot. Um, but a lot of the details have to do with versions themselves, their meaning. What I think is 1.0 is different from what you think is 1.0. I even have a hard time deciding when I depend on a library.

How do I decide, like, how volatile is this? And should I pin it to the patch? Should I allow up to the major? What are your thoughts on that with versioning and what it all means? Yeah, thanks. So, I mean, to paraphrase a saying about democracy, I think SEMVA is the worst form of versioning except for all the others. And that's basically how I look at it because there's lots of challenges. There's lots of things going wrong.

But right now, it's still the way to go. It's not anything to throw out. But the challenge is that I think there can be a mismatch between people's expectations about Semver. Is Semver for the consumer or is it for the producer of the packages? And you used the word volatile, which is actually a really good one to include there because, you know, Semver works on major, minor patch. And in recent years, there's been a movement to sort of clarify that a little as being like breaking feature fix, right? Mapping to the major, minor patch but like to give an example um if i have a javascript library and i do nothing except for deprecate support for node four you know i just say okay i'm not going to support that from

now on is that a major minor or a patch wasn't meant to be a trick question sorry yeah it's a deprecation so i would think that is a patch you're not really doing you're not even doing anything no no it's a it's a major because it is a breaking functionality. No, you're just deprecating it, though. Oh, sorry. We're removing support for it. Oh, okay. It's no longer supported.

I mean, I'm not saying something breaks. Okay. So, yes, if you're removing support, then that's definitely a breaking change. You shouldn't keep, yeah. I thought you were just notifying of an upcoming breaking change. Okay, so you got me. So we saw that a lot. So we saw people remove force.

That's a breaking change. But I mean, if you're not using Node.js 4, what's the volatility of that? It's like zero. I mean, it's not a risk to you. Like none of the actual code change, it was just saying, well, we're not going to keep supporting Node 4

from now on. So if you're using it, don't upgrade to this major version. Now, the next code change, it was just saying, well, we're not going to keep supporting node four from now on. So if you're using it, don't upgrade to this major version. Now, the next thing is, let's say I add a new language support to renovate, but like I put it behind a feature flag, it's isolated into one file and it does nothing unless you actually enable that feature. Okay. Is that, I mean, that's a a minor i've added a feature right but what's the risk of that it's behind a feature flag it does nothing unless it's turned on

i mean the risk to you as an existing user would be like well i don't care i mean like realistically that that's that's a very low risk to you shouldn't that be how every minor is that there's new there's new functionality but there's no risk in upgrading? Ideally, but you can also have features that might touch like 20 files or things like that. So I'm giving you the example of, you know, the simplest of features, but it is a feature. Now I'll give you the final example. Let's say I've got like an edge case, a corner case that's really complicated and really nasty to try and fix. And it takes me like 17 files of touching to add like an extra state across the whole app to track to remove it.

Now, that's considered a fix, but like that one's the highest risk of all of them because I've had to touch 17 files. And I tell you, I've broken things with fixes. That's just how it is. Right. But when I'm trying to work out my versioning, I feel compelled by this concept that I should be following like breaking feature fix. So if I'm truly fixing an edge case, I don't want to call that a feature or people will say, well, who are you trying to kid? That's a bug. But the reality is you as the consumer, forget all of the breaking feature, minor, major. All you're trying to do is, like you said, volatility.

You just care. What's the chance it's going to break me? Yeah, exactly. That's really all you care about. And that's where Semver is kind of not working for us very well. Because as the end user, you just want to know your risk level. And breaking feature fix is a good like general rule but it lets you down in so many times and that's the biggest problem we have with semba

right now is it like we could do a better job somehow and i don't have the you know the implementation idea we could do a better job of the producers being able to communicate risk to the consumers and uh you know the major minor patch by using feature and fix, um, that's, that's not really working very well today. What if we could add, so instead of saying, well, let's throw a Semver out and do something, I know you're not saying that, but like, let's have another standard that's better. Um, what if we added more metrics in addition to Semver? So that still is there to communicate the intentionality of the release right is this a feature uh what was the first one feature something fix major minor breaking

feature fix yeah breaking feature fix that's our intention so we continue to do that we release things according to our intentions but we have tooling around the history and the changes and all that and so maybe in addition to that you have additional metrics like this is a this is a patch according to what it did but it also you know added 17 files and touched 60 on the code base that would give you like the things that you're describing to me yeah because we can automate all that i could just i mean that's what exactly our tooling does already yeah yeah so yeah i mean that's again that. I mean, that's what our tooling does already. Yeah. You can flesh it out.

Yeah. I mean, again, that's why I think, that's why I kind of really firmly think that everybody can need a little bit of automation, even if it's just something that's giving you a report about the estimated stability of this fix. Is it a typo or is it 17 files? Yeah.

Yeah. I like that. Everybody could use a little automation or automatability, 17 files? Yeah. Yeah. I like that. Everybody could use a little automation or automatability. I think that's what you said. I like that. Yeah. Yeah. We'll quote you on that.

Risa Gill is one-liners, man. We'll quote you on that. He's flexible, so he don't have to be. I like also that you talk about the risk management, too, because that's one thing Jared and I talked about in the pre-call was like, you know, it's essentially risk management of like how much, how far you're willing to go, like how configurable you make Renovate for yourself. It's curbing risk management. And the ultimate extreme is this auto-merging feature, which seems scary to me. Can you tell us about that?

Because that's like, you know, going back to our conversation months ago, about looping with uh that's right tim mclaughlin thank you tim where they would close the loop on their uh on their diabetes machines what are those called i'm dropping the ball on it but uh geez i don't remember the ultimate was to close the loop where would actually regulate things for you yes in your body and that was scary auto merging auto merging to me is like okay at least let me look at the thing before it gets merged but uh yeah if it goes well enough tell us about that feature yeah so um so to give you just some perspective so um yeah well auto merges where um you give renovate the permission to merge a new version to your master branch or whatever is your base branch if it passes your test. So you do these for ones that you're confident of.

And for example, like dev dependencies, or if you're updating Jest, you're updating ESLint. I mean, if you've got a new version of ESLint and all the tests pass, I mean, are you really going to inspect anything else? So the rule that we use is like, if you were just going to click that merge button anyway, why don't you save yourself the trouble? And if you want to really get out there, there's the option to do what we call a branch auto merge, where it just creates a branch. And if the tests pass on the branch,

it does a merge onto your master without even raising a pull request. So you reduce your noise. So that's auto merge. And right now, actually, when I look at the statistics, we have about a two to one ratio between manual merge and auto merge. So that's like thousands a week are being auto merged by people. So people are feeling safe enough to be increasing that. Nice. That's an interesting metric too to use for getting

people's buy-in just to say you know what the ratio is between the risky which is auto merge to the you know the jareds that will inspect it manually and or just do it the other way yeah yeah like i try to force myself i just whenever i like merge a pull request i think to myself have i ever like looked into that like have i ever spun up a vm and check that it still works the whole search this that or am i just clicking merge i mean i'm waiting for someone else to find it and if the answer is like i'm not actually spending that time then you know i may as well you know i may as well let the bot be you know negligent not myself if that's the way i'm gonna be especially i

mean if you're branching you're testing and you're merging and then you're merging back to master i mean it's fairly easy it is get you can roll back i mean yeah right i mean so it'd be different if it was like a permanent change you could never you know revert back to but i guess if you're several commits down the line and maybe two deploys later, you know, I don't know, maybe it's too far back to really do that. Maybe it gets more complex infinitely. But for the most part, it is Git, and that's the point of Git is to be able to roll back changes.

So to give you a little insight into the future of Renovate as well is that what I want to do is augment that such that, because now we have some scale. So there's now around 5,000 repositories using Renovate on GitHub alone. that what I want to do is augment that such that, because now we have some scale. So there's now around 5,000 repositories using Renovate on GitHub alone. So that gives me some really good statistics. And what I want to be able to do is allow people

to configure auto merge rules that say, well, if it passes my tests and passes an expected number of everybody else's tests than merger. I mean, for ESLint, you don't really care. But say if it's a new version of the Angular core or the React core, then it would give you the ability to say auto-merge it if it passes 95% of tests. Or in the future, you might say auto-merge it if 30% of everybody else has already merged it.

To allow people to have these kind of metrics that give you more like feeling of surety or safety um i think that that's sort of uh yeah that's part of the future of the automation that's really interesting actually i mean you're using the wisdom of the crowd and like past performance to say 90 of people you know auto merge this yeah yeah. Where would that UI surface at? Well, it would basically still be configuration. I mean, that you can figure out thresholds. That's my intention.

Where would you communicate that information, like the wisdom of the crowd? Where would that be communicated? Oh, in the pull request, in the pull request. Okay. And I saw a nice trick that TJ Hol tj uh hello white chuck uses for something he does github polls and he actually embeds svg files you know as an image um into github issues and if you're using his github polls and that is feeding back to a lambda function that polls

dynamo db and so basically it gives you like a dynamically updating issue comment where you don't have to rely on a bot to be continually refreshing you and saying, okay, now 843 people tested. It's actually an image and the image every time you refresh pulls the latest number from the backend.

That is super cool. Can you get us a link of that in action so we can include it in the show notes and check it out ourselves because that's a great idea yeah sure yeah it's it's a really it's a really innovative idea i'm actually considering you know making half of the pull request being essentially like a text svg so that you know you can kind of be able to dynamically update the information in a pull request description um you know graphs and so on without actually needing to continue to be like hitting the github api to be you know annoying people by popping it into their uh their news feed whatever i think it's interesting too how uh

hackable svgs are yeah i've seen some really interesting stuff like this included as well as i think the way code sponsor did their thing with thing with SVGs, that was really inventive. No one would ever have thought of that, and Eric did, and that was really cool. Yeah. Sorry, if I can just add one more thing. I think one of the challenges with the updates, and this is the hesitance that everybody has,

or sometimes it's the fatigue they have after the initial positivity, is that the updates become a bit like a fire hose. I think that automation 1.0 is sort of like, whenever there there's an update here it is it's in your face but i've continually worked to try to have ways to reduce that noise and so all emerging is really one of those because like if you can auto merge it without you needing to do something then that's one but other ways include include grouping and scheduling. So for example, you can say, don't submit any new pull requests during our working hours, which also has a benefit, meaning that your CI machines can not be holding you up with application code during working hours as well. So grouping, scheduling, auto-merging,

these are all ways to try to kind of reduce that noise and I think reduce people's frustration that you don't have to have the fire hose. If somebody says to you, are you interested in getting healthy? And you say, yeah. And then they say, okay, well, the only solution is 5 a.m. bootcamp every day.

And you're like, ah, that's a little bit extreme. And so if you say to people, are you interested in keeping updated? And they say, yeah. And then you say, okay, so here's what's going to happen. I'm going to hit you with a pull request every single hour of the day. You know, then that's like the equivalent

of this 5 a.m. bootcamp. So some people actually, some people want it. Some people want that. But by having that flexible configuration, they can just be just be like you know what let's make dev dependencies weekly let's make a monthly or something you know they have that flexibility to be able to just schedule things down i want the version that's likened to the machine that you walk into and it has a nice like rubber uh belt that just jiggles you know those things they just jiggle the fat right off yeah yeah yeah that's not real jared give me that version of automated dependencies

just jiggle the fat right off my app will you oh my gosh i thought you were going there but you didn't that's a good one i like that my my app adam yes your app your app well you know reese i think maybe i'm jumping the gun here if we have more to talk about in this subject we can but i think you know this is during this conversation i've been revealed through discussion and your excitement for this that there's a serious business here for you and you potentially accidentally stumbled on an open source itch that could very likely be a business, but that's kind of scary

because you're going to build this business potentially around somebody else's product and kind of volatile ecosystems. And Jared asking you for Elixir support. What do you think about that? Yeah, yeah. How much money do I have is the question. It's exciting as well as a little bit you know stressful um because you know the concept of like monetizing open source can be a hot topic at the best of times um but as i mentioned earlier

the real the sort of uh the epiphany to me was when somebody said like this is exactly what i want but i won't run it you know if you run it i would pay you and then i like, this is exactly what I want, but I won't run it. You know, if you run it, I would pay you. And then I realized, okay, this is why I'm going to work on this because it's fun. But I think it, it tends itself towards being a service. And it also tends itself as we just talked about towards having a network effect where the more people using it, the better it can be for everybody. And that's essentially been the motivation. But you know, until now I've been running it as a free app. It currently supports around like 500 installs and about 5,000 projects on GitHub, which is quite a lot of scale. And at least, at least to me. But yeah, I, yeah, I think so. I'm pretty, I'm pretty chuffed with it.

Like, I, you know, I still remember when you, when you, when you, when each day you like, you see it go from like 25 to 26 or something like that, you know? Um, so yeah, it's been, it's been going very well, but, um. Plus with some big names using that, you got Algolia, Google Chrome labs, Mozilla, you mentioned Angular. So you have like some very significant projects that are dependent on this. Yeah, yeah. It's super exciting whenever I see big names on the installs.

It's very flattering almost. And yeah, it's really nice. How do you track the installs? Is it currently a service where these are their own installed versions of of versions of it or is it oh yeah right so these are actually only the people who have installed renovate on public repositories on github i i have a uh not that probably anybody's read it but i have a point in my terms and conditions that say if you install renovate on a public repository we have the right to use your logo and your, you know, your name without further permission. But, you know, if you hate that, you can tell us and I'll remove it within seven days. So, I put that because, you

know, it's better to like, you know, beg forgiveness than ask permission. So, that list of customers is actually, or I should say users, no one one's paying that list of users is um that's only ones that have installed it publicly i actually have this how would i say there's other like uh there's other unicorns will say that it like you know running it privately that i'm aware of but i you know i don't put their logo up because i haven't asked them and you know it's self-hosted so uh right that's their own business so I guess the way then to get this into an open source application is to go to github.com slash apps slash renovate, which is linked to from your readme.

And that's the way you, there's a big green button up in the top right. You click install, and then you choose a repository to install it into. Is that the process? Yeah, that's right. I mean, GitHub gives you the option of either installing it on all repositories

or selectively picking them one by one. That interface is not particularly friendly. So a lot of people end up, you know, ticking all out of convenience. But yeah, basically you install it, you pick which repositories you want it to run on. And the next thing that happens is it gives you like an onboarding pull request. And that one does nothing except say, okay, here's our recommended default config. And if you use this, then here's what will happen next. You know, you'll expect like seven pull requests

and here's what they'll look like. It gives people the ability to then edit that pull request, you know, edit the config, you know, to add these exceptions, these configurations and run immediately and like give you an updated, you know, prediction. So like give you an updated you know prediction so like if you started with here's your seven pull requests and then someone adds a preset that says group all together then you know it'll hopefully within like a minute or something will update to

then say you'll have one pull request called update all packages you know so it's like a sort of like an interactive onboarding where nothing happens until you then click the button to merge. What happens, I guess the first step is to either choose all or choose the repo, then you have to add a config to your repo. Is that right? So that's actually a file that lives in your repo? Yeah, that's right. It is actually possible to run it without a config file. So if you actually just close that onboarding pull request, that's good enough to get it to start. I mean, because you've already installed it on the repo, so clearly you want it. Right.

So it is possible to do without a config file. What that means is you just get the application defaults. And those are the ones which I'll call fairly unopinionated. Over time, over major releases, I've often changed for um for configuration to make them sort of like i'm trying to describe it less uh action less action i'm missing the word but you know less less volatile like it by it does less by default as each one goes on meaning that people kind of opt in to things so um you know for example in the very earliest releases it said it was a bit more opinionated and said let's pin everything let's do this whereas, you know, for example, in the very earliest releases, it said it was a bit more opinionated and said, let's pin everything, let's do this. Whereas now, you know, you kind of have to like opt into that if that's what you wish. I mean, it'll attempt to auto detect.

I guess this couples with potentially a new announcement. I think this is fairly new for you too, which is, you know, inclusion in GitHub's marketplace. Can you, do you want to speak about that? Can you talk about those details? How does that reflect back on the, the two different processes to install it, so to speak? Yeah. So, um, you know, to be, to be a part of GitHub's marketplace, you don't have to actually be like a GitHub app, you know, you could be like an OAuth app or things like that so it's the two are very closely related but not like tied to the hip um so you know if you go and install the app um without going through the marketplace it will install and run and give you the onboarding and very soon not today but very soon it'll start giving people polite reminders that it is necessary to select a

plan um that's sorry that's only if they're actually on a private repository i should add It'll start giving people polite reminders that it is necessary to select a plan. Sorry, that's only if they're actually on a private repository, I should add. But so soon it'll start prompting people to say like, you know, Renovate is available on the GitHub marketplace. Please select a plan. And then eventually run out of patience and say, you know, well, you've got like seven days left or something like that. So that's my planned approach to how to kind of nudge people onto the plans if their use is in private repositories.

This is only private repos, not open source repos. Correct. So that's a clear distinction there. Exactly. I mean, and that's a pretty, you know, standard GitHub business, you know, GitHub add-on business model is like open source is always free. Yeah. Sometimes people have to have like reasonable use limits, but, you know, it's been going pretty well so far. You know, like I said, it's like about 5,000 projects and that's, that's been fairly manageable. So I think that we can continue managing

with, you know, open source being free indefinitely. Does it make sense to mention this? I don't know if this is like brand new or how long this will be real, but it seems like you maybe even have an opening special for personal plans. It's like a dollar a month. Is that legit forever? Yeah. Yeah. So that's a, yeah. Yeah. So, um, you know, it's, it's challenging when you go from like a free offering to saying to people, you know, can you pay me? Yeah, exactly. Exactly. And, uh, I thought the one of the nicest ways i could do that is in a kind of almost like a kickstarter like approach where it's like you know your earliest backers you know get the best price and uh so that's why it's it's opened

with this like opening special where um it's a price that will be as you were sort of asking it will be grandfathered in because that's actually github's policy github's policy is like if you sell someone a plan at price x then you keep delivering it basically indefinitely until that person cancels it yeah and that works really well because that what that is allowing me to do is to offer this kind of opening special prices and i can uh starting tomorrow i'll be um pointing some of the people i know been using it for a long time and saying hey like sign up with this you'll get that price forever and thank you for being you know helping promote renovate um and i thought that you know having this kind of carrot approach to pricing rather than the stick approach which says like pay up now or else you've had long enough i thought that

might be a nice way of kind of transitioning where you offer the existing users a price that they know is, is really, really fair. A dollar a month is really fair. Yeah. I mean, that's the, that's the, that's the, the personal plan. That's for the personal accounts. And like, I remember I was, I would have been willing to pay like five, 10 minimum kind of thing. So I'm like, I think a dollar is good. And people can sign up and lock that in. And another reason for charging a dollar and not saying free is that I know that like, if I sign up to a service and they've got like a free plan that suits me, I always have a concern that like one day they're going to say, you know what, we can't keep offering that. And it's now like 35 bucks a month or something like that. Like

they'll go from free to a price that you just, is just not valuable to you. It doesn't match with the value. So I personally prefer to have something where I can be like, okay, I'm a paying customer of them and I get this price. And I know that, well, they'll hopefully, you know, there's a good chance that they'll grandfather that in. So that's another part of my line of thinking is that not so much just like, oh, I worry whether they'll be sustainable because, you know, a dollar a month is not really going to help with that. But it's more like, oh, but I know I've got a price locked in and that I like. So this is the, you know, to, to share with the listening audience, like where Renovate is going, where you have dreams about going and, you know, considering now you're in marketplace, it's becoming, you know, a paid for product that can sustain itself and grow. Like what are some

plans you're, what's on the horizon for you what's next yeah so well i obviously hope that there will be a good um you know take up from the marketplace the marketplace itself can be very good um exposure you know people finding it via the marketplace that wouldn't have otherwise heard about it you know like you guys haven't heard about it for example right we should hear about it right jared i mean yeah i'm glad nicholas told us because i mean without nicholas we'd be in the dark still yet that's right we need this we need nicholas yeah so look my my long term uh longish term i should say plan for renovate is um fundamentally it remains an open source first tool with a very good core that you can run yourself yeah if that's what you want to do um a plan and hope that a lot of people

prefer to have the app like i'm only aware of one um company who is running their own app you know their own you know bot whatever you want to call it um on like github.com you know meaning that most people it is free, but I still think that the convenience of having someone else watch it, monitor it, alarm it, and things like that, and save the logs, I think that'll benefit. I also plan to add some things to the app that are not really easy to do in an open source command line tool, and that's things like a web interface to view a history like were there any like failed attempts yesterday or what was the log

from you know three hours ago when it created this pull request that looks a little bit weird to me you know things like that um and that's only possible when you're like actually like you know keeping state storing logs providing a you know a web interface and so on. So I think that the tool can remain a very powerful open source tool, while the app can provide what you expect from an app when things are as a service rather than just simply software. Very cool. Well, I know I'm excited. I think this was an eye-opening topic for me because automating something can be pretty scary. Like Jared said, he hasn't found a reasonable tool to do it for ourselves.

So we've been basically wasting time and money. And I'd be excited to have Jared have more of his time back so we can make some more money or find just different fun things to do. And it's just such a shame that there's so many, like you just repeat that 50,000 times, many people wasting their time and money updating dependencies that Renovate could save so much out there and automate it so much too. Yeah. My goal is that there's always some setting

or some level that works for everybody. So if anybody thinks it's not right for them, I mean, I assume there must be something that is right. And well, if it just did this, cause we've got some ideas and if I find that people like them, then I think there's a few other like approaches and models that could be used. Yeah. Well, Rhys, thank you so much for sharing your story and your passion for this project and, you know, your commitment to open source and just, you know, sharing the details around a sometimes tough subject, you know, of open source to business and how you balance all that. So I know it's tough, but thank you so much for sharing your time today and all your ideas with the show.

Yeah, thank you very much. It's been a real pleasure and thanks for your time as well. Alright, that's it for this episode of The Change Log. If you enjoyed this show, do us a favor, go into Apple Podcasts, go into Overcast, go into whatever app you're using, favorite it, like it, share it, tweet it, whatever. Just get it out there, share it

with a friend, help us grow the show, and thank you to our sponsors, tweet it, whatever. Just get it out there. Share it with a friend. Help us grow the show. And thank you to our sponsors, Linode, Glyphie, and GoCD. Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. Rollbar takes care of our error monitoring. Check them out at rollbar.com. And we host everything we do on Linode cloud servers. Head to linode.com slash changelog.

Check them out. Support this show. The changelog is hosted by myself, Adam Stachowiak, and Jared Santo. This edit was done by Jonathan Youngblood. Music is by Breakmaster Cylinder. And you can find more shows just like this at changelog.com or on Overcast or on Apple Podcast or wherever you subscribe to podcasts. Go there. Search for the chang Change Log, you will find us.

We'll see you next week. Thank you.