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.