# Looking back at my first year as the Renovate Project Lead > Source: > Published: 2026-09-21 15:58:39+00:00 A year ago on Thursday, I logged on for my first day [joining Mend to work on Renovate full-time](https://www.jvt.me/posts/2025/08/27/joining-mend/). Similar to [what I did after my first 100 days](https://www.jvt.me/posts/2026/01/21/renovate-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](https://www.jvt.me/posts/2022/02/07/blog-publish-date/)). 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"](https://github.com/renovatebot/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. 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: Over the last year, we've also seen some changes in how folks interact with [Renovate](https://docs.renovatebot.com/). 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](https://www.jvt.me/posts/2024/04/12/use-renovate/). 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". Speaking of AI agents, we've also made several improvements over the last year to try and make it easier for agents to contribute: `AGENTS.md`` pnpm check` command that runs all CI-like checks, locally 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. 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. As noted above, [because we use GitHub Discussions for triage](https://www.jvt.me/posts/2026/01/07/renovate-why-discussions/), 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](https://github.blog/changelog/2026-08-03-triage-role-can-bypass-issue-creation-restrictions/) to the [original release in June](https://github.blog/changelog/2026-06-29-restrict-issue-creation-to-collaborators-only/)), 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: 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. 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](https://github.com/renovatebot/renovate/discussions/44952)) 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: 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! I'm very happy with some of the key things I've led on: `minimumReleaseAge`, before the rest of the ecosystem `pnpm`` config:best-practices` users, we saw more `vulnerabilityAlerts` through Open Source Vulnerabilities (OSV), but being able to block dependency updates to a known malicious version is really important`constraintsFiltering=strict`` go` directive unnecessarily, you can now use `apk add` extraction in `Dockerfile` s`@renovate-bot` user on GitHub.com`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 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 😹 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. 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"). 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:`fix`` docs``chore`` feat``test`` ci``refactor` Across a mix of files and parts of the project: Over the year, including i.e. linting fixes, I've touched: 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](https://github.blog/changelog/2026-03-12-issue-fields-structured-issue-metadata-is-in-public-preview/), 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](https://github.com/orgs/community/discussions/190548), we unfortunately can't take advantage of it for some of our fields. 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](https://www.jvt.me/posts/2026/06/18/ai-adoption-commits/) 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](https://www.jvt.me/posts/2026/05/26/ai-craft/) and [the worries about how Open Source survives](https://www.jvt.me/posts/2025/11/17/llm-oss/). As I noted in [*How much AI can a maintainer get away with using without losing their humanity?*](https://www.jvt.me/posts/2026/08/02/ai-maintainer/), 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](https://bcantrill.dtrace.org/2026/09/05/the-revolt-of-the-reader/) - and my replies to humans, but worrying that the increase in workload will lead to compromises needing to be made. 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. 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](https://www.jvt.me/posts/2026/01/21/renovate-100-days/#shipping-despite-a-tiny-team) 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!