jvt.me
Looking back at my first year as the Renovate Project Lead
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.
## 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:
A breakdown of how the trend of Discussions being created against the project has changed since September 2024.
In 2024, we saw ~180/month "Request Help"s and ~50/month "Suggest an Idea"s being raised.
By September 2025, "Request Help"s were down to ~140/month and "Suggest an Idea"s down to ~25/month.
Through to the end of August 2026, the "Request Help"s are down to ~80/month and "Suggest an Idea"s up to ~30/month.
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:
A breakdown of how the trend of PRs being created against the project has changed since September 2024.
Between September 2024 and March 2026, we saw fairly consistent number of external PRs between 47 and 79 PRs/month, from 35-58 distinct authors.
In March 2025, we see this increase to 96 PRs from 677 distinct authors, up to a peak of 124 PRs from 86 distinct authors.
Similarly, we're receiving increased numbers of PRs, but are still continuing to merge them, albeit it's taking a bit longer:
The breakdown of how many PRs are merged/closed without merge/not-yet-merged-or-closed, looking at 6 month periods (as a "cohort").
We see a fairly stable percentage of PRs closed without merge (17% to 23%) over the cohorts.
In 2024-H1, we see 83% of the 336 PRs are merged.
In 2024-H2, we see 79% of the 390 PRs are merged.
In 2025-H1, we see 76% of the 393 PRs are merged, and 1.3% still needing a decision.
In 2025-H2, we see 69% of the 375 PRs are merged, and 8% still needing a decision.
In 2026-H1, we see 61% of the 494 PRs are merged, and 20% still needing a decision.
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:
The breakdown of the number of new contributors to the project, looking at 6 month periods, and based off merged contributions.
In 2024-H1, there were 183 new contributors.
In 2024-H2, there were 193 new contributors.
In 2025-H1, there were 179 new contributors.
In 2025-H2, there were 171 new contributors.
In 2026-H1, there were 205 new contributors.
### _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:
A count of the releases that Renovate shipped over the last year, showing (at time of data collection) 1813 releases, of which 1276 are patch releases, 533 are minor releases and 3 major releases.
(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:
A timeline of changes to the modules that Renovate supports, showing that in the last year:
* Managers grew from 110 to 118
* Datasources grew from 76 to 82
* Versioning schemes grew from 46 to 54
* We added 1 new Platform
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 `tool`s 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:
The breakdown of how many PRs are merged/closed without merge/not-yet-merged-or-closed, looking at 6 month periods (as a "cohort").
We see a fairly stable percentage of PRs closed without merge (17% to 23%) over the cohorts.
In 2024-H1, we see 83% of the 336 PRs are merged. In 2024-H2, we see 79% of the 390 PRs are merged. In 2025-H1, we see 76% of the 393 PRs are merged, and 1.3% still needing a decision. In 2025-H2, we see 69% of the 376 PRs are merged, and 8% still needing a decision. In 2026-H1, we see 61% of the 500 PRs are merged, and 20% still needing a decision.
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.
The breakdown of how many human commits there are in the last year, looking at 6 month periods, between "everyone else" and me.
In 2024-H1 through 2025-H1 I have 0 commits, so "everyone else" is doing very well.
In 2025-H2, I have ~180 commits compared to ~510 from "everyone else".
In 2026-H1 I have ~410 commits compared to ~620 from "everyone else".
In 2026-H2 (so far) I have ~270 commits compared to ~370 from "everyone else".
However, this is then much more drastic if you look at it based on number of commits per person:
The breakdown of how many human commits there are in the last year, broken down by GitHub username, showing the top 10 usernames.
At the top, `@jamietanna` (the author of this post) has 875 commits.
The next best, in order, are the other two Renovate maintainers with `@viceice` at 186 and `@secustor` with 137 commits.
7 of the top 10 contributors are collaborators on the project, and 2 of them are for the same human, under two different usernames.
The 10th place has 12 commits in the last year.
These commits are a mix of things:
Based on my commit messages, there were:
* 221 `fix`
* 155 `docs`
* 146 `chore`
* 129 `feat`
* 78 `test`
* 75 `ci`
* 65 `refactor`
* 7 others
Across a mix of files and parts of the project:
Over the year, including i.e. linting fixes, I've touched:
* 11/11 of the Platforms
* 73/118 of the Managers
* 26/82 of the Datasources
* 10/54 of the Versioning schemes
Note that this isn't the entirety of Renovate, and I've purposefully omitted the other areas for brevity.
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:
Before I joined the project, I naturally didn't spend much of my time regularly interacting with the the GitHub Discussions, unless I had an issue or feature request, so up until September 2025, I effectively had 0 engagement.
However, from September 2025, the amount of discussion comments from others decreased as I did more, as well as the general decline of folks using GitHub Discussions to ask questions.
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 😅
Before I joined, our labelling of Issues on the repo was at ~95%-98% over time.
Since I've joined, we're down to ~45% of newly created Issues with any `priority` label, and ~75% with any labels at all.
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:
A stacked bar chart showing my commits (on `main`) per month from October 2025 to September 2026. From October 2025 to January 2026, the AI usage was between 2% and 7%. In February this increases to ~29%, and in August and September 2025 (so far), we're seeing roughly 88% AI usage.
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!
