Author here:

> If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism.

The rules in a way are changing with the threshold of "criticality". In a way what you are proposing is suggesting to developers to unpublish if they do not want to deal with the complexity of that. This is exactly what happened yesterday accidentally (https://news.ycombinator.com/item?id=32026624). From the responses I have witnessed to that incident I do not believe this a path anyone should take.

> claims you owe nobody anything while the distribution mechanisms owe you something

The post explicitly states that the distribution mechanism doesn't owe developers anything.

I think a lot of people are hung up on the fact that 2FA was your example because 2FA is widely regarded as a good idea.

My takeaway from your article is: if I create an open source project and it becomes popular, I’ll have a bunch of responsibilities I didn’t necessarily sign up for. Those responsibilities will probably include things that I don’t know how to do or don’t want to do as an IC.

I suppose some people are looking for that when they work on open source, but I am personally almost never looking for more responsibility. I have enough already, thank you.

I wonder how many more people would contribute to open source projects if they knew they wouldn’t have to worry about project drama or being guilted into taking on more responsibility? I think it’s a very real (and probably measurable) chilling effect.

EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me?

The amount of work required to maintain a very popular package is obviously higher, even without taking into account any distribution part. From your message it sounds like you expect same amount of work. Besides, the extra work from this side would pale to the extra amount of work needed to maintain just due to increase of users.

Yes, that's the status-quo. But OP is arguing, rightfully so, that we don't want to put additional responsibilities to already hand-full maintainers. If anything, we want to reduce that to make open source community more sustainable. We've seen too much that maintainers burnt out, shutdown repos, or beg for money to just keep the light on. Once they turned the project into commercial endeavor to "spread" the burden, then they have the dilemma of "open-core" dual license.

There must be a way to make the extra work minimal for maintainers even if their works are popular. For example, in the days people use apt / yum for distribution, both vetting and packaging are the responsibilities of the packagers, not the maintainers. (Not saying that's good, but just an alternative perspective, there is a reason why language-specific package registry wins today).

> EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me?

I'm pretty sure {your favorite popular basketball player}'s career prospects would not have been impacted by an NBA requirement to "spend 10 seconds sitting on the bench to warm it every day before playing". Doubly so if there was a reasonable argument that it would somehow make the stadium safer for their fans.

Volunteering is all about taking responsibility. If you contribute regularly to a project with many users, you can't avoid the responsibility. If you only want to express yourself by writing code without the burden of responsibility, you should contribute to something else.

One thing I've learned from various volunteer projects and organizations is that good volunteer administrators are rare. Finding good people for the creative parts of the project is not particularly difficult, because creative work is inherently satisfying. Administrators are another story. Many try the job and quit, because they don't enjoy it enough to do it in their free time. Others are not suitable for the role. Some are good and motivated administrators, but they drive other volunteers away by trying to manage them. And then there are the rare ones who can be administrators and enjoy it without ruining the project for everyone else. If you manage to find one, the last thing you want to do is increasing their burden.

As far as I understand, PyPI is largely a volunteer project. It works only because some people find running that kind of bureaucracy satisfying. It's their project, and they can run it any way they want. If their burden gets too heavy, they may quit, and then the project may fail. That would probably be a bigger issue than some open source contributors not liking how PyPI is run.

Honestly I don't think this is a hill you want to die on. "The greater your influence, the greater your responsibilities" is something society generally agrees is reasonable in most domains, and this is just a manifestation of that principle in the case of OSS and supply-chain integrity. The principle is pretty universal in modern society though. If you see an unreasonable responsibility being placed on you, for sure, complain about that. But if you don't think the responsibility itself (2FA in this case) is unreasonable, and in fact think it should be mandated on everyone, "it's a slippery slope!" and "it's not fair!" are not going to be compelling counterarguments for most people. It goes against what people expect in society.

When we write software as part of a job, we have all kinds of staff who support the project —- project managers, product managers, QA, marketing and sales, security etc etc.

It really seems that, for open source projects, the author is expected to be responsible for everything.

I think it would be a great benefit to all of us if people who wanted to open up code but didn’t want to add responsibility to their own world felt welcome to do so. I think it’s a problem worth solving.

"I think it would be a great benefit to all of us if people who wanted to open up code but didn’t want to add responsibility to their own world felt welcome to do so. I think it’s a problem worth solving."

I think i would strongly disagree with this view - this is similar to arguing that people should just be able to release plans for nuclear weapons (or take your pick of less extreme examples) without adding responsibility to themselves, etc.

There's no obvious reason they should be able to, or that it is a net benefit to society. It's one of those things that people often think "sounds good", but isn't that great in practice, ever.

In fact, most of the problem that exists today in OSS security, support, etc is precisely because of people opening up code without trying to add any responsibility to themselves. At the same time, OSS has produced 100 of everything, so it's really hard to believe arguments that "if we didn't let this happen, things would not progress" and the like. I don't believe we would have been worse in terms of progress, etc, if we instead had 10 of everything, with the people more willing to take responsibility.

More practically, society has always believed in balance in every similar sort of thing, so it's not obvious to me why the extreme of "everyone can release anything without any responsibility" is ideal for anyone.

> It really seems that, for open source projects, the author is expected to be responsible for everything.

If you wrote "for underfunded projects" I would agree with you. It's a pretty universal fact of life regardless of the nature of the source.

> I think it’s a problem worth solving.

Definitely, I don't think anyone is against a solution to this problem. The question is what we can expect before the envisioned solution is finally created by someone and provided to us.

What’s interesting is that we don’t really have this kind of structure in place elsewhere to my knowledge, outside of open source software. There’s a limit to how much legal liability you can shed, and even after that social liability is much more fickle.

It’s the free (no payment) part that makes the difference and outside of the Open Source movement many things are not provided free of charge because of the associated costs.

Similar things happen for research papers or generally scientific content though. You won’t be successful in suing an author of a study for incorrect content either.

> What’s interesting is that we don’t really have this kind of structure in place elsewhere to my knowledge, outside of open source software.

https://developer.apple.com/support/authentication/ ?

Not for 2FA, for absolving yourself of all responsibility.

Fundamentally I agree with you. But I also think it easy to get the idea that "no responsibility" is a prevailing view. Or at least that it has to be. There are plenty of people who want to do their best. I would certainly considered the author's software involvement to be part of that. It is just hard to do. And increasing hard not only because of software but society at large (like job and housing markets). So the problem exists regardless of various positions on the issue.

Or put another way. If we want open source developers who favor responsibility we have to make it easy for those developers. Otherwise we only end up with people who are fine with throwing things over the wall.

2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects"

As a user installing from a registry, you are trusting both the publisher AND the distributor.

Consider an attack where the distributor is adding malicious code to 1% of installs. The publisher is not involved in the process and (unless code signing is involved) has no influence.

But if code signing is involved, why is 2FA even needed? The signatures themselves should be sufficient proof.

So 2FA overall is a solution in the lens that the distributor intermediates the relationship. This need not happen. People can chuck tarballs and post signatures, establishing more direct trust compared to the indirect solution.

That's not even the point of the blog post to begin debating it here. If the the author believes that then he can write a blog post about how 2FA is bad. That's not what we have here though. In fact, he instead says "it's a sensible thing" and his complaint is that it's a slippery slope: "More importantly though is what could come next. There is a hypothetical future where the rules tighten."

> 2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects"

This is not what 2FA asserts in the context of PyPI. It’s used solely for logins to the web frontend, which is where users can manage their projects and the permissions associated with those projects. The idea is to make account takeover more difficult, since that’s (frequently) the first step in malicious package takeover. Assuming that you’re using API tokens to publish to PyPI (which you absolutely should be), having 2FA enabled on your account will not affect any ordinary publishing workflows.

We have separate plans to improve PyPI’s support for code signing.

They solve different problems. Given a signed package I can say "this is signed by that key". I can't say how that key was registered, or who registered it, etc. 2FA would be where that key registration actually happens.

That doesn't seem to apply to companies -- they make billions from open source and give back little, or nothing, to the majority of the authous and packages whose work they build on.

Now that's fine under open source licenses -- but if you want the "free", you also have to take the "no warranty".

I find it bizarre that they don't ask for 2FA for all contributions. Possibly a historical inheritance?

Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.

2FA, whether TOTP or physical, comes with a per-user support burden for any organization that enforces it, because there must be a human-in-the-loop mechanism to handle "my 2FA devices were all destroyed/stolen, and others depend on me having access to my account." PyPI isn't exempt from this, despite mitigating with multiple 2FA devices, and says as much in the announcement https://pypi.org/security-key-giveaway/ -

> Without multiple 2FA options, effect of losing a 2FA method results in the need to fully recover an account, which is burdensome and time-consuming both for maintainers and PyPI administrators. Enabling multiple 2FA methods reduces the potential disruption if one is lost.

So there's a huge practical difference to PyPI of enforcing 2FA for all vs. enforcing for <1% of projects. I don't envy their position, and it's a reasonable compromise IMO.

That said, it's absurd that PyPI didn't make more clear in the announcement linked above that TOTP apps are allowed. There's literally not an FAQ about the most important FAQ. They very well could have avoided the reaction from OP, and this entire debacle, with more thoughtful messaging.

> they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.

No, a TOTP app is also allowed.

Well then, that's perfectly reasonable.

To tack on, they're actually giving away those tokens for free for those who request one.

https://pypi.org/security-key-giveaway

They're being beyond reasonable. This is outright kind.

> Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.

They don't.

I think "unpublishing" packages is generally not something that should be done, except in the case of malware and maybe some other cases, and I believe that e.g. NPM already went through an iteration of this issue, which is why they have an explicit policy around it: https://docs.npmjs.com/policies/unpublish

But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights to make any further updates, which is, I believe, also the line that PyPI itself takes.

The fact that a package got yanked from the registry because of this is an unfortunate combination of a) PyPI allowing it (they shouldn't, and learn from NPM's mistakes), and b) the maintainer being really unreasonable in the face of a perfectly reasonable request.

> But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights to make any further updates, which is, I believe, also the line that PyPI itself takes.

That seems worse to me for quite a few cases that go towards actual burden beyond 2FA. That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. There is a reason why I have a "No Warrenty" clause in the licenses of my Open Source work. I have created it for others to enjoy it, but I reserve the rights to not be burdened by my users for the unpaid labor.

Sure, but then who does the work? No one is an answer but not much of a solution since the problem still exists. Index or package maintainers could do the work but would often also be unpaid and burdened even more. An organization could do the work but most packages don't reach the level where they would get adopted.

If being unpaid is the problem then the most obvious solution is to charge for the index, possibly only for commercial use, like a streaming service. Use some for the index and give the rest to the projects who does the work. As far as I know it wouldn't be against open source as people think non-commercial licenses are. But it would still be hard to do for various reasons. Some legitimate and some not.

> That implies the index will take away someone's permission over their creation as a result of too many other people also started using it.

The creation here is the package, not the distribution channel. You can use an alternative Pypi-compatible index (there's one built into Github, and enterprisey ones can be purchased from Azure or AWS) or you can put instructions for a local build & install on your blog.

The maintainers of PyPI should be able to enforce some amount of quality control over their creation, after all.

Caveat: Not everyone in FOSS is American, but…

Here in the US folks tend to have some amount of burden on their creations, tools they use, etc. Just because you put out a sign that says “Not My Problem” doesn’t make it so.

Great example is these big gravel trucks hauling rocks to job sites, they’ll rain stones on the roadway and the cars and sometimes pedestrians because the workers are sometimes too careless to pull down the tarp to secure their load. They’ll put up a sign saying “DRIVER NOT RESPONSIBLE FOR DAMAGE” but the problem is they 100% are both legally and morally responsible.

We also have some rules around nuisance, enticement, etc. For instance, if I have a pool and a kid jumps my meager fence and drowns I might we’ll still be responsible, at least legally, because I put up an enticing thing but failed to consider how idiots might misuse it.

To me, the pool one starts to get at or near “South of Sanity” but that’s from where this mentality applies.

Often you’ll get some Node project some cool tech person shits out, pimps out to social media , then abandons when the real work comes out. Folks will pick it up early on as traction builds, then be stuck with abandonware when the author gets a new job or chases a different shiny ball. I would argue you at least owe a caveat in the README about your level of commitment to the project, a bit beyond a mere “not my problem” license line.

Wow. This attitude is exactly why I don’t post software anymore.

I’m not delusional; I know that the world might be better off without my creations littering it. But if I were an attorney advising $Bigcorp, messages just like this one are why I would advise against posting any free software unless there is a business case for how the benefit outweighs the risk.

And a disclaimer does not eliminate risk, not even the heightened disclaimer you suggest (why isn’t the disclaimer in the license enough?) The instant I have to defend a lawsuit, I’ve lost. It doesn’t matter if the suit is meritless and I “win.” Then instant someone sues me, the only winner is my lawyer.

I guess this was all inevitable when people started relying on free software. They somehow think people who have given them something for free owe them something. I guess this works fine when the giver is $Bigcorp doing it for profit-seeking reasons. But this attitude is going to strangle the old small-time hobbyists who really were just scratching an itch.

Now I know why some software is posted under pseudonyms.

You are absolutely right here. If anything the excluding of implied warranty works better in the US than many other countries for Open Source as typically a price is required for implied warranties to exist but even there are limitations.

I also tend to agree that there is a certain level of added burden that comes with popularity that you cannot get rid of. This starts from the basic fact that I noticed a few years back of becoming a target of social engineering.

I do however think for as long as we believe Open Source is a good thing and there is limited ways for developers to receive monetary compensation for their work, we should be quite careful here. Enrolling people into things purely based on the popularity of their creation without compensation to me feels problematic.

I think it would be ideal if the increase in responsibility was accompanied by some actual reward, so the “congratulations” would be more genuine. I don’t know what kind of reward would make sense - money makes sense, but who’s money? Maybe you get a voice in the development and direction of the language and ecosystem? That would also constitute more responsibility but it might feel less burdensome and give you a seat at the table for the next such decision.

No, they simply take away your rights to publish your creation to their index.

You can always publish your creation on your website or wherever.

> You can always publish your creation on your website or wherever.

What you're suggesting wouldn't solve the problem for critical packages, though; the effect would be similar to yesterday's package unpublish issue[1] (all users of the package would have to update their dependency references despite no change in the content of the code).

[1] - https://news.ycombinator.com/item?id=32026624

No, the issue yesterday is that people had to go in manually to fix their CI builds, etc. That's simply not necessary if you don't update the version and yanking is disallowed (which it should be).

After that, if people want to at some point update to a newer version of the package, yes, they will have to adjust.

Hrm, fair point. Although migrating 'backwards-compatibly' like that could leave a lot of people in the cold if-and-when a security update for the package is released (and we're talking about critical packages here, at least for now).

How about you 1) leave old versions in place on the package index, 2) declare that you will not be providing further updates to the package through the index because of this issue, 3) go publish your stuff on your website or an alternate package index?

So what? Users can do that if the maintainer chooses to move hosting.

Sure, accepted. That'd be a disruptive change, though, and I think that a better approach is possible.

The suggestion regarding separation of (immutable) packages and policy in the article could provide some hints in that direction.

There is no reason the index can't do the extra thing they want for their own reasons themselves.

There is no valid reason to demand the already-a-volunteer do anything extra to supply something they want for their own reasons.

They could collect the source and vet the updates all kinds of other ways than demanding the author jump through hoops for them, for free.

> They could collect the source and vet the updates all kinds of other ways than demanding the author jump through hoops for them, for free.

At minimum it's completely unproven that that would be practical, whereas 2FA is trivial and has been widely deployed for decades.

But if you feel strongly about this feel free to make a formal proposal. There are some nascent projects exploring this area that you could draw inspiration from and I'd certainly welcome tooling in that area.

What a weird leap. Now not only the author of some software has to jump through someone else's hoops, I a total bystander also has to? It does not require "feel strongly" to observe the invalidity of some argument.

Rather, if you feel so strongly that something should be done, like vet that software, you could do it.

You don't have to do anything?

"The post explicitly states that the distribution mechanism doesn't owe developers anything."

But then goes on to claim otherwise in the rest of it. :)

Which means that statement does not actually help your cause.

Is the whole point of this not to ensure that someone can't use your identity to produce a compromised package?

When I download someone else's code its my job to make sure the code I run isn't riddled with spyware. Hence why I design my projects to rely minimally on external dependencies.

Why should this burden be placed on the developer and not the user?

If I buy a chainsaw and cut my arm off, is this the fault of the chainsaw manufacturer?

You do know that bladed machinery is made with more and more safety features right? No one actually thinks "oh fuck em if they lose an arm". It just isn't a good comparison, nor a good solution.

This kind of reply is frustrating. Someone wrote a nice article explaining how it may not be desirable for package indexes to force the authors of packages to put on even more work to get their free work published, work that they didn't have to do before... and the best answer you can come up with "that's nonsensical"?

Here's what is nonsensical: to call the author's argument "i would like to have my cake and eat it too" because the author does not ask to eat any cake... they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it... to call this argument nonsensical is offensive to the author and to those who read the argument and actually understand it.

> they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it...

Yes, the "having the cake" would be the ability to publish code to pypi and the "eating it too" would be the abdication of responsibility to abide pypi policy.

> they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it

PyPi is free and not the only way to distribute your software. You're welcome to self host. PyPi, in order to be successful as a package repository, needs to serve both authors AND users. If you don't want to abide by the new policy? You don't need to use PyPi, and your account is presumably locked. Nothing is taken away from you except your ability to continue to use a free service for free without abiding by their security policies.

This is as nonsensical as being upset that PyPi is enforcing minimum password length or requiring HTTPS. They're not making money from this, they're obviously not doing it maliciously. The motive here is to stem a very serious problem with package management (across all of software) in a really mundane, minimal effort way.

Specifically when you say "the burden should be on the users who care about it," those users are YOUR users. They turn to your PyPi identity as a source of trust for the packages they download. If there's a new version published under YOUR profile, it's not possible to know whether that package came from you or not unless YOU do more work (reliably publishing about it elsewhere). This problem can't be put on the users of the software because there's no reasonable way for them to actually accomplish what you're describing. To say that the author here should not have any responsibility ignores the core premise of what PyPi does.

Frankly, putting the burden on the user would be blocking access to these packages unless the user explicitly opted in with messaging like "Flask is owned by an account which has no 2fa enabled. This could result in a supply chain attack in the future. Are you sure you wish to install it?" I think we can all agree this isn't the right way to solve the problem.

A flag would provide choice and unburden everyone.

Personally I am not outraged by the fact that Python’s most popular package authors must go through the “burden” of authenticating their accounts properly.

> Nobody is forcing you.

Well, the author was happily using that distribution mechanism and built a community of users whose production systems are now locked into it. Then they rules changed unilaterally, effectively holding access to that community hostage. They most certainly are forcing the author to do something!

Sure the author had a choice to not use PyPi when they initially published a package. But doing so NOW, yanking the project and publishing elsewhere, would directly cause massive amounts of problems that would need to be solved. Who's going to do that labor? The author. There's no reasonable interpretation of this situation that doesn't involve the author being forced to do something.

Don't agree with your interpretation of what the original author is trying to convey.

It's not about the rules of the package distribution channel has. It's about the fact that they have different rules for different levels of popularity.

If everyone needed to do 2FA fine. Don't want to do it? Guess you'll distribute your code another way.

But... You can use it and we're going to gladly take your free work and host it and in the process benefit from it (look! It's so simple publishing stuff! Use us) until the liability of hosting you becomes greater than the benefit of hosting you. At that point we need to pull out the adult rulebook and teach you how to properly do things.

So to me it sounds like the distribution channels want to have their cake and eat it too while passing the work to the developers,ie the people that made the distribution channels successful in the first place.

The author doesn't want anything.

The index wants something for their own reasons, but for some reason considers it reasonable to demand the author do something they want instead of doing the thing they want themselves.

The author provides various ideas for how they could get what they want by doing it themselves or by organizing volunteers who choose to work on that.

It's like demanding a better man-page than the author supplied, instead of writing one or facilitating someone else who may be willing to work on documentation.

If you walk into my house and I ask you to take off your shoes, you can turn around and walk away. I am well within reason to make that demand - it's my house.

OK, I'll skip the obvious analogy. PyPI is a free, open source service. It hosts packages for distribution. When you go to PyPI you say "Hi, I would like to distribute software, can you do this?" and they say "Yes, you can do this for free. There's some terms of use, and we require 2FA."

You can say "Great, I accept all of that, thanks for providing distribution of my code for no monetary cost to me" or you can say "Ah, ok, thanks anyways but I would prefer not to accept that".

Is that clearer?

The more correct analogy of what it looks like in a few months is PyPI coming back to you after a while saying “this package we are hosting for free you can only update or delete if you now follow these new terms if use. If you don’t agree we take away your access but retain the package.”

You can't say that's more correct. That's a prediction about the future that's based on nothing, as far as I can tell. Does PyPI have a history of increasing, unwelcome restrictions?

I mean, of course you have to continuously accept terms of use changes as you publish to them. That is the same as anything else. To tack on a bit of additional conversation,

"Hi, I previously published v 0.1, I would now like to publish v 0.2"

"OK, cool, we have a new EULA if you want to publish 0.2"

"Great, no problem, signed and now I'll publish" / "Ah, I don't like those new terms, I'll publish elsewhere or not publish at all"

I don't get the complication here.

> You can't say that's more correct. That's a prediction about the future that's based on nothing, as far as I can tell.

The statement I made is based on what is currently communicated. The "terms" is purely "you need to use 2FA" (which just to be clear I already said I have no quarrels with). I cannot judge what will be the future requirements will be for critical packages. Donald Stufft from PyPI on Twitter said that he could imagine requiring signed releases (https://twitter.com/dstufft/status/1545503252871004161).

> I don't get the complication here.

Maybe there is none, maybe there is. The consequence however undoubtedly is that if you do not accept the terms you lose access to your package on PyPI.

> Maybe there is none, maybe there is. The consequence however undoubtedly is that if you do not accept the terms you lose access to your package on PyPI.

Right but I just don't get why this is notable or why anyone would ever be surprised by this, or why this would ever be controversial. I just can not wrap my head around this being framed as a complex issue when it seems so very straightforward.

It is indeed so very straighforward and not a complex issue, which begs the question why you might not be able to wrap your head around it. I call volition.

Federated / self-service responsibilities are the only way things like this ever scale. In your example, it makes sense the index wants to push the responsibility out broadly, there’s no way the index can develop the breadth and depth of expertise necessary to write high quality man pages for every package - they’re too busy using their limited resources on maintaining the index (their “vertical”).

So what? Too bad? No one else's problem? The reasons they want things vetted and attested was never contested. The fact it's a lot of work, is a given. And neither of those things explain why the author has to do it, necessarily. Maybe it's natural, maybe the author of a thing is generally the best positioned to attest and support their own output, but so what?

If they find the software valuable enough that it matters that it's verified and certified, and the supplier doesn't feel like doing it, they could do it themselves or arrange for others to to do it or delist the filthy uncertified package or just tag it as not certified. There are all kinds of options besides demanding a volunteer do something they didn't aldeady feel like doing voluntarily.

I don't get why everyone confuses the obligations here. Just because pypy wants something, no matter how understandable the reasons, doesn't change the fact that it's pypy who wants it, for their own reasons.

The author derives no value from it (not neccessarily, they may choose to value the credit and exposure of their work appearing in the index, but they also may not). Pypy derives value from it, and all of the users derive value from it.

The obligation for supplying that extra frosting they want on the cake lies with those who want it.

I’m not at all confused about the obligations.

You seem to be confusing requests and demands.

PyPi requests that you take certain steps once your package is deemed critical. If you don’t, they prevent you from releasing new versions.

The author presents a perfectly reasonable alternative with argumentation supporting the position. There is nothing in the article about being forced.

Personally, I find the described model - especially with trusted "notaries" - much better. It might also help with open source financing.

I agree it's nonsense. The argument appears to dodge 2FA itself and the benefits to ecosystem by instead focusing on fairness, which is subjective at best.

It's not "fair" that the author has to accept the burden of 2FA, because they created a package that turned out to be critical through no fault of their own.

It would seemingly satisfy the author's "fairness" goal if everyone had to use 2FA whether their packages are critical or not.

It's also ironically not "fair" that the volunteer maintainers of PyPI are subjected to complaints like this for their hard and valuable work to improve the security of the entire ecosystem, which has become critical infrastructure itself through no fault of their own.