Roughly 100 days ago, I joined Mend to work on the Renovate project as a maintainer and community manager. In a vague homage to the style of politics' "first hundred days", I'll talk about some things that have happened since I've joined the project, and some of the interesting (and mundane) things I've learned since joining the project.

This was originally going to be a talk presented at FOSDEM 2026, but there was a lot of strong competition to the half-day Package Management track so I didn't get through to speaking.

Instead of losing out on the opportunity to share this, I thought I'd write it up as a blog post instead, as well as it being quite a nice opportunity to reflect back on the last few months.

Note that this post is focussing on the Mend Renovate CLI, the Open Source project that is commonly referred to as Renovate, and I won't be going into anything internal to Mend.

What's Renovate?

First, before we dig into the learnings I've had, let's first explore what Renovate is. It's likely you have some inkling if you're reading this, but it's worth making sure you have the context before reading further.

There's a good primer on what Renovate is on a recent post of mine, but a good TL;DR is that Renovate is an Open Source project (AGPL-3.0-only) owned by Mend, which boasts the best support + extensibility in the ecosystem for dependency updates, and we had over 300 human contributors and 1599 releases last year alone.

Since starting the project in 2017, we've gone through a few versions of how we operate the project.

Right now, we have three classes of folks who interact with the project:

1. Maintainers: the team who have final say on the direction of the project and new features, and whom have merge rights
2. Contributors: people who regularly contribute to Renovate's features, fix bugs, improve documentation and help answer user questions
3. Users: the folks who use Renovate, or are responsible for their Renovate deployment. They may infrequently raise PRs for documentation of bug fixes

Shipping despite a tiny team

As noted in my recent post about why we use GitHub Discussions as our triage process, I noted that we optimise for the people doing the work and making sure that Maintainers and Contributors are able to do their best work.

The most surprising thing I've found since joining the project is seeing how lean the maintainers team is. I felt like I did intellectually know that, but seeing it in practice has been another thing.

Within Renovate's maintainer team are 3 of us - Michael Kriese (who is contracted through Mend, but also does Renovate-y things in his free time), Sebastian Poxhofer (an external maintainer who is 100% not associated with Mend and works independently) and myself (who is 100% paid by Mend).

Alongside the maintainers, we have two contributors who are paid by Mend to work part-time on the project - Rahul Gautam Singh and Sergei Zharinov, who do great work on Issues and Discussions that come in from the community, as well as work coming in from Mend customers.

We also have a number of contributors who have Triage access on the project and get involved when they're able to, but there's no expectation of any time, given it's a volunteer basis.

When you put together the size of the team behind Renovate (in and outside of Mend), you have to admit it's impressive how we've been able to ship all these changes over 2025!

Especially when you also factor in the fact that none of the maintainers nor contributors work full-time on Renovate. I try to spend at least 50% of my time on the Open Source project, but it's worth bearing in mind.

In the first 100 days since I joined, we've had:

• 95 contributors (excluding renovate[bot] and github-actions[bot])
• 187 contributions from me
• 735 from renovate[bot]
• 314 from contributors (including me)
• 419 releases
• 1 major release
• Renovate's GitHub repo hit 20k stars
• Renovate GitHub repo hit 40k Issues/PRs/Discussions

(these aren't things that I'm taking credit for being responsible for - aside from my own contributions - but I'm showing how much we've got done in a small period of time)

So with all these changes coming in, how do we keep on top of them?

As I'll talk about a bit more, community management for our Discussions is primarily taken by Rahul and I, working with users to help answer their questions.

When things promote up to Pull Requests, a mix of Michael and I will do a lot of the code review (including my many PRs!), and merge them as they're ready to be shipped.

Dependency bump PRs from Renovate are automagically approved + merged through PR-based automerge, allowing us to keep an eye on changes going in, and so we can action a failing build, but don't require human reviews given the number of dependencies being bumped. We require our external dependencies are at least 7 days old, via Minimum Release Age, to make sure that stability and security aren't lost by automated merges.

Without using PR-based automerge, we'd be unlikely to ever get to reviewing all the dependency bumps on top of user contributions, and considering Renovate is many projects, we can't scale our minimal team quite that far.

(And yes, I realise the irony of us not having time to review our own Renovate PRs 😝)

Too much shipping

At one point, we found that the pace of delivery of shipping new releases regularly over the years would actually come back to bite us!

In my first full week at Mend, publishes to the npm registry failed due to:

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).
npm error The likely cause is that you have too many versions (10451).
npm error Resolve this problem by unpublishing older versions of your package.

This wasn't down to an individual package.json being too large, but down to the fact that we had so many releases that the npm registry APIs would no longer allow publishing.

I feel that's a pretty cool "badge of honour" to note that we've been shipping consistently for so long that we end up hitting a rate limit on the npm registy side!

(Note that not every commit has its own release - we perform a batched release if there are multiple commits landing on main within the same timeframe, but sometimes it does end up being several releases a day that are a single commit worth of changes)

This was also a "fun" incident because we weren't even able to manually unpublish any versions ourselves, as we're a popular package. We needed to work with npm support, who could perform some backend magic to force some unpublishes for us, saving us some time.

We're also working to periodically clean up old tags, to make sure that we don't hit this again in the future.

There's no "I" in team

Working on a large project like this isn't possible to do on your own - it really "takes a village".

The primary projects I've been maintaining over the years have largely been down to a single maintainer (me) who has been trying to fulfill all the roles necessary, as well as fitting it in with all the other things I'm working on.

For instance, oapi-codegen is a widely used OpenAPI-to-Go code generator. But right now, my co-maintainer is mostly unable to work on the project, which means that triage, user questions and PR review, let alone being able to do forward thinking product-y thinking is all down to me - that gets hard over time, especially as the Issues and PRs pile up.

I noticed in the first couple of weeks of my time in the project that it was really nice to come in on a morning and see that Rahul had already triaged and/or resolved Discussions raised by users, or that Michael and Sebastian had already reviewed + merged Pull Requests.

It makes a huge difference mentally to know that there are other Contributors and Maintainers who are also working to support the project and that it's not all on me, unlike other projects I maintain.

I've also found that this gives me more ability to think about what I want to delegate, for instance a number of Mend customer requests may go to Rahul and Sergei, which frees me up to do a "bigger picture" piece of work, or frees me up to focus my time on code review instead.

A welcoming bunch

I'd also like to say another thank you for folks being so welcoming! It definitely helps being more of a familiar face, but it's still been nice that everyone's been lovely and welcoming.

I find it really important to build empathy with my users, and so working on the community management is super valuable to me, and allows me to continue helping others as I've been helped over the years.

It's also fortunate I enjoy it because it's core part of my role at Mend as the community manager for the project, and so it's been good that it feels much more sustainable than other projects I've maintained in the past.

This was especially something I was a little nervous about, as I was stepping into Rhys' shoes of being the community manager, but I've found I've settled well into the role.

As I've written about, Renovate uses GitHub Discussions for the community to get in touch about questions, possible bugs and feature requests. I recommend you read the post for the full discussion (pun intended) about why it's worked so well for us.

As my role as Community Manager on the project, I spend a lot of my time working with GitHub Discussions, and have found that although Discussions does work for us, there are a few areas where it's not the best experience (as an offering from GitHub).

To improve the experience for (primarily) me, I've ended up building a sync-to-local-SQLite-and-web-application which I'm calling the "maintainer dashboard", where I can now get separate views of the data, such as the below information, which isn't possible to get out of GitHub otherwise:

Another key benefit of getting raw access to the data means that we can look at other interesting queries for things that we care about as a project, such as "where have we not replied to a user request for some time" or "is someone trying to bump an old thread, instead of creating a fresh Discussion?".

I'll soon be sharing about this in a bit more detail, as well as releasing it under an Open Source license.

Minimal reproductions take time

As with many Open Source projects and commercial projects alike, before you can fix a bug you need to find a way to reproduce it.

With Renovate this is no different, and it's a large part of the "Request Help" flow our users go through, where if we can't reasonably work out what's going on from debug logs provided by the user, we require a minimal reproduction repository.

While debugging Mend customer requests, thinking about features I'd like to have in Renovate, and sometimes being extra nice and going the extra mile for a given user request, I'll put together the minimal reproductions, as our users do, which can take time.

But like with writing a design document or a blog post, going through the process of breaking down the issue into the smallest possible unit can help determine "oh, it was actually something unrelated", or can make it much clearer that the behaviour you're trying to achieve doesn't make sense.

It's hugely valuable, and was something I was doing at Elastic as our resident Renovate expert, too. I also have a separate post I've been working on, which will go into what I find works best for my own testing of Renovate configuration changes, which feeds into this.

Although I've not yet had a chance to fully play around with it, I've been planning to get an LLM Agent set up with being able to take a bug report and convert it into a Minimal Reproduction - even if it gets a maximum of 80% of the way there, that's a good start!

Hitting the ground running

One of the key reasons I joined Mend to work on Renovate was because - in my humble opinion - I was the best person for the job. I had a lot of context with Renovate, some of Mend's offerings on top of the Renovate CLI, as well as the wider package management + dependency insights ecosystem Renovate sits in.

One of the really nice things was being able to join a company and - while being cautious about over-exertion and burnout - get going straight away, without needing to onboard.

Literally on my second day, I was reviewing Discussions and PRs, and drafting my own code changes.

Going back 2 weeks before I joined, I proposed something that would take up a considerable chunk of the next couple of months - the enablement of Minimum Release Age across the npm ecosystem.

As I'll mention below, this is something I was very proud of - and there was a lot of work for a few of us making the feature as stable and predictable as possible before enabling it for a significant percentage of our userbase.

This isn't the sort of thing that you'd expect a new-starter at a company to be picking up, so it was pretty great to know that I was able to come in and immediately "push the needle".

Renovate isn't one project

Another thing that I learned fairly quickly on the job is that when we talk about "Renovate", most folks think of the Renovate CLI as the thing, but there's many more things behind it that we don't consider.

Coming into the project I feel like I knew this, and I knew that the Renovate Docker image was built on top of "Containerbase", but I'd not fully appreciated how the two interacted, as well as the many other projects that make up the offering that is Renovate.

A simplified list of some of the more interesting projects that fit under "Renovate" are:

Each of these projects needs updates, they all have their own backlogs and sets of documentation to improve and keep on top of.

As noted above, there has to be some level of automation in place for dependency updates, otherwise we'd spend all of the Maintainer + Contributor time reviewing dependency update PRs!

Although we're primarily focussing on Renovate, there are times that to implement a feature in Renovate, it requires changes across multiple components before we can implement it upstream - so sometimes this can lead to a slightly more complex contribution process, as we're fairly well documented on the Renovate CLI, but not as many of the related projects.

Typescript is great

This isn't a new opinion of mine, but I very much love Typescript. Although builds aren't quite as speedy as Go, I very much enjoy the stronger type system, and the way Renovate is configured as a project works very nicely.

It's really quite nice to have real enum types - opposed to the hacks we have to do in Go - and the Language Server is much more powerful that gopls, which has become more stark a contrast as I flip between the two languages.

I'm not likely to migrate to Typescript for personal projects - due to the beauty of the single static binary from Go - but it is nice to be working on what I find to be a really nice codebase with a strong set of tooling.

await response()

Open Source is naturally an asynchronous model of collaboration, with the globally distributed nature of users, contributors and maintainers, and Renovate is no different.

We do fortunately have our maintainers all in Europe, so we have a significant timezone overlap, and cross-continent working with our contributors still works well.

After years of working at Elastic, where my team at one point was across a couple of timezones in the US, the UK, Spain, Germany and two timezones in Australia, I'm very used to - and enjoy - more asynchronous working.

I've managed to video call with a few folks, and I plan to try and meet with all of our core contributors + maintainers over the next few months, even if it's a "hey, let's make it easier to remember we're both humans" and get to know each other slightly more.

The majority of interactions are done over GitHub, but we do have a Renovate developers Slack for contributors and maintainers, so every so often we can have some high bandwidth calls.

So many package managers

Although we've not yet merged support for new package managers (there are a couple of PRs waiting on me, sorry!), it's been really interesting finding out how many package managers there are out there.

I knew that Renovate supports many package managers, but it's been eye-opening getting a chance to see what's in use, and get a gut-feel for what our users are actually using.

With user requests coming in, it's also a little bit of a learning curve trying to work out how the package manager works, getting minimal reproductions set up, and this is another area where I need to try and lean on LLMs a little bit more.

Lots of "work in progress"

As someone with ADHD, I've noted before that I'll often (but not always) thrive more when there's lots of stuff to do at a given time, rather than only having a single task to do at a given time.

Working on the Renovate project is no different - I have several backlogs of "TODOs", coming in from community Discussions, Pull Requests, my own TODO list of "I'd love to have that done" and "that'd improve Mend's offerings if we had this" through to Mend customer requests.

Having a strong level of control over how I spend the time towards these is good, but as users, it's good to remember that there's often a lot of background work going on which may be why you're not getting a response - as noted above, I'm not even 100% full time on the Renovate Open Source project, and if you saw my email inbox from Renovate Discussions, you'd understand the delays 😅

A lot of the time, this means that I'm working through 10+ Discussions at a given time, trying to provide an answer, the right documentation, or getting an Issue raised for changes to the codebase.

Big deliveries

To take a bit of a self-congratulatory note, I'd like to talk about some of the things I'm most proud of us delivering since I've joined.

Since joining, there have been a few things I've been most proud of leading + delivering:

There are also a number of other smaller bug fixes, features and community contributions I've helped get shipped, as well as shaping a number of medium-/long-term routes for the project.

One of the great benefits of being on the maintainer team means that I've been able to look at some of my previously raised feature requests, and I can now get them delivered because I now have much more experience, and ability to explain why the features should get done - including a few I've raised in the past that are super useful for Mend to have for our hosted platform!

There's always more to do

As noted on my interview on Open Source Security, package management is a pretty large space and there's so much to it.

Renovate aims to make it possible to keep all the things updated, with safe defaults and a workflow that is configurable to work for you.

To do this, however, is a balancing act to make sure that we're not adding features that make the maintenance of the project more difficult, or to make sure that we don't introduce too many more configuration options, while also continuing to move forward as a project.

I've really enjoyed the last 100 days, and the work we've done so far. I'm very excited to see what the next 100 days bring, and onwards into the future!

If you've got to the end - well done! Was this interesting? Anything you're interested in learning more about?