Fine, then let's adopt a standard of announcing whether you're serious about your projects, and then other people know if they can rely on your library or not. Some kind of "verbal" promise of being proactive when catastrophe happens. That you'll personally won't bundle malware in your code, or your reputation will suffer.
I mean it. The open source world, especially the JS ecosystem, desperately needs something like this. And a monetary incentive isn't enough, unless it's significant, but no one will pay $500 a month per JS library they depend on.
A simple ".serious-project" committed to the project root would suffice.
Let's see how many people will pay money for their `is-odd` dependency.
Again, enforcing responsibility by paying is non viable and doesn't scale, especially in the JS world when you depend on 500 packages for a bare React project.
Yet I as an open source developer I want to announce that my projects are actively maintained, i.e. I'm serious about them and I'll react in less than 23 days if someone adds malware to my code.
> Let's see how many people will pay money for their `is-odd` dependency.
If they're unwilling to pay for it, then maybe they should reconsider including it as a dependency? And maybe, just maybe, if they include it as a dependency without any intention of paying for it, then they should have zero expectation of support for it?
And likewise...
> especially in the JS world when you depend on 500 packages for a bare React project
...then maybe they should consider an ecosystem wherein they, you know, don't depend on 500 packages for a bare project? And if they do, then maybe - just maybe - they should expect to either contribute to the ongoing maintenance of those 500 packages or else be entirely unsurprised when they inevitably fall into disrepair?
> Yet I as an open source developer I want to announce that my projects are actively maintained
Then do so: remove the clauses in your licenses w.r.t. warranties and liabilities and fitnesses for particular purposes, and declare that you'll commit to active maintenance. If that's your prerogative, then nobody's stopping you. Chances are, though, you'll grow weary of the expectations from others with which you've burdened yourself without compensation.
A better form of seriousness would be to offer support to those willing to pay you for it. Naturally, this means producing something that's worth such an agreement.
You need to vet your packages. Always, even if you paid for it.
There are package managers that work with Github repos. Should this apply to every public Github repo too?