Looking back at my first year as the Renovate Project Lead · Jamie Tanna | Software Engineer

A year ago on Thursday, I logged on for my first day joining Mend to work on Renovate full-time.

Similar to what I did after my first 100 days, I thought now would be a good time to recap how this last year has gone. This is also a fun way of doing a public mini performance review!

I'd planned to try and land this on my actual anniversary, but I know this is going to be a busy week - as they all seem to be, nowadays - so thought I'd pre-publish it (and because I don't like waiting to hit publish).

Plus, publishing this now means that I don't have to keep re-writing this as the stats change!

Note that below includes analysis from Claude Opus 5, based on data from our "maintainer dashboard" and commits on main over the last year. I've done some double-checking of some of these stats. Claude Opus 5 has created each of the charts on this page.

I've got a really great team behind me on the project, so I'm not attempting to completely claim credit for everything - thanks for all you do!

Changes in the industry

Before I get into how things have gone with the Renovate project, I wanted to look at the wider industry's context.

In the last year, we've seen:

• a significant rise in supply chain attacks, where malicious package releases are being used to compromise others and continue propagation as a worm (such as the "Shai Hulud"/"Sha1 Hulud"), or purely used to target specific users and organisations
• an overwhelming increase of contributions across the Open Source ecosystem using AI, swamping and burning out maintainers faster than ever
• a similar increase in reports of privately reported security vulnerabilities in code, with a high percentage of these being bogus
• (as far as I can tell) higher adoption in dependency update tools, while also seeing calls to disable (your dependency update tools) or to prune the dependencies you own
  • I have a lot of thoughts on this, and had hoped to do a conference talk about this, but the talk proposal wasn't compelling enough to get past a couple of CFPs - I'm still planning on writing it up as a form of blog post!
• increased AI usage has also led to service providers, like GitHub, seeing increased instability, outages, as well as the general feeling that products themselves are feeling a little bit lower in quality

Changes in the project

Over the last year, we've also seen some changes in how folks interact with Renovate.

Firstly, it appears that there is an increase in adoption of Renovate, which is great! I'm especially biased right now, but I still think that Renovate is the best tool for dependency updates out there.

Reduction in "I need help"

Secondly, we've seen an interesting trend in how folks interact with the project. In prior years, we would have a fair few "Request Help" discussions - often "how do I get Renovate to do ..." or "I've configured ..., but it's not working how I expect it to" - which are down 43% this last year:

My instinct is that with the rise of LLM usage, more folks are asking their LLMs to answer questions like this, instead of coming to us. I can't fault folks for using a tool with immediate responses - even if it's likely got outdated knowledge, or the chance of suggesting solutions we wouldn't recommend any more - as it gives them that faster feedback so they can get unblocked.

I do think this is a shame, however, because previously we could use the contents of "Request Help"s as a feedback loop for what issues folks are seeing most commonly, and what areas we may need to improve, but now it's hidden inside a user's chat windows. We've been quite fortunate to have this as a signal in the past, and now we're going to need to work a bit harder to see how we can improve this going forwards.

I don't have any numbers to hand on this, but when we do receive "Request Help"s, a lot of the time, they include a "I got an agent to trace through the code and it looks like this line needs a fix", rather than a real case of "I honestly don't know how to do this, please help".

Improving life for agents (and humans)

Speaking of AI agents, we've also made several improvements over the last year to try and make it easier for agents to contribute:

• introducing an AGENTS.md
• introducing a pnpm check command that runs all CI-like checks, locally
• making sure that agents use pnpm check as a stop hook (and a few other options to tune tool usage)
• nudging agents to fill in the PR template better
• nudging agents to not raise Issues, because we use GitHub Discussions
• adding linting rules that avoid the same comments coming up in code review

Sergei and Sebastian have been doing some really great work on this - as well as a few other folks - and it's made a massive difference for my own usage of LLMs with the codebase, and getting even better code out the other end.

That being said, prior to these changes were we seeing - for the most part - fairly technically correct code, but it wouldn't necessarily fit in the areas that it was added for, or wouldn't completely fit our code style, but would handle a lot of file-directory architecture choices.

An increase in contribution

It's pretty great that work we've done for years to keep the codebase well-defined has made it easier for humans and LLMs both to contribute, and we can see this in the data of contributions.

Prior to September last year, every 6-month block of the year for the last 18 months, we saw ~700 commits every 6 months. In the first half of 2026, we saw that number increase to 1035 (48% increase), which is a whopping increase for a 0% increase in maintainers on the project 🤓

We can see this in how the external contributions have increased over the months:

Similarly, we're receiving increased numbers of PRs, but are still continuing to merge them, albeit it's taking a bit longer:

Considering we're seeing an increase in new contributors, these are folks who aren't necessarily going to know the practices of the project, so it may take more time to iterate through changes:

Please stop raising Issues

As noted above, because we use GitHub Discussions for triage, there shouldn't be any Issues being created by folks outside of the project, but that doesn't stop them right? Although we've done a few things to try and stop users doing this - like a big glaring warning, and auto-closing them if they're not raised by a collaborator on the project - there were still some cases we'd get repeat offenders, especially as GitHub still didn't block it via the API or in specific UI widgets.

I'd often give a temporary block to "nudge" the user that their behaviour wasn't correct, but a lot of the times, these were created by an AI Agent, not even a human who was being a bit of a dick.

Thankfully by August (after a needed follow-up fix to the original release in June), it was possible to completely close out Issue creation from non-collaborators, which also means there's one fewer place I need to keep on top of.

E_TOO_MANY_RELEASES

Another big issue we've hit this year is that when publishing new npm packages, we hit:

npm error code E406
npm error 406 Not Acceptable - PUT https://registry.npmjs.org/renovate - Package publish failed.
npm error Your package metadata is too large (100.01 MB > 100 MB).

This is quite a novel error in the npm ecosystem, as there aren't that many projects that release quite so much that they hit hard limits on the registry size 😅

This happened twice this year:

• In my first full week but was resolved within ~2 days of downtime
• In April, resolved after a month of no new npm releases

During this window, we were still able to publish Docker images, but not having the npm package led to a lot of knock-on effects that weren't ideal. We've performed some significant cleanup at this point, and aren't yet planning on reducing our release cadence, due to the utility it provides to us as a project.

Continuing to ship 🚀

Speaking of our frequent release cadence, over this year, we shipped:

(Of which one major version wasn't intentional)

These changes also led to a number of changes across Renovate's excellent support of things it can update:

It's been great to see how much stuff we've got done considering the small team, and I'm always incredibly appreciative of maintainers Sebastian and Michael, who also do a tonne to keep this project going!

My key achievements

I'm very happy with some of the key things I've led on:

• Doubling down on minimumReleaseAge, before the rest of the ecosystem
  • Renovate's had the ability to set minimumReleaseAge (also referred to as a "cooldown") since 2019 - we've seen a good adoption of the feature over the years, but an noteworthy increase in the last couple of years
  • Foreseeing this as something we needed to be more opinionated about, I decided to set things in motion before I'd even joined officially to provide better defaults to protect our users
  • As I'd written on the Mend blog, this was an important change we made to secure more folks where possible, and would be the start of further work to improve minimumReleaseAge, and generally widening our support for this, as well as where we would set it "on-by-default"
  • This also involved a tonne of work from me and Rahul, where we worked towards my vision of what would be a good point for this to be on-by-default, and writing a little more in-depth documentation for a key feature than we may have in the past
  • It was nice to see our friends at Dependabot introduce cooldown functionality last July, and then, based on some feedback I'd shared with the folks at GitHub earlier this year, they enabled cooldowns by default this July, as well as many of the package managers now adopting it, led by pnpm
  • The wider ecosystem agreed with my thinking, because not long after we'd enabled it for config:best-practices users, we saw more posts from folks like William Woodruff about why cooldowns are important, and prompted by pnpm adding minimumReleaseAge functionality in early September
• Malicious package prevention
  • we're still working through making it available for users who aren't using vulnerabilityAlerts through Open Source Vulnerabilities (OSV), but being able to block dependency updates to a known malicious version is really important
• Security hardening
  • As an ongoing effort, helped and accelerated by AI tools, we're doing a lot of work to close out potential gaps in things that have been around for a bit
• constraintsFiltering=strict for Go
  • Something that's bugged me for a while as an author of Go libraries/tools that doesn't want to update the go directive unnecessarily, you can now use constraintsFiltering=strict to only receive PRs for updates that don't bump your go directive
• Increased OpenTelemetry instrumentation
  • The telemetry that Sebastian had originally added into the project was a great start, but I had a bit more time to spend on improving how our instrumentation works
  • We've now got strong coverage of some of the key operations in Renovate so far, and it's currently being used to help improve the performance of Renovate when it runs against monorepos, which wouldn't be possible purely from our logs themselves
• apk add extraction in Dockerfiles
• Visualising some - in my opinion - interesting stats about how a given release train ran
  • For instance, for Renovate 42 and for Renovate 43
• Being competitive with our features
  • For instance, within hours of being made aware of an issue with how both Renovate and Dependabot handled GitHub Actions' tagging formats, I'd started working on fixing this - as it would block users from migrating from a mutable/"floating" tag to immutable tags, which are more secure, while Dependabot are still yet to implement this
    • Albeit it was a little more difficult than I'd originally thought - having slightly broken things a couple of times while I iterated on it 🫣
  • Or supporting the GitHub Actions' lockfile format, before Dependabot did
• Providing a bit more insight into the project, from the outside
  • This blog post, and after my first 100 days
  • Writing a bit more in-depth about things like why we use Discussions and how we're using the "maintainer dashboard" to do better things
  • Adding some different means to provide more focussed feedback to us
  • Doing some more project management-y things (which were being done at some level before) like adding an epic tracking all potential deprecations we're going to remove in a future version, and pre-announcing new releases, with a new "Maintainer announcements" Discussion category, so folks can follow via RSS
  • Changes we're making to Mend-hosted infrastructure, such as when I decided we would enable "vigilant mode" on the @renovate-bot user on GitHub.com
  • Being a bit more clear that i.e. we're a small team, or that we're taking things a bit easier with summer holidays or at the end of the calendar year
  • Documenting areas that customers are interested in being merged/fixed or explicit requests they have, to help improve visibility + priority calls
• Some key improvements to our documentation
  • I've worked to make sure our documentation is more complete, for instance autogenerating key pieces of information, such as "what are the given depTypes this manager supports", or "what tools can I tell Renovate to install i.e. with constraints?", as well as working to make our JSON Schema as representative as possible
  • Adding more in-depth documentation like minimumReleaseAge or how environment variables are handled

There's actually a load of other things that I'm happy we've got done over this year, but this section is getting very long 😹

Title change

When I officially joined Mend, I had a bit of a mouthful of a job title, which also didn't really reflect the work and impact I was having when folks inside and outside of Mend read it.

In May, we changed my title to make the scope of the work and impact I was having official:

-Senior Developer and Open Source project maintainer
+Renovate Project Lead

This is probably a little bit of a vanity thing, but it made sure that it was clear that my role is leading the Renovate project, shaping direction of where both the Open Source project and our product offerings go.

Some personal stats

Let's look at some of how I spent my year.

I've intentionally not included code review, which has been a chunk of my time, but not as significantly as it has been for Michael.

For instance, let's refresh ourselves on how many external PRs we've been seeing recently:

If we look at human (or agent) commits, we can see that I've started taking up more time in the overall percentage of project's commits.

However, this is then much more drastic if you look at it based on number of commits per person:

These commits are a mix of things:

Across a mix of files and parts of the project:

These changes have been across Mend customers' requests, reports of bugs from the community, features I want to deliver as well as a mix of other backlogs that we have, and I'm working to make more explicit.

With the small team we have, we're trying to review as best as we can while this number keeps on growing. And it's clear to see that the more changes I'm authoring, there is a smaller percentage of community PRs that get in, because we have limited review time - something we're hoping to try and improve where we can.

We can see that as well as committing a lot of things, I also am largely present in the GitHub Discussions:

An interesting view that Claude Opus 5 noted was that - since I've joined - I've done a bad job with keeping on top of labelling our Issues appropriately 😅

This isn't ideal, and is hopefully something we can fix! This is largely because the intake form for Issues would guide you towards creating the Issue with the right fields, but as GitHub (maybe late last year?) allowed maintainers to use free-form inputs, I lazily started using that.

I'd hoped that with the new structured Issue metadata, we'd be able to migrate to them for a number of the "mandatory" labels we used, but unfortunately due to platform limitations of 100 items per field, we unfortunately can't take advantage of it for some of our fields.

My own AI increase

As much as I continue to say I'm an AI skeptic, you may not believe me when you look at how many of my commits are now including AI-generate content in them:

I've definitely been using AI a whole lot more this last year. Some of it is absolutely to "keep up" - with the increased load on maintainers, if there are metrics needing to be hit or even for fear of "being left behind".

But it's also disingenuous to not also say that I am enjoying having AI agents available to me, that I can use to parallelise tasks while working on other things (for instance, writing this blog post 😉), while also lamenting whether "craft" can exist and the worries about how Open Source survives.

As I noted in How much AI can a maintainer get away with using without losing their humanity?, I'm not at the point - and I don't think I really want to be - of replying to other human people with AI. I'm still thinking fairly critically, doing my own writing of my blog - also as Bryan Cantril recommends - and my replies to humans, but worrying that the increase in workload will lead to compromises needing to be made.

Mend products

I won't go into this in the same level of detail here, but there are a number of key changes that I've done/helped shape this year that I'm very happy about, and I know a number of our customers have been very appreciative of!

I'll also note that I've ended up shipping ~102 Renovate upgrades to Mend-hosted apps, roughly up ~50% compared to the previous year.

Performance review: happy?

I'm pretty happy with how the last year has gone.

There are of course some situations and conversations we could've handled better, there are areas that I wish we'd tested a little better before they got merged, but given the tiny core team we have we've done very well generally with the increase in workload.

But I'm also big-headed enough to say that I think I'm absolutely the right person to have picked up the mantle with Rhys leaving, and I'm very happy I did. It would have been interesting to see how someone else would've responded to a number of the changes over this last year, but I guess we don't get to see that.

Looking forward to seeing how things go this coming year!