While I don't have hard numbers, it does feel that the number of messages on the mailing list has gone down since RTC was implemented, which implies to me that there's less discussion activity. I haven't seen Matt or Ralph post much lately(although I think Ralph has been busy).
It seems like there are two competing forces at play here: on the one hand, there's the fact that Log4j is a rather important part of the Java ecosystem, and as such needs to be carefully maintained. On the other hand, development seems to be mostly on the backs of Piotr and Volkan at the moment, meaning that there is not a large group of people who are actively maintaining the project. I don't believe that anybody is being paid to work on it full-time either even though I know Volkan and Piotr have both had some level of payment from the Sovereign Tech Fund in order to work on Log4j2. To Matt's point, because the process has become much more of a $WORK type of job now it's harder for him to do anything with it. This could also potentially push away new contributors. Personally I'm not convinced that /required/ reviews are a way of improving code quality, or that they will help to catch the next log4shell. It would be bad if enough current maintainers were pushed away - reviews might help to prevent log4shell, but a lack of maintainers could lead to the next XZ supply chain attack. Reviews themselves are still important, but how they get done may need to be less strict. -Robert Middleton On Tue, Jan 6, 2026 at 12:10 PM Matt Sicker <[email protected]> wrote: > > I have a follow-up message to this topic which I previously shared to the > private@ list regarding personal context around this situation. > > I’ve been contributing to Log4j since 2013. This project has oftentimes been > my creative outlet for where I can work on problems (or do some soothing > refactoring such as porting tests from JUnit v4 to v5 or cleaning up areas of > code identified by static analysis tools as concerning). This outlet has come > in handy during the various points of my career where I would be stuck across > multiple parallel lines of work waiting for PR reviews in order to make > further progress (whether those be from co-workers or from upstream OSS > projects I contributed patches to), and the only place I could work on things > without having to wait multiple days or weeks to make progress on was Log4j. > > However, once we began requiring PR reviews, Log4j became an extension of > $WORK rather than a passion project. As such, I pivoted to getting buy-in at > $WORK to contribute to the project. By the time I had all the approvals and > had started planning on some ideas of what to work on, Log4j had reached its > current state where there are approximately two maintainers active on it, > both of whom insist on PR reviews even from committers and PMC members. The > long time contributors who were extremely active back in the early 2010’s > have all faded from the project, most of them since about a year or two after > Log4shell. I suspect that the overly formal code review process for > committers has contributed to this decline; I know it has had a major impact > on myself. In fact, over the past couple years, I’ve found entirely new > hobbies to replace the time I used to spend working on Log4j on nights and > weekends. > > > On Oct 16, 2025, at 12:43 PM, Matt Sicker <[email protected]> wrote: > > > > When we decided to try out RTC, I had accepted the idea with the caveat > > that I’d only be alright with it if there is prompt PR review. Some of my > > PRs since then have indeed been reviewed or approved within a day or two > > (good), but some of them have sat for months without a single comment. > > Seeing as how we’ve disabled committing to main and 2.x directly, I can’t > > merge my own PR. I’m bringing this issue up once again to see if we can > > resolve it. > > > > This makes it much harder to make simple code changes such as typo fixes, > > documentation updates, small refactoring, and similar chore work simply too > > complicated with unnecessary procedures. There are some other reasons why > > this RTC flow doesn’t seem to match this PMC: > > > > * RTC tends to be used in highly active codebases with dozens or hundreds > > of regular contributors. > > * RTC works best when reviewers have sufficient time available every week > > (estimate; thinking of the 72-hour style feedback window at ASF). > > * RTC can technically be accomplished by having a coworker review the code > > before making a PR (assuming both are on the same PMC), which gives undue > > advantage to full-time contributors compared to part-time contributors. > > * RTC seems to think that the ideal time to go over architectural design > > and other planning details is at the time of proposing the code change; > > ideally, non-trivial changes will document and discuss the proposed feature > > via mail and issue tracking. > > * RTC is a flow optimized for accepting contributions from third parties; > > being invited to be a committer is supposed to trust that person with the > > responsibility to know what they feel comfortable committing directly > > versus what may benefit from peer review ahead of merging. > > > > If you wonder how it is or was possible to manage this project using CTR, I > > point to the past when it was CTR. Before we enabled Dependabot, I used to > > be able to follow the commits@ mailing list where I could asynchronously > > review code as it was added to a main branch. Replying to those emails > > would default to dev@, so the conversation went somewhere meaningful. When > > we used CTR, I would oftentimes post to dev@ with details about what I was > > planning to implement or change. We had also configured CI to post an email > > about test failures in the main branch(es) so that if they were broken, we > > were alerted to the need to fix it right away (which was even more useful > > in the past when our build/test time was much longer than it is now). >
