Pull in something

[GeorgeWL]

there's been zero updates since 2018, yet there's plenty of pull requests

[ChipWolf]

There's some reasonably active forks and alternative repositories

[GeorgeWL]

@ChipWolf ah, that I didn't know, and this one still shows up as the top result on search.

Can you recommend any in particular?

[ChipWolf]

https://github.com/fuzzdb-project/fuzzdb @GeorgeWL

[GeorgeWL]

well that name doesn't make it clear at all what it's for. Thanks for the link though 👍

[minimaxir]

Sorry, I've been busy. Given the demand, I'll give this another pass.

In the future, send me an email; I don't follow issues/PRs as closely.

[GeorgeWL]

@minimaxir you thought of adding some collaborators that are allowed to merge for you?

I've seen it used before by other popular modules such as this, and as long as you're careful with who you pick, it keeps things running smoothly when you're too busy to keep it running yourself.

[minimaxir]

The "careful who you pick" is the hard part. I'd be more open to donating the project entirely to a reputable org.

[scribblemaniac]

It looks to me like there aren't any long term contributors, or people who have been maintaining their forks well the past year, which are the things I would look for. But to be completely blunt, it would be hard to find a maintainer among the open source community who does a worse job than no job at all. I can't blame you, I'm too busy for many of my own projects too, but this one is popular enough that you should be able to find at least a couple people willing to help with the upkeep. An org would be nice, but I'm not sure which one would be suitable for and interested in this project.

[minimaxir]

it would be hard to find a maintainer among the open source community who does a worse job than no job at all

That's not a good assumption. For example, when I first launched the repo years ago I received monetary requests for ownership of the repo; giving permissions to the wrong person could cause problems.

Unlike most repos where dependency changes can break a code project or new information can make the project obsolete, this repo is mostly a .txt file which (probably) won't be obsolete any time soon. Comparing inactivity this repo to others isn't apples-to-apples.

[Ruaphoc]

I would recommend reaching out to (in this order):

1. OWASP
2. EC-Council https://www.eccouncil.org/
3. Cloudflare
4. ISE-COM https://www.isecom.org/
5. Mozilla Foundation

[scribblemaniac]

That's not a good assumption. For example, when I first launched the repo years ago I received monetary requests for ownership of the repo; giving permissions to the wrong person could cause problems.

At minimum, all we really need here are some active people with write access to the repository. There is nothing particularly destructive that someone can do with that that can't easily be fixed by removing them and a force-push to the repository. See what exactly collaborators can and can't do on a personal repository here: https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/permission-levels-for-a-user-account-repository. They can't transfer ownership of the repository or even invite other contributors so this shouldn't concern you so much.

Unlike most repos where dependency changes can break a code project or new information can make the project obsolete, this repo is mostly a .txt file which (probably) won't be obsolete any time soon. Comparing inactivity this repo to others isn't apples-to-apples.

I agree it's not apples to apples with libraries or the like, but inactivity still harms the project. People are here to test their systems for vulnerabilities and errors, but it isn't as useful if they don't end up testing known issues until years after they have been discovered.

Your argument can be looked another way too: because it's just a .txt file, malicious modifications to the file would not really break anything. If someone were to put "Sponsored by So-and-So Publishing" it would be a nuisance and obviously should be removed if the project is not benefiting from that, but it would not break anything. Deleting acceptable test cases is slightly more problematic, but like any other change can easily be noticed and reverted with git.

I'm not advocating giving the repository to the first person you see on the street. I do think though that finding some people who are a) interested in this project and b) have a proven track record with open source projects to be given write-access has risks that are far outweighed by the benefits of an active project, including:

• people are encouraged to contribute because their PRs don't sit unreviewed for months and months
• people are encouraged to use this repo because it looks up to date
• the many people and organizations that do use this repo (if the stars are to be believed) are more likely to catch issues with their systems because there are more test cases and newer test cases available