The rise of few-maintainer projects(increment.com)
increment.com
The rise of few-maintainer projects
https://increment.com/open-source/the-rise-of-few-maintainer-projects/
36 comments
In my opinion the farm analogy doesn't work because you can't fork a farm and continue working where the original left off. In my opinion Dominic should have simply stopped maintaining the package, and maybe added a message stating that the package is no longer being maintained. If someone wants to take over then they would need to fork it. That would force people to consciously switch to the newer forked versions and there would be no surprises about a new maintainer suddenly inserting malicious code.
That is what I do too. (I also do not give commit access to anyone else, but do accept patches after I review them. However, nobody ever sends patches or other stuff, but if they did, then I will read them. I do, however, allow others to edit the documentation, just not to edit the code itself.)
That analogy might work with the original formulation of this idea: if someone opens a "big" pull request on a project you weary of, hand it over. That PR, even without substantial review, can show effort and familiarity, and you could argue there's a really good chance they'll try to be good stewards.
But in this case, it's not "a member of that community who also has potato farming skills", it's an absolute nobody, who you haven't seen doing any farming, or eating, before. It's a big world, there are crazies out there, they show up every once in a while.
And finally, it's the internet, it's not really like anything that came before. You can be more trusting in a small town than in a big city. The internet is 1000 times bigger than the biggest city, it's a whole new kind of thing. If 99.9% of people out there have good intentions, that still leaves millions of people on the internet trying figure out a way to take advantage of you.
But in this case, it's not "a member of that community who also has potato farming skills", it's an absolute nobody, who you haven't seen doing any farming, or eating, before. It's a big world, there are crazies out there, they show up every once in a while.
And finally, it's the internet, it's not really like anything that came before. You can be more trusting in a small town than in a big city. The internet is 1000 times bigger than the biggest city, it's a whole new kind of thing. If 99.9% of people out there have good intentions, that still leaves millions of people on the internet trying figure out a way to take advantage of you.
Trust issues can often be mitigated with verifiable signatures. Perhaps if there was a protocol in place requiring each release to be signed by the current maintainer and all commits signed by the individual contributors, then a change in signature on the release would have provided a strong downstream signal that maintenance had changed hands. Without verifiable signatures, downstream is drinking the water without testing it. As you said, there are crazies out there, who knows what they might put in the water.
> It is like giving up volunteer work to another volunteer
But without making it clear to anyone else in the volunteer community that that's what you've done. In other words, using your garden analogy, a weary volunteer potato farmer whose potatoes feed a lot of people is approached by another volunteer who wants to take over maintenance of the potatoes. The weary volunteer gives it to him, but doesn't tell any of the people who rely on his potatoes for food. The new volunteer puts a harmful substance in the potatoes and lots of people get very sick, because they thought the potatoes were still being maintained by the first volunteer, who they knew and trusted; they had no idea that the potatoes were now being maintained by a newcomer who they didn't know and whose trustworthiness they had no way to evaluate.
But without making it clear to anyone else in the volunteer community that that's what you've done. In other words, using your garden analogy, a weary volunteer potato farmer whose potatoes feed a lot of people is approached by another volunteer who wants to take over maintenance of the potatoes. The weary volunteer gives it to him, but doesn't tell any of the people who rely on his potatoes for food. The new volunteer puts a harmful substance in the potatoes and lots of people get very sick, because they thought the potatoes were still being maintained by the first volunteer, who they knew and trusted; they had no idea that the potatoes were now being maintained by a newcomer who they didn't know and whose trustworthiness they had no way to evaluate.
> But without making it clear to anyone else in the volunteer community that that's what you've done.
You mean like pretty much 100% of everything else going on in a typical open source community?
I’d wager at least 99.99% of the users don’t even knows who or how many maintains a piece of software, nor if updates are based on external patches or (core) internal development.
They just sit there entitled and expect free (gratis) software which works for them without providing anything in return.
I’m not saying that because I’m a bitter maintainer, but it’s just a fact of life.
You couldn't inform these users about any changes at all even if you wanted to, because they’re simply not involved and they never will be.
Anyway, if they cared, if they were somewhat involved, they would know. As it stands, it’s their own fault for blindly trusting random code from the internet.
And really: mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this?
You mean like pretty much 100% of everything else going on in a typical open source community?
I’d wager at least 99.99% of the users don’t even knows who or how many maintains a piece of software, nor if updates are based on external patches or (core) internal development.
They just sit there entitled and expect free (gratis) software which works for them without providing anything in return.
I’m not saying that because I’m a bitter maintainer, but it’s just a fact of life.
You couldn't inform these users about any changes at all even if you wanted to, because they’re simply not involved and they never will be.
Anyway, if they cared, if they were somewhat involved, they would know. As it stands, it’s their own fault for blindly trusting random code from the internet.
And really: mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this?
> I’d wager at least 99.99% of the users don’t even knows who or how many maintains a piece of software
I'm not talking about users. I'm talking about other developers who are using the package, and who deserve to know when the package's maintainer changes.
> it’s their own fault for blindly trusting random code from the internet
Developers aren't trusting random code from the internet; they're trusting a particular package maintained by a particular person who, from past experience, they have reason to trust. But if that maintainer hands the project over to someone else without telling all those other developers, that's betraying the trust those other developers put in that maintainer.
> mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this?
Because it's the previous maintainer's job to tell other developers when he turns over the job to someone else. Failing to do that means the previous maintainer is basically saying what you said above: it's those other developers' own fault for blindly trusting my code, hahaha, sucks to be you. Is that the ethos you want other open source developers to follow?
I'm not talking about users. I'm talking about other developers who are using the package, and who deserve to know when the package's maintainer changes.
> it’s their own fault for blindly trusting random code from the internet
Developers aren't trusting random code from the internet; they're trusting a particular package maintained by a particular person who, from past experience, they have reason to trust. But if that maintainer hands the project over to someone else without telling all those other developers, that's betraying the trust those other developers put in that maintainer.
> mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this?
Because it's the previous maintainer's job to tell other developers when he turns over the job to someone else. Failing to do that means the previous maintainer is basically saying what you said above: it's those other developers' own fault for blindly trusting my code, hahaha, sucks to be you. Is that the ethos you want other open source developers to follow?
The majority of developers are freeloaders who deserve exactly what they gave Dominic, ie nothing. If the act of posting code on github creates rights or an obligation to others, it rapidly becomes untenable to do that thing.
It wasn't Dominic's job, because you (and everyone else!) wasn't paying him.
It wasn't Dominic's job, because you (and everyone else!) wasn't paying him.
> If the act of posting code on github creates rights or an obligation to others, it rapidly becomes untenable to do that thing.
He didn't just post the code on github; he had publish rights on npm, which is where node developers are supposed to publish code they want other node developers to use. Lots of other node developers used it. Then he gave the publish rights on npm to someone else and didn't tell anyone.
If you're entirely ok with that, you're basically telling any node developer not to trust npm. Which basically breaks all of node development. Is that your intent?
> It wasn't Dominic's job, because you (and everyone else!) wasn't paying him.
I see you are not clear on the concept of a volunteer job. If lots of people use your code and you don't give them any indication that (a) you're no longer actively maintaining it (as someone noted in the github comment thread, he could have archived the repo long before this happened since he was no longer actively maintaining it and hadn't been for years), and (b) that you gave the npm publish rights to someone else, then, whether you like it or not, it was your job and you failed to do it. You made a promise to all those other developers and then you broke it.
If your argument is that nobody will do open source development for free under those conditions, then there is a lot of evidence over the past few decades to prove you wrong. But nobody is forcing you to do open source development for free under those conditions. It's everyone's free choice whether they're willing to put their code out there and whether they're willing to actively maintain it for free once it's out there. What you can't do is change your mind and not tell anyone. If Dominic realized that he didn't want to commit to maintenance for lots of developers for free, he should have archived the repo to make that clear.
He didn't just post the code on github; he had publish rights on npm, which is where node developers are supposed to publish code they want other node developers to use. Lots of other node developers used it. Then he gave the publish rights on npm to someone else and didn't tell anyone.
If you're entirely ok with that, you're basically telling any node developer not to trust npm. Which basically breaks all of node development. Is that your intent?
> It wasn't Dominic's job, because you (and everyone else!) wasn't paying him.
I see you are not clear on the concept of a volunteer job. If lots of people use your code and you don't give them any indication that (a) you're no longer actively maintaining it (as someone noted in the github comment thread, he could have archived the repo long before this happened since he was no longer actively maintaining it and hadn't been for years), and (b) that you gave the npm publish rights to someone else, then, whether you like it or not, it was your job and you failed to do it. You made a promise to all those other developers and then you broke it.
If your argument is that nobody will do open source development for free under those conditions, then there is a lot of evidence over the past few decades to prove you wrong. But nobody is forcing you to do open source development for free under those conditions. It's everyone's free choice whether they're willing to put their code out there and whether they're willing to actively maintain it for free once it's out there. What you can't do is change your mind and not tell anyone. If Dominic realized that he didn't want to commit to maintenance for lots of developers for free, he should have archived the repo to make that clear.
> It's everyone's free choice whether they're willing to put their code out there and whether they're willing to actively maintain it for free once it's out there.
Literally not according to you. One 'git push origin master' and our contributor has signed up to your requirements.
Dominic made no promises to anyone -- he offered the world something and said they could use it if they wanted. Full stop.
Literally not according to you. One 'git push origin master' and our contributor has signed up to your requirements.
Dominic made no promises to anyone -- he offered the world something and said they could use it if they wanted. Full stop.
> One 'git push origin master' and our contributor has signed up to your requirements.
I made no such claim. Did you read what I actually wrote?
> Dominic made no promises to anyone
Not by putting his code up on github, no. But that's not all he did.
I made no such claim. Did you read what I actually wrote?
> Dominic made no promises to anyone
Not by putting his code up on github, no. But that's not all he did.
> > Dominic made no promises to anyone
> Not by putting his code up on github, no. But that's not all he did.
I don’t see how putting your code on npm is fundamentally any different.
No one is entitled to free maintenance of gratis software forever, just because someone once said “npm publish”.
That’s not how open source works. It works by people contributing and getting involved, as opposed to entitled freeloading.
> Not by putting his code up on github, no. But that's not all he did.
I don’t see how putting your code on npm is fundamentally any different.
No one is entitled to free maintenance of gratis software forever, just because someone once said “npm publish”.
That’s not how open source works. It works by people contributing and getting involved, as opposed to entitled freeloading.
> No one is entitled to free maintenance of gratis software forever, just because someone once said “npm publish”.
I have made no such claim. If he didn't want to maintain it any more, he could have said "npm deprecate" and that would have been fine.
What's not fine is to say "npm publish", then actively maintain the software for years, then decide you don't want to any more (which, in itself, is fine, it's your choice how much effort you want to put in), but not tell anyone, not deprecate, not send any signal that you have changed your commitment to the package--and then hand over publish rights to some random person who emails you, also without telling anyone.
If you think that is fine, then, as I said several posts upthread in response to another poster, you've basically said no developers should ever trust npm, because people who say "npm publish" are making no commitment whatever, not even to say "npm deprecate" if they don't want to maintain the package any more, or to tell anyone if they decide to hand maintenance over to some other random person. That is not how open source works.
I have made no such claim. If he didn't want to maintain it any more, he could have said "npm deprecate" and that would have been fine.
What's not fine is to say "npm publish", then actively maintain the software for years, then decide you don't want to any more (which, in itself, is fine, it's your choice how much effort you want to put in), but not tell anyone, not deprecate, not send any signal that you have changed your commitment to the package--and then hand over publish rights to some random person who emails you, also without telling anyone.
If you think that is fine, then, as I said several posts upthread in response to another poster, you've basically said no developers should ever trust npm, because people who say "npm publish" are making no commitment whatever, not even to say "npm deprecate" if they don't want to maintain the package any more, or to tell anyone if they decide to hand maintenance over to some other random person. That is not how open source works.
> you've basically said no developers should ever trust npm
Nobody should. At least not blindly. You should check what updates are and who made them. On every update.
Anything else is irresponsible and your own god damn fault when things go wrong.
> That is not how open source works.
npm is a proprietary package-repo and has nothing to do with how open source works. You can also easily publish proprietary packages using npm.
Nobody should. At least not blindly. You should check what updates are and who made them. On every update.
Anything else is irresponsible and your own god damn fault when things go wrong.
> That is not how open source works.
npm is a proprietary package-repo and has nothing to do with how open source works. You can also easily publish proprietary packages using npm.
> Nobody should.
Ok, thanks for putting everyone on notice.
> npm is a proprietary package-repo and has nothing to do with how open source works.
So event-stream is not open source?
Ok, thanks for putting everyone on notice.
> npm is a proprietary package-repo and has nothing to do with how open source works.
So event-stream is not open source?
I sorta trust my direct dependencies in node-world and have some idea who is responsible and if they are reputable. But there's approximately 1187 other subpackages nested ad nauseum under those dependencies, and there could be anything at all hidden deep in the bowels of that mess, with some malicious party potentially injecting who knows what.
I hate it, but this is what we have made it. I hope that we aren't getting riddled with backdoors and keyloggers and miners, but I wouldn't want to lay money against it.
I hate it, but this is what we have made it. I hope that we aren't getting riddled with backdoors and keyloggers and miners, but I wouldn't want to lay money against it.
My comment applies in general, but yeah node/npm is particularly shit in this regard.
I wonder if the node community will ever revert on the terrible idea that single functions should be separate packages.
I bet moving away from that model would make node dependencies much more sustainable.
I wonder if the node community will ever revert on the terrible idea that single functions should be separate packages.
I bet moving away from that model would make node dependencies much more sustainable.
> I'm not talking about users. I'm talking about other developers
False dichotomy. Developers are users too.
And trusting random code from the internet is still irresponsible as a developer, maybe even particularly as a developer.
> Developers aren't trusting random code from the internet; they're trusting a particular package
Let’s be honest. They did an act of “npm install gratis shit”, and they don’t give a shit where that code comes from. I.e. blindly trusting code from the internet.
If they expect more without getting involved, they are by definition acting entitled.
False dichotomy. Developers are users too.
And trusting random code from the internet is still irresponsible as a developer, maybe even particularly as a developer.
> Developers aren't trusting random code from the internet; they're trusting a particular package
Let’s be honest. They did an act of “npm install gratis shit”, and they don’t give a shit where that code comes from. I.e. blindly trusting code from the internet.
If they expect more without getting involved, they are by definition acting entitled.
> Developers are users too.
But most users are not developers, and "developer" is the relevant category here, not "user". So saying "user" is inaccurate.
> They did an act of “npm install gratis shit”, and they don’t give a shit where that code comes from. I.e. blindly trusting code from the internet.
I'm not unsympathetic to this. However, even if other developers were at fault, that doesn't mean Dominic wasn't. Not deprecating the package, and not telling anyone when he handed over the publish rights to a random person who emailed him, is still wrong even if the developers who used his package were wrong as well.
But most users are not developers, and "developer" is the relevant category here, not "user". So saying "user" is inaccurate.
> They did an act of “npm install gratis shit”, and they don’t give a shit where that code comes from. I.e. blindly trusting code from the internet.
I'm not unsympathetic to this. However, even if other developers were at fault, that doesn't mean Dominic wasn't. Not deprecating the package, and not telling anyone when he handed over the publish rights to a random person who emailed him, is still wrong even if the developers who used his package were wrong as well.
I agree with the sentiment but I think you are being too gracious with your analogy. The long and the short is a group of developers was relying on another group of developers to provide software with security concerns for free without vetting the implementation.
I don't know what is more unethical, the backdoor or the blind distribution of the backdoor.
I don't know what is more unethical, the backdoor or the blind distribution of the backdoor.
The event-stream incident shows that npm has restructured the way projects work: rather than an end-user choosing a few pieces of software, each of which has a lot of maintainers, they install a huge number of very small packages each of which has a very small number of contributors. The "unit of contribution" is not a pull request or commit but spawning a new micro-project.
Community management and vetting remain hard problems that aren't fun to volunteer to work on for many developers, so they are neglected.
Community management and vetting remain hard problems that aren't fun to volunteer to work on for many developers, so they are neglected.
NPM is an actual company, they are the ones responsible.
And some people are complaining that Python has too many batteries. I'll be happy when I can depend only on the stdlib, which I expect to have better reviewing process than a thousand random projects.
I'm curious how the new Github Sponsors development plays into the one or very few maintainer "issue." My gut instinct tells me it will be an added incentive to keep the governance of such projects small or solo because how do you deal with distributing the funds over numerous maintainers with vastly different levels of contribution? I guess one could argue that a project valuable enough to attract a large sponsorship would also be too unwieldy for some to handle alone.
But I haven't given that much critical thought and I hate to default towards cynicism immediately after getting presented with a way to help get open source developers some financial support.
But I haven't given that much critical thought and I hate to default towards cynicism immediately after getting presented with a way to help get open source developers some financial support.
I agree, it would tend to encourage a smaller core team and a larger number of unpaid contributors. But this is often a workable model. I don't think most drive-by contributors expect to be paid and that seems... fine?
I suspect that most small projects won't receive much if any funding anyway.
The problem with this type of analysis mirrors that of wikipedia:
http://www.aaronsw.com/weblog/whowriteswikipedia
> Almost every time I saw a substantive edit, I found the user who had contributed it was not an active user of the site. They generally had made less than 50 edits (typically around 10), usually on related pages. Most never even bothered to create an account.
Pandas might have had 4 core maintainers as measured by commit count, but the actual work might have a much larger outside influence
http://www.aaronsw.com/weblog/whowriteswikipedia
> Almost every time I saw a substantive edit, I found the user who had contributed it was not an active user of the site. They generally had made less than 50 edits (typically around 10), usually on related pages. Most never even bothered to create an account.
Pandas might have had 4 core maintainers as measured by commit count, but the actual work might have a much larger outside influence
I'm reminded of Wikipedia and drive-by edits. When each repo is so small (equivalent to a single article on Wikipedia, or even less), it seems like they should be part of larger organizations with a bit more bureaucracy and guidance?
> When each repo is so small (equivalent to a single article on Wikipedia, or even less), it seems like they should be part of larger organizations with a bit more bureaucracy and guidance?
You mean like publishing a coherent library-package, rather than a million independent function-packages?
We know how to do this, but the Node-community just won’t have it.
You mean like publishing a coherent library-package, rather than a million independent function-packages?
We know how to do this, but the Node-community just won’t have it.
Great idea.
Would make sense to pool volunteers for code reviews similar to what Stackoverflow does for questions, answers, edits etc.
Would make sense to pool volunteers for code reviews similar to what Stackoverflow does for questions, answers, edits etc.
Hmm, review and certification of open-source packages could likely be a business. Something similar to commercial Linux distributions, like RHEL, that test and vet their packages, but not limited to that.
Like GitHub's organizations?
No. A better analogy would be that a weary volunteer potato farmer for a large community garden is approached by a member of that community who also has potato farming skills. The community member tells him that he wishes take over maintenance of the farm. The weary volunteer accepts the community members offer and leaves the farm in the new volunteer's hands. The weary farmer returns to his home, and pursues other things. Meanwhile, the new community's potato farmer turns out to be malicious. Keep in mind that more than 99% of the time these volunteers are just wanting to give back to the community.
It is nothing like giving up the keys to your home. It is like giving up volunteer work to another volunteer, because that is exactly what it is.