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.