For the last year I’ve been pointing people to click through to a talk by Juliette Reinders Folmer called “Resurrecting the Dead.”

It was via this Mastodon Post from @lauchgott. The talk is online, and starts at 3:59:23, on YouTube, at the Neos Conference 2025. I’ve listened to it a few times and what’s wonderful and startling about it is how much it’s about the fact that open source code contributions are made of PEOPLE. So many incredible nuggets.

So much in software we talk about code and frameworks, but ultimately all this code depends on human effort.

The talk is filled with pithy lines that strike me as true. She talks about forking and the pitfalls thereto. I’ve been at San Diego IndieWeb Camp 2025 talking about the past and future of the IndieWeb, how to maintain the software libraries and standards we use, how to write resilient HTML and CSS and all of this has been terrific.

Thank you. Yes, we’re going to talk about Resurrecting the Dead tales of an accidental maintainer. Now, before you wonder, there are projects for which I’m a deliberate maintainer, where I’m not the accidental maintainer, which I started from scratch, which I maintain like that. But there’s also a project for which I’m an accidental maintainer. Now, what is an accidental maintainer? Quite often, these are projects where I’d never even looked at the code base before, but I use them. And something was failing, something was going wrong, and the maintainer wasn’t picking them up. So these are some examples of projects for which I became the accidental maintainer. Now, how does this happen? Normally, it means something something in my project or in my CI pipeline is failing, so I submit a patch to fix it, quite often to do with a new PHP version. And that patch then gets a failing CI build in the project. And I then look at the CI and realize this has nothing to do with my patch, but the CI is wildly out of date. It might still be on Travis. It may be they’re using outdated dependencies, which is why the CI is failing.

So I then submit another PR to fix their CI. And then the waiting game begins. Sometimes, depending on the project, community pressure starts building up. People start saying, ” Can this please be merged?” Pinging the maintainer. At some point after a few months saying, ” Can you please just take over the project because we need this as well?” Keep in mind, community pressure is also how the XZ Utils Backdoor vulnerability happened. Do you all know XZ Utils? If you don’t, look it up after the talk on the internet. It’s an interesting story. It’s the biggest vulnerability on the internet which would have happened and only just got prevented in time. Last year (2024). Right. So after about six months of this community pressure and nothing happening, depending on how essential the dependency is for me, I sometimes end up taking over. Now, the latest in this list is PHP Code sniffer. I’m now the official maintainer of PHP Code sniffer. Now, Yeah. Codesniffer does have a little bit of a different backstory. I was actually already an active contributor for about eight years. And the official maintainer had been becoming less and less active for about four or five years.

And at some point, he pings me privately saying, I’m going to abandon the project. I’m Which is not going to do it anymore. And realistically, this project was too big to fail. Something like 500,000 dependents. That’s too big to fail . And just In the case, just making sure, is there anyone here who’s never heard of PHP Code sniffer? Okay, a few. In the PHP world, there’s basically two typical go-to tools for checking code style and sometimes part of code quality, PHP-CS-Fixer and PHP Codesniffer. And PHP Codesniffer is the biggest of the two. Also, PHP Codesniffer has about three times as many features as CS-Fixer. Half a million dependents. I had other plans, but what did you do? How does this happen? Well, you originally started a project and it’s greenfields and nice. Sometimes you just start a project because you want to explore a new technology or you want to just try something out. If that works well, then it might become a popular project and mature and you make sure there’s tests and you make sure the codebase is clean. And that’s the stage where you really want your project to be, a mature project with contributors from outside.

And then life happens. So Sometimes the project then becomes a zombie project, where it still maintains, but not as actively. And it takes longer before PRs get merged. And it’s perfectly fine if that happens once in a while, and it’s perfectly fine to rotate between those mature and zombie states. Preferably, you stay in the mature stage, but still, the zombie stage is something which happens to every project at some point. And then sometimes, yeah, that happens. So what is the reason for abandoning a project? Anyone? . Well, So literally, it’s just one answer, and that’s called LIFE HAPPENS . And whether that is because you meet someone wonderful and start a family, or because you get a different job and your job doesn’t permit you to contribute to open source, or you just get a job in a completely different field. Or maybe your parents are getting elderly and they need care, and it falls to you to help them. Or, yeah, health. Sometimes your body just does things which you don’t expect. And I’m not saying this as a situation which is a hypothetical future. This is already happening. One of the other projects for which, again, I became an accidental maintainer is the Composer plugin for a PHP Code sniffer.

Originally, we started out with three maintainers. Currently, we’re two. Why? Because the third one has a terminal brain tumor. This is someone, I don’t even know their age, somewhere in the 30s, beginning of 40s, and they have a terminal brain tumor. And what to me is the scariest thing about this, I wouldn’t even know about this if it weren’t for the fact that we have off GitHub contact. Because it’s not as if you open an issue in the repo and say, Oh, I’m going to have to step down as a maintainer because I have a terminal A brain tumor. This is happening, and it may be happening to your project, and you are not aware of it. You don’t know about it because this is not something you communicate via an issue on GitHub. This is a reality. And one thing I also want to call out in the life happens category is mental health. Maintainer burnout is a real thing. Now, the typical path to maintain a burnout is maintainer saying, I need help. Please give me funding so I can balance my work-life balance better and spend more time on the open-source project.

And companies then go and say, I heard “help,” and they put people on the project. So now the people who got put on the project are generally people who’ve never contributed to the project before. So now the project is flooded with low-quality PRs, which are basically not mergeable in in any reasonable time. And this overloaded maintainer who needed funding to improve their work-life balance is overloaded even more and starts getting community pressure to merge PRs which are crap. It has to defend themselves against that, tries to ignore those PRs, and at some point, screams out “help” again. And the cycle continues. This is the road to maintain a burn out. Please do not beat that company which does Right. So now you know a project is being abandoned. Now what? Sometimes there is a one-on-one replacement. Sometimes you can just swap out one project for another. The interface, the API may be similar, and sometimes it’s not that much work. But a lot of times that’s not the case. And if, say you are an agency and all your sites, all the projects you maintain as an agency are built on Neos, and Neos would be abandoned.

Now, you might say, Okay, then we switch to TYPO3 , but that would still be a lot of work, and your customers may not want to pay for it. The dependency being abandoned, depending on how critical that dependency is for your project might mean bankruptcy for your company. This is what you really need to realize. So sometimes it might even be more beneficial for the company to decide to hire someone to maintain that project so you can continue to keep using it. It’s not always as easy. So what happens when a project gets abandoned? What are the options? Well, sometimes you can add a new admin, but this is not always the case. In a personal GitHub account, you can add committers to a project, but you can’t add a new admin. In a company organization, you, again, might want to add committers to the project, but it’s very rare that an external person will be allowed to be admin in a project in a company organization. So this is not always an option. It is the best scenario. The second best scenario is transferring the repo, preferably to a dedicated organization. I’ll come back to that.

The good thing about that is that your users will continue to be able to find you because GitHub will automatically redirect the URL from the old repo to the new one. You keep the history, you keep the issues, you keep the PRs, you will lose the get the GitHub Pages address if you’re using that, but you keep everything else. So that’s second best scenario. The third, and you really preferably would not want that, is you have to fork the repo. This is what happened with Codesniffer. I had to fork the repo. The original maintainer did make it a “blessed fork,” as in he very much supported me taking over, but he did not want to transfer the repo. What that means is you lose access to all the history of the project. You lose the issues, you lose the PRs, you lose the Wiki, you lose get the GitHub Pages address. All of that is gone and you have to start from scratch. And by the way, do defork the repo when you fork an essential dependency. The thing is, otherwise the PRs will still go to the repo. Not a good thing. So forking, not great.

But for Codesniffer , I’ve been blessed that the maintainer at least let me keep the Packagist name, the Composer name for the project, which helped. But Every five user had to change their setup. Every person will use the far downloads, every person who use d clones of the repo. They all had to change their CI, their setups, to account for the fact that the project moved. The last option is, let it die. Now, you may say, Okay, but that just means that someone else will fork it. And yes, that will happen. About 10 or 20 people will do that. And then nobody knows where to contribute. Nobody knows what the canonical fork is. And a year later, the project is still dead. So do not have the illusion that if it’s a non-blessed fork, that it will survive. Having that communication that something is the canonical successor really does help to keep the project alive. Right. So what does it mean to be a maintainer? Well, nothing ever just works. You may think it does. No, it does not. Things change, whether it’s a new PHP version coming out or Composer making and the requirement that plugins have to have permission to be run or a new PHP Unit version coming out, or Travis suddenly deciding, Oh, see, we’re going to no longer support open source for free.

There’s always something to be done just to keep the project running. Nothing ever just works. So what does maintaining mean? Maintaining is keeping things running, primarily. Maintaining means unblocking contributors, making sure that CI is still passing at any point, so your contributors will get a passing PR if their PR is good enough. Maintaining also means envisioning the future. I have plans for two, three major (versions) in the future. I’ve not published all those plans because I don’t want to over-promise. But I do I do envision the future. I do envision where I’m going and how to get there and what small steps I need to take now to be able to get there in a few years. That is maintaining. What maintaining is not is doing bug fixes and new features. And yeah, that’s painful because I really love developing. I really love coding. So yeah, I’d like to do more of But at the same time, that’s not my priority anymore. My task in bug fixes and new features is guiding contributors, helping others, giving others the platform to shine. You want to grow a community around the project. You don’t want to be the sole maintainer.

To grow that community, you need to give people the opportunity to contribute. And Bug Fixes and New Features are the best place to start. So how do we prevent getting into a situation of abandonment? Well, yeah. Let’s have a look at healthy versus unhealthy project. And I’m presuming all of you know this, but just to reiterate, A healthy project generally has multiple maintainers. It then has a layer around that with regular contributors who maybe do one PR a month, but come back and continuously contribute. And then you have the occasional, or as I often call them, the drive-by contributors, the people who once in a while contribute something or just throw it over the fence and just hope that you do something with it. They just provide a PR to scratch their own itch and then continue with their life. In a healthy project, people can move between these circles. So a maintainer can decide, I want to step back for a while because life, and become a regular contributor. A drive-by contributor might become a regular contributor for a certain period because their employer allows them to. People move between these circles. And you can because there’s enough people in each circle.

Unhealthy project: you have a sole maintainer and you have very few occasional contributors. That’s what you really don’t want. But at the same time, this is the reality of the vast majority of open-source projects. So what we need to do is we need to start doing succession management. Now, what is succession management? First of all, start documenting the project. Document how you accept PRs. Document the release process. Document what your policies are for accepting new features. Document how you decide upon where to go into the future. Document. Activate the community. Try to get more contributors. One way to do it is to improve the contributing file. When I started and took over Code sniffer, the contributing file was this. It’s now this. Why did I expand it so much? On the one hand, to give people lots of different information, lots of places to start contributing, Also to set them up for success, to give them lots of information on when a PR will be accepted, what they need to comply with. Set people up for success. Help them to become contributors and successful contributors to your project. Another thing I’ve done is I’ve created a community CC list.

Now, this is a project, Codesniffers, which has a huge ecosystem around it. It’s used in IDEs. It has lots It has lots of external standards, it has lots of integrations. So any decision I take might be a breaking change and will impact those external standards, might impact integrators. Anything which makes that change, I will add a CC with a list of people who have volunteered to be on that list so they can give their opinion. They are interested parties, they are involved parties, they have vested interest in keeping Codesniffer alive and also helping guide it to the future. And I asked for their opinion. I’ve asked for their guidance because I don’t know everything either. Next step, identify candidates for eventually becoming a maintainer. Identify your regular contributors. Approach them and ask whether they want to be coached, whether they be interested in maybe potentially becoming a maintainer at some point. Validate your trust in these people because, again, XZ Utils. For Codesniffer, this is really something I’m very aware of. We have autofixers. That means if I were a malicious maintainer, I could literally inject security vulnerabilities in 500,000 of the top PHP projects just by people running the autofixers.

I have to be very, very careful. Who I give commit rights, I need to be able to trust them to take the right decisions and to spot those kind of risks. Promote them when they’re ready and funding, and I’ll come back to that later. Now, how do you do that? Another thing in this whole story about succession management is making sure, even if you’re still growing the community, even if you’re still the sole maintainer, make sure someone else has the keys to the castle, that you’re not the only one with access to the project. If I would get under a bus tomorrow, someone else would need to be able to still maintain Codesniffer or have access and decide who should be the next maintainer. So make sure someone else has admin to the organization, has ownership of the organization as well. Make sure they have access to Packagist, make sure they have access to the different platforms. And by the way, yes, I’ve done this for Codesniffer already as well. Just in case you have a lot of projects in your personal account, you can also designate a successor via GitHub for your personal account.

Please do ask that person for permission to make them your successor. Right. Now, I’m going to let you read this for a moment while I take a sip of water. Yeah. Can someone please, please, please explain this to me like I’m a five-year-old? Yeah. Basically, we need to talk about funding, and we need to talk about structural funding of open source. The free and open source software was never about money. It was about freedoms. It was about the source code being public, being free to adjust the source code. But it was never about money. Open source is not free. If open source is not free, if you’re not paying for it, someone else is, and most of the time, that someone else is the maintainer. And they are paying for it with money for domains, for extra services, with time, and quite often with their mental health. There is a name for this. And remember this name, Exploitative Capitalism. Do not be that company. So funding is not optional. We really need to change the culture because let’s be realistic. In 10, 15 years, a lot of the open source maintainers of now are going to reach pension age, and the next generation is not stepping up to take over.

And even if they are stepping up, they’re not willing to do it for free. So we need to start this discussion about funding open source, and we need to start taking it seriously. If you depend for your business on open source projects, if you use open-source projects and you do not fund those projects, you have an unmitigated business risk. Your company could go bankrupt if your dependencies get abandoned. See it as insurance. You ensure your company building when it’s not on fire. And no, you’re not getting anything while you’re paying insurance until that building burns down. Similar with open source, you start funding open source as an insurance for the long levity of the project to make sure, hopefully, that it will stay maintained to increase those chances. It doesn’t buy you influence. It doesn’t buy you a seat at the table. It’s like insurance. And I’m not looking at any of you individually to start funding projects. I’m looking at all of you as ambassadors. Please take this message back to your companies. Start discussing this with the board of directors. Start discussing with the CFO that they need to realize that they haven’t mitigated business risk and they need to do something about it.

Can I ask you all to make the promise to do that? Can I have a yes? Good. Okay. So what are some do’s? When you take over a project, set up funding channels. When I took over, I took about a month to set up the fork, including setting up the funding channels, because coach never didn’t have any. Use a dedicated organization. I’ve already mentioned some of the advantages with a dedicated organization You can add a second owner, you can more easily add other admins. But it’s also you can… Sometimes there are subprojects which don’t have to be in the main repo, but can have their own repo. Like the PSR per, we still want to get a standard setup for that. That doesn’t have to be in the code sniff repo. We can have a separate repo for that, and I can give other people commit and admin in that repo without risking the main project. So with a dedicated organization, you buy yourself flexibility for that thing. Improve the contributing guide. I already mentioned it earlier, but it really is something which is helpful to set expectations and to help people get started contributing to your project.

Use PRs and protected branches. The previous maintainer had a tendency to push straight to the main branch. The problem with that is there’s no control. Nobody verified their code. Using PRs creates transparency. When I now create PRs in Codesniffer, and aside from the technical debt PRs, those are merged quite quickly. But if it’s a functional PR, I will leave it open for like three to two days, maybe up to a week, depending on how big the feature, how important the feature is, to give other people the chance to review my work, to give their opinion on what we’re changing in Codesniffer, to give people the chance to have a say. Also, especially with expanded CI, especially if you’re the sole maintainer, it’s the way to keep yourself honest, because everyone makes mistakes. So expanded CI, I have spell check enabled, I have markdown checkers, I have link checkers, I have all sorts of Q A setup just to make sure that those things don’t get missed because it’s too easy to miss something, especially if you’re the sole maintainer of a big project. Use signaling via labels, and obviously, most people will No, the typical labels, help wanted, good first issue.

But also signal waiting for opinions. This is something you don’t actually need to do something other than to read it and give an opinion whether something is a good idea. Another one, close candidates. If something is like a niche thing which probably doesn’t need to get solved, if someone else then speaks up, Hang on, I also have that problem, then it may not be a close candidate after all. So again, Use labels to signal and close quickly. As a maintainer, seriously, the amount of noise and the amount of pressure you get from people trying to get attention, either via discussions or issues or anything you can do to reduce that noise is a good thing. Closing issues quickly is the way to do that. Anything that’s open is actually something which is open for action. I’ve taken over a year and a half ago, and yes, I’ve learned some things in the meantime, sometimes the hard way. Say no a lot. It’s not nice to have to say no to a lot of things, but it’s unavoidable. You need to set direction, you need to take decision, and And you can’t keep everyone satisfied. But say no quickly so you make it clear what the expectations are, what is going to happen.

Have an off GitHub contact. This is good for your mental health. Have contact with some regular contributors, via video calls or via different channels than GitHub. Just, okay, I’m thinking of doing this. What do you think? I don’t want to make it public yet, but I just want to have a quick opinion. Have off GitHub contact. Make a plan and stick to it. Leave room in the plan for new ideas from external contributors, but do make a plan and try to keep making progress on that plan. And pace yourself. You can’t do everything yourself and in one go. When I took over the project, Okay, the Sniffer had code coverage with tests. The whole of the framework basically didn’t have any code coverage. A project 20 years old which had 65% test coverage. That amount of technical debt, you can’t just magic away in a week. Pace yourself. There’s enough to be done, and you can’t do everything at once. Now, things I struggle with is slow turnaround on feedback. And this is a personal thing. Some maintainers will not have a problem with that or may even be slow themselves. For me, if I look at the PR, give you feedback within a day or two, I would very much like you to update based on that feedback within a day or two as well, because then the PR is still fresh in my mind, and I can look at the update and either merge it or give you some further feedback, but we can make progress really quickly.

If I give feedback and then the next iteration on the PR is like a month further away, by that time, I’ve gone through 300 or maybe even 500 other PRs and issues, and I’ve lost the context completely. And it costs me exponentially more time to review that PR again because I have to completely regain the context, read all the previous conversations about it before I can review and then respond again. And if that happens a couple of times, believe me, your PR is bottom of my pile on the to-do list because I know how much time it’s going to cost me. Another thing is when is good, good enough? And this is, again, it’s difficult. You can’t set the same standard for external contributors as you set for yourself. At the same time, I’m actively trying to reduce technical debt, not add more technical debt. So you You need to find a balance there to still make contributors feel welcome and give them a path to success without adding more technical debt to your code base. It’s lonely. The buck stops with you. There’s nobody else, and you are the final decision maker, and you’re not going to make everyone happy.

You need to be able to handle that. And if you can’t, definitely Very, very quickly, try and find a second maintainer. And the last thing, I don’t know everything. And this is with Codesniffer. Codesniffer is not a code base I set up. When It’s your own project, which you started from scratch. Even if you’ve not worked on it for a few years, it’s like an old coat, and you put it on and it might smell musty and it might have some tears and it needs some work. But everything about it smells and feels familiar. When it’s someone else’s code base, that doesn’t work. There are parts of code snips where I never touched because I never had the need to touch them. So I don’t know everything either. And I’m happy to admit that, but that’s sometimes difficult if you then have to reevaluate a PR from someone which touches that part of the code base. So But you need to do a lot of learning yourself as well. Right. For those of you wondering, is Codesniffer still alive? I think it is. Yeah. So one of the things I’ve done, aside from a lot of focus on technical debt, is also focus on the end user experience.

One of the reasons for that is to reduce support requests because support request cost me a lot of time, time I can use for other things. So improving the help screen, improving documentation, there’s been a lot of things where I’ve really tried to improve the end user experience, improving performance, and also improve the stability. We have 11% new test coverage added from that 65%, actually, 66%, I think we’re at 78 now. So that’s huge for an old code base like this. We don’t have full support I don’t have a PHP 8. 4 yet. I’m sorry about that, but seriously, do not talk to me about property use. We will get there, but it’s going to take a while. So lots of things have been happening, lots of things which make for a better experience for engineers, but also for sniff developers, for external standards, they can now deprecate sniffs without failing builds, for instance, which is a great win for people. For those who don’t know, in about somewhere in the next two weeks, expect PHPCS 4 to come out. This is the first new major in eight years. This was not an easy road because the old maintainer created a four-branch five years ago and then cherry-picked into it.

I basically had to recreate the whole four-branch. And I didn’t want to come back on promises which had been made before because a lot of things had been promised that this is going to happen in four. So that release is coming out. And from then on, I can take my own part after that. So in case you didn’t realize this talk was not about Codesniffer. This talk was about dependency management and realizing, knowing your dependencies, knowing where your risk is, where your business risk is, knowing how those projects, those dependencies work, what their status is. Contribute to those projects and start funding them to prevent crucial critical situations, well, critical situations from happening and your own project and your own company potentially going bankrupt. So thank you.