I’m firmly in the “you don’t owe anyone a single thing” in open source camp, and I believe you should be able to throw your code out into the world and not give a shit what happens. But James is obviously correct when he says that mantra has to be applied equally to the pypi maintainers who are free to dictate mfa as a bare-minimum security practice for packages they handle, and therefore that truly does just end the conversation.
Even more the pypi maintainers are free not to deal with cracked accounts anymore because people are too lazy to use good password management. And there are two options: Enforce 2FA or simply let the cracked accounts run rampage.
Astonishing to me that this is somehow controversial to some people. Running a package index is really hard, thankless work, and when they do the most basic thing to protect themselves, developers throw a fit.
I agree and want to add that despite some regulations this is also true for commercial and closed source software and product’s in general.
Most services have something along the lines of “we can turn it off at any point and may delete your account at any time for any reason”. On top of that software for various reasons might stop eorking, because servers are shit down, even Google is famous for shutting down services, stopping to maintain software because they don’t want to pursue it.
In fact open source with no obligations gives you more guarantees cause you might fork or incorporate it, so are a lot more independent of creators and providers in just situations. Even when it’s just randomly put out there. Good luck trying to do that with any other product even if the company is dead it might sometimes be outright illegal.
One might say that there’s contracts in the commercial field, but other than one often being dependent in one direction while the other side bring able to just terminate you (GitHub if you do more than just code hosting), you might also just do contacts in open source.
I think we are lying when we act that this is somehow just a thing with open source when for the most part commercial products also come with very little a compy owes you. Any cloud provider even Google and Amazon can at least in theory just drop offering that service. Or force you to upgrade into something or change plans, etc. And unlike with open source you might not be able to just stick with what you have.
And for open source it’s the same. I would also argue that even when zero rules if there’s more than one dev or even just enough technically versed users you have more likely long time support than with even big companies, espt for things like smart devices, but even in must other areas.
And I think it will become worse, because the goal is to bind customers, upsell them, etc. For much open source that’s not the incentive and if it changes you might just fork. A relatively young example is Mapbox and Maplibre
I believe you should be able to throw your code out into the world and not give a shit what happens.
Under one critical condition: say so. Make it clear that you’re releasing the stuff as-is, and that for real this time, there is no guarantee. Write this in the most obvious place possible: landing page, README…
That would be nice but it can’t be all that critical a condition if most open source I come into contact with (eg npm packages) is unacknowledged abandonware, and the world keeps on turning.
I’m more in contact with cryptographic code on GitHub, for which the standards are… well, stringent enough that people sometimes nuke their code when I point out a bug.
I still don’t get why some people mix software development and software maintaining. Security guarantees are quite logical move if you’re part of a supply chain that is being used by people.
If I want to just make stuff I’ll only put it on a public repo and it is up to someone else to find it and incorporate if it is useful. Including that piece of software into some sort of repository - being so pypi or openbsd packages - is a completely different matter, and just as writing useful software includes obvious things “it has to build/work” the supply chain integration requires a verification and increased security/audit measures.
I still don’t get why some people mix software development and software maintaining. Security guarantees are quite logical move if you’re part of a supply chain that is being used by people.
I want my code to be used by people, but I specifically don’t want it to be “part of a supply chain”. The open source world seems to have gotten into this extremely concerning state over the last decade where somebody’s hobby project or personal library that they threw out there for other hobbyists to use can be part of the infrastructure of a billion dollar corporation, and worse, that they are now somehow in a quasi-contractual relationship with said corporation.
There are a bunch of intertwined social and technical problems going on here, but one of them is certainly that the “everyone can publish to the same centralized package repository” system of package management simply shouldn’t exist. I’m as guilty as anyone of using them, but in retrospect, they’re clearly a bad idea. The other biggest problem is the recuperation of the radical potential of Free Software by capitalism as Open Source. Developers need to step up and insist that the commons is not a supply-chain.
If you want to write and release software that nobody is ever allowed to use in any commercial endeavor, you can accomplish that via licensing, but even the Free Software movement generally frowns on licenses which discriminate based on fields of endeavor, and prefers to just use things like the AGPL which accomplish the same end result via other means (sometimes too well, given that the AGPL is now ironically popular as a way to use copyright to enforce a monopoly on commercial exploitation).
And like I said in the post, if some “billion dollar corporation” gets a bit of benefit from something that also protects people who have far less resources to secure their projects, I am willing to accept that as the cost of protecting the other people. I’ve made peace with the fact that it’s hard and perhaps impossible to serve the underserved without creating the opportunity for at least a few free riders to get something they could have otherwise afforded.
Meanwhile, centralized services of all sorts, not just package indexes, are not going to go away any time soon, because social forces inevitably push us back to centralizing over and over again.
You’re always free to distribute a tarball, but package repositories ought to look out for the health of the overall ecosystem. I don’t think MFA is that onerous (neither was the GPG key I grumbled about for maven), but even if it is, better to suffer it.
The sooner we stop romanticizing open source development, the better for everyone.
That’s the only reason Open Source exists; the thought of freedom, creativity and providing value to the world. If you take that away, the only thing left is “work for free”, which I guess not a lot of people want to do.
Well, “work for free” and “provide value to the world” are the same thing in a lot of situations. If you opt to submit your work to a package index, then you are really steering to the “work for free” direction and not in the “freedom” and “creativity” direction.
The latter two would indeed be better served by a tarball or repository. Write some blog posts about it and submit it to communities for discussion, then you can provide value through creativity.
The problem here is perhaps not that obvious. But I am thinking about this angle. When you compare this to the “app stores”, it becomes clear. Epic games wants to sue Apple and Google for taking 30% cut. You can’t buy e-books through the Android Kindle App any more. Google and Apple get to decide what is “critical”, what is “spam” and everything in between. They already do that, more or less, but it isn’t to say that the system is flawless.
But the kicker in that case is, any app developer NOT publishing on the app stores absolutely has no chance. Play/App Stores hold monopolies in their respective ecosystems, and for any chance of global success, you can’t make it without them, and have to go by their rules.
Now, apply that back to pypi. Or npmjs.com. Or any such centralised package. If you’re not using them, your package has a lot, lot less influence. You can provide a lot less “value to the world”. For some niches, probably no value, since the not-so-good alternative is in the index and gets used instead, and your “value to the world” is totally wasted.
Then again, running an index - or an app store - costs resources. If those that invest the resources get some benefits - like setting their own rules - then they should be able to. If you want, you’re free to run your own index. Invest a lot of money, time and work into maintaining it, marketing it, making it so awesome that people WANT to come etc.
The answer to any question in this industry seems to always be “it depends”.
I think you’re both totally correct. Romanticizing open source is both detrimental to its well being and is also the only reason for it to exist. It lives in a perpetual state of self sabotage and we love it, sometimes for that reason.
(I think I just romanticized the self-sabotaging nature of romanticizing open source)
Thanks for this, your phrasing of the three values really is helpful.
What I referred to as the romantic view is probably best thought of as neglecting the tension between freedom, creativity and providing value. It seems like you can have all three, but there will be choices. Providing value means managing a community, enabling MFA and generally spending a lot of time on boring problems.
“Dude, your stuff – the product of your work that you gave away for
free – has gotten so important that we’re going to ask you to
do extra free labor above and beyond what we require of everyone
else.”
Among many possible responses, “fuck that, I don’t wanna” is
perfectly reasonable.
That is the crux of the matter. Any discussion of MFA or the like is
really missing the point. The problem isn’t with requiring MFA. The
problem is with waking up one day to be told that you have to do some
extra unpaid work above and beyond what is being asked of most other
contributors, because your work is now considered “critical”.
As a lifelong contrarian whose motto is “I don’t wanna”, I totally get
this piece.
Calling MFA “extra free labor” is quite the stretch. I would rather
they just enforce MFA to publish to the platform altogether.
That point was hammered home both in the article and in my TL;DR. To
MFA or not to MFA is not the issue at hand.
From my faithful dict client:
work:
Exertion of strength or faculties; physical or
intellectual effort directed to an end; industrial
activity; toil; employment; sometimes, specifically,
physical labor.
[1913 Webster]
involuntary:
adj 1: not subject to the control of the will; “involuntary
manslaughter”; “involuntary servitude”; “an involuntary
shudder”; “It (becoming a hero) was involuntary. They
sank my boat”- John F.Kennedy [syn: {involuntary},
{nonvoluntary}, {unvoluntary}] [ant: {voluntary}]
I think “exertion of strength or faculties … not subject to the
will” certainly fits the topic under discussion.
Is it reasonable for pypi to ask for MFA for everyone? Extremely. Is
it reasonable for pypi to require MFA specifically from authors of
“critical” packages? I suppose so. Is it reasonable to be upset about
being asked all of a sudden to go the extra mile because your package
becomes “critical”? Yep. If you answered no to the third, then maybe
you have a vision for free software that differs from my own.
I disagree that MFA is going an extra mile. It’s kind of a bare minimum
security posture in today’s age.
Well, that all depends on your threat model. See the MFA thread. As
I’ve said I’m willing to grant that MFA is a reasonable requirement.
One person’s “a little nothingburger of an ask” may well
be another’s burden. I had a cardiac event last fall. They had to
shock my heart back into a normal rhythm, and I also required heart
surgery. I have 30% cardiac function today. I don’t have near the
spoons I used to have.
If someone feels put-upon, listen to them, because you don’t know what
their struggles are.
It’s closer than before tho. I think we need to separate the indexes from the machinery of package management before we can hone in on the next step though. Allow for example somebody like jfrog or similar to easily run their own indexes and/or additional vetting etc without having to replace the mechanics on devs’ workstations. You could set up your own index for your shop, or pay somebody to run an index of blessed and known-good-together packages, or any number of other things I haven’t thought up yet.
Sure. I specifically am concerned about attribution and assignment of namespaces. Every package index is a namespace, creating an economy where some names are more valuable than others and there is a natural scarcity of short/memorable/easy/branded names. This is not a healthy pattern for a software commons.
I want to imagine Free Software which doesn’t care who wrote it. The software has the appropriate license, and the precise identity of the author would not alter the rights granted to the user, so the packaging system’s design should trade off a precise identity for other possible benefits. One obvious benefit is that there is no longer an artificial division between standard libraries and third-party libraries.
On the other hand, holy shit, PyPI let’s you publish packages without MFA? I knew python packaging was bad but I didn’t know it was that bad.
I don’t really understand this part. Several ecosystems does not enforce MFA and this has been common for years, why are we suddenly regarding this as an absolute requirement for publishing?
Several package managers read directly from git repos (pip included), and github does not enforce anything either.
I guess it’s been a long time since I used any package repository other than Clojars. That one is relatively small but it’s required MFA for a few years now so I just assumed the more professional ones had been … well, professional about it. I certainly wouldn’t trust a package repository that treated it as optional.
In my head, npm, Maven Central, Rubygems, and PyPi are all big enough to have multiple full-time professional staff employed to run them, but I’ll admit I haven’t looked into any of them in detail since I’m not a user of those languages. On the other hand I am a user of Debian, and I know that they don’t accept any packages that aren’t signed by their maintainers using GPG, which IMO is a big step up over just using MFA for login.
Debian gets to do what they do because they’re not an open-to-the-public repository for publishing. To get a package into Debian you specifically have to go through a small set of trusted gatekeepers who use their credentials, and have been vetted by the Debian project.
A public repository that lets anyone with a package sign up and start distributing simply cannot do that level of verification and vetting on every single package uploader, which is why they don’t do it.
Maybe Debian-level packaging curation is the solution to the recent high-profile open-source supply chain problems. Drew DeVault certainly thinks so. Unlike him, though, I think language-specific package managers have their place, particularly because they support platforms that aren’t free Unix-likes. Perhaps PyPI, npm, cargo, etc. should have subsets of their packages that are heavily curated as in the distro package managers, and some of us could start restricting our dependencies to those subsets. I would contribute some money to help make this happen.
In my head, npm, Maven Central, Rubygems, and PyPi are all big enough to have multiple full-time professional staff employed to run them, but I’ll admit I haven’t looked into any of them in detail since I’m not a user of those languages.
I’m unsure about Maven, but the rest of them are underfunded infra mostly driven by volunteers.
As much as I disagree with the post, I think it’s pretty fair and not ironic. They acknowledge that the change is in the index and its users’ interest. They just want a different solution and make their opinion public. If more people agree, maybe someone will be motivated enough to run it.
I think the somewhat inflammatory tone of the post (understandable, IMHO, we’ve all had frustrating days…) hides a good part of the problem here.
When you see something labeled “critical”, it’s impossible not to raise the age-old question of “who is this critical for?”
The obvious answer is that this is critical for other independent software developers who work in these things in their spare time, and it sounds like if you don’t do your part, you’re a bit of an ass. After all, the community can benefit from it.
But the other answer that we all know and loathe is that this is critical for a whole lot of companies that rely on it for commercial services. This is an understandable part of open source, I mean, the software’s released under a free license for a reason. Not that this is mutually exclusive with the other one. They can both be true, but that doesn’t make this other answer vanish.
So of all the things that the “critical” label could come with – funding for infrastructure and development, coordinated QA efforts, or at least a bloody plush cat with a sign saying “Thank you for your critical contribution”, whatever – it had to come with… more requirements for maintainers, who weren’t even asked if they wanted their packages to get into the program. It cannot be surprising that some of them now have a detailed map for where whoever came up with this can stick their critical stuff.
I’ve seen a lot of “cake-having and -eating” in the arguments against this pypi change. I’d say it’s actually typically true that devs choose to have a critical package. They build it, document it for others, release it, advertise it, maintain it for years and years, constantly establishing reliability. If they didn’t, the project would wither into obscurity like the other 99.9% of pypi projects. These devs benefit too. Would we be reading this blog if not for the reputation of the author? Critical packages bring power and influence. And centralized, trusted package indexes help achieve that.
As a result, I don’t think it’s unfair to place a lot of restrictions on abuse of that power and influence (intentional or not). There will always be a push and pull between devs and pypi. It’s healthy to use your power in this arrangement to negotiate a better deal, but it strikes me as entitled when someone who gained significant power and influence with pypi’s help acts like playing by their (scant) rules is some kind of affront.
I posted this before the two threads were merged, but I’m happy to see James Bennett made this same argument but significantly more detailed and well-written! Go read that in the “It goes both ways” section.
I wrote this (making a link in case of merging) as a response to Armin’s post and discussion over here.
Yes, you have responsibilities when you use something like PyPI to release and distribute open-source code. No, 2FA is not too much to ask. Nor would some other things be too much, should PyPI want to start requiring them. And no, PGP still is not the magic solution to everything.
I think the author’s on the right track. The package someone writes may be critical to their own work, but the fact that it has become critical to a community is not the author’s problem. It is the community’s problem. If the community wants a convenient way of pulling critical packages with confidence, that needs to be done on the community level.
This is a solved problem, of course. Someone else mentioned Debian. Having a whole process for software and versions of software to be vetted before being made available via the distro’s channels is the whole point of Linux distributions.
In many cases a package author might also sign up to be the one who does the work of vetting it, but that need not be the case. Maybe it shouldn’t be the case in many cases (“Oh, what a nice pile of money from the NSA! Yes, I’ll certainly add this little patch they sent me.”). But it explicitly separates “I wrote this code, here, someone might like it” from “I take responsibility for this code’s support for the community.”
I feel like the real story here is that pypi is not funded well enough to take on the task of vetting “critical” packages, but everyone who considers a package “critical” to their infrastructure must share the responsibility for keeping it secure.
If you’re throwing something on the internet to be some sort of ”worked for me, good luck” abandonware, for example, you probably should let people know that so they don’t waste their time and yours by sending you bug reports or patches or other contributions.
We do: it’s the ‘software is provided as-is, no warranties, no expectation of fitness for purpose’ etc. clause in the open source license. What, just because it’s a standardized boilerplate text, do people think they can just ignore it and ask for maintainers to declare what it already declared? Unfortunately even OSS veterans suffer from very basic misconceptions.
That legal boilerplate is in the license of so many free software projects (perhaps even the majority?) that is not abandonware and is actively supported by maintainers and a community that it can’t be taken as an indicator of the sentiment you are expecting it too.
The license expresses a stance on legal responsibility. It does not and cannot express a stance on social responsibility, which is an orthogonal concept.
Yes, an orthogonal concept that users like to use to beat OSS devs over the head with because the actual software license gives them no headroom to do so. But not one which carries any weight beyond what each of them imagines it does. Imagine saying that Microsoft should continue supporting Internet Explorer for corporations which keep using it because it has a ‘social responsibility’. It’s the same level of absurdity.
Imagine saying that Microsoft should continue supporting Internet Explorer
Microsoft infamously did continue extending support for old versions of IE, and Windows, on multiple occasions, to cater to corporate users who weren’t upgrading. They’re also notorious for their backwards-compatibility commitments, which are not required by anything I’m aware of in any of their licenses.
So, to me, this looks like another argument in favor of writing Free Software rather than Open Source. Open Source just boils down to free labor, and if writing it weren’t bad enough, you’re left on the hook to provide free maintenance down the road, both of which for companies that you know will never contribute back in any meaningful way. That said, I don’t think existing copyleft Free Software licenses do enough to combat this type of abuse, though I’m also not sure that licenses are the best place to be trying to prevent it.
A response to https://lobste.rs/s/w21yxt/congratulations_we_now_have_opinions_on from James Bennett of Django fame, which I found quite reasonable and covering most of the points raised in the linked discussion. I liked the part about responsibility that we take when we release something.
This post is the most reasonable, well-phrased, polite text I’ve ever seen make me angry.
If he doesn’t owe us anything, then we also don’t owe him anything. Perhaps he’d like to take back his code and the rest of the world can take back all the opportunities and other things he’s been given In exchange.
Sorry, what “we” are you talking about here?
There’s this sort of collectivist view in this post, of open-source as one giant collaborative endeavour, a position with which I disagree strenuously, not to mention how James puts himself subtly in charge of it. No, not only do you not get to demand that Armin does anything, you don’t even get to define what other people should expect Armin to do. Certainly if you want to underhandedly imply that “the world” has these expectations, you need to do a lot more work to support this thesis. Otherwise, well, it was said to not be an asshole, and this runs up against that line for me.
PyPI wanted something from Armin and announced that they would stop allowing Armin to update his package on their index unless Armin complied. Putting aside that this violates the precise “set expectations” rule that this post just espoused, yes, that is where it stops. The next step would then be to fork PyPI, create an alternative “unreviewed” version, or whatever. Or do none of that and just delete your package! Which Armin did! From my point of view, this is the most basic freedom available - the freedom to stop interacting with people for any reason at any time, but certainly at least if they try to change the rules on you.
In addition, this post smacks of victim olympics. “Armin says he is the victim, but actually look at how poor and overworked PyPI are, and how much Asshole Armin has profited!” Even putting aside the matter of the facts, this is not how this issue, or any issue should ever be decided. Is it the core of the post? No, but then it shouldn’t be in there at all. It adds only bad taste.
Or do none of that and just delete your package! Which Armin did!
Armin didn’t delete any of his packages from PyPI that I’m aware of.
Putting aside that this violates the precise “set expectations” rule that this post just espoused, yes, that is where it stops.
And PyPI is setting expectations — they’re announcing a policy change well ahead of time through multiple communication channels (remember, the timeline is “coming months”). As I suggested in the post, the basic social obligation is to communicate such things to one’s users.
In addition, this post smacks of victim olympics. “Armin says he is the victim, but actually look at how poor and overworked PyPI are, and how much Asshole Armin has profited!”
Armin has had a successful career culminating, so far, in a Director of Engineering post at a notable tech company, almost certainly due in large part to his open source involvement. PyPI is a chronically understaffed project supported by a non-profit and by volunteers. If we are going to talk about overburdened open source maintainers, the PyPI team are closer to that description than Armin is.
There’s this sort of collectivist view in this post, of open-source as one giant collaborative endeavour
If you can explain to me how open source isn’t collaborative by definition, I’m all ears. But like I said: it’s a social activity. It literally makes no sense outside of a social context, and the entire point of Open Source (the uppercased form) is that multiple people collaborating can produce better software than any one of them working alone.
You seem not to like that it’s social/collaborative, or perhaps not to like some of the consequences of it being that way, but I can’t help with that.
Oh, fair enough, I must have misremembered that he deleted it. Probably mixing it up with something else.
And PyPI is setting expectations — they’re announcing a policy change well ahead of time through multiple communication channels
Fair enough, though I’m genuinely unsure if this is sufficient. By the same logic here, if library developers have a responsibility, surely repository maintainers have a much greater responsibility because they’re the point of access for many libraries, and also have network effects buoying them.
If we are going to talk about overburdened open source maintainers, the PyPI team are closer to that description than Armin is.
I think my main disagreement here is that it’s not a question of charity or acceptable burdens. Each person has the right to set their own level of acceptable effort at any point they like. Armin saying he feels overburdened by this is not at all affected by the PyPI maintainers also being overburdened; it’s not a zero-sum competition. Armin is not asking for our charity, he is providing a rationale, though he was not obligated to.
If you can explain to me how open source isn’t collaborative by definition, I’m all ears.
I think that there’s different kinds of collaborative efforts, and open source is a rule-driven one. Our projects literally have legal documents describing acceptable interactions as defining traits and points of contention. (GPL vs BSD, fight!) My view is that “open source” is first and foremost a collection of software with certain traits and licenses, and only dimly and secondarily a collection of people. Actually, the intense thing- and rule-focus is something that I appreciate about it!
Armin saying he feels overburdened by this is not at all affected by the PyPI maintainers also being overburdened; it’s not a zero-sum competition.
If you insist on phrasing it in these terms, it comes down to this: you’re going to overburden somebody, now pick who you’ll do it to. I pick not overburdening the PyPI maintainers, for a variety of reasons.
My view is that “open source” is first and foremost a collection of software with certain traits and licenses, and only dimly and secondarily a collection of people
The software doesn’t exist without the people, and the licenses are there to set baseline expectations for the way the people will interact with the software and with each other.
Like, if there were an apocalypse tomorrow and you were the last person left on earth and you sat down and wrote some software and slapped a BSD license on it, there would be no meaningful sense in which you were doing “open source”, because there would be nobody else to share it or collaborate on it with. Open source is made of people and is a social activity.
Sure, but that goes for any rule-driven activity where the rules are phrased in language. Rules are always implemented on human minds; the point of rules is that you want to take the ambiguity of those human minds out of the equation. Else, every license could just read: “Do the right thing.” Inasmuch as it’s social, it’s anti to start.
If you insist on phrasing it in these terms, it comes down to this: you’re going to overburden somebody, now pick who you’ll do it to. I pick not overburdening the PyPI maintainers, for a variety of reasons.
I believe - as a statement of what I consider justice - that there’s a foundational right to avoid overburdening yourself in any voluntary activity. Any reduction of burden on any other person is nice, but strictly supererogatory. Simply put, that’s not your job.
If people want to throw abandonware tarballs on the internet, disclaim any and all “maintainership”, and walk away, that’s their right and they can and should do that. And if “please take a bare-minimum baseline level of responsibility for securing your package-index account” is overburdening to someone, then they can and should walk away.
But the issue here really is people who want to try to have it both ways. They want the benefits that come from participating in the larger ecosystem around Python and PyPI — which can include everything from just occasional people helping out and contributing back, up to the sort of lottery-winner situation of people like Armin or myself where it basically makes your whole career for you. But they want it to be a one-way thing, and it isn’t and can’t be a one-way thing.
Meanwhile, unmaintained/abandonware/“throw a tarball over the wall” packages don’t hit top 1% by accident in the Python world. Flask, for example, wasn’t some teeny-tiny barely-ever-did-anything-with-it side project of Armin’s that he woke up one day and found out had become popular without his knowledge — that was the result of years of maintaining it, of documenting it, of evangelizing it, of cultivating a community around it. And if someone wants that, then they want that, but it absolutely does come with social obligations and expectations. Like, say, protect the community of users you’ve cultivated for your package by enabling 2FA on your package-index account. And notably, Armin did in fact hand Flask over to other people to maintain, and from what I hear they’re doing a good job of it. If he doesn’t want PyPI to ask him to secure his account, he could always remove himself from the project. Of course, then he loses some of the cachet of continued involvement/ownership of it, but just as he would say he doesn’t owe anybody else anything, nobody else owes him that on a continuing basis.
Like, say, protect the community of users you’ve cultivated for your package by enabling 2FA on your package-index account.
The point I’d argue here is that it’s not for you - and arguably not even for PyPI! Though the PyPI people may and do disagree, and their disagreement has power as they run the project - to get between Armin and his community and tell them what level of safety is acceptable for them. They’re, presumably, mostly adults; they can take responsibility for their own safety standards.
If he doesn’t want PyPI to ask him to secure his account, he could always remove himself from the project.
Or remove the project from the index. Or argue against the decision but go along with it. I think it’s not your place to delineate in advance how people are allowed to respond. The choice of how to move forward lies solely with PyPI and Armin, and I don’t believe that’s anywhere near the only option on offer.
Of course, then he loses some of the cachet of continued involvement/ownership of it, but just as he would say he doesn’t owe anybody else anything, nobody else owes him that on a continuing basis.
Agreed - what raises my hackles is the article adopting an “us vs Armin” framing. “Us” does not exist! “Nobody else” is not a coherent group! Taking a contentious topic and implicitly saying “this should not be contentious, so I’ll blithely assume to speak for everyone else who, of course, agrees with me” is just not good behavior.
If Armin has chosen to put his package on PyPI, then it absolutely is PyPI’s prerogative to “get between him and his community”, except that really it’s about being between him and the Venn diagram of (people who use Armin’s packages) x (people who use PyPI as a package source).
And I strongly suspect he wants access to the relative ease (compared to alternatives) of distribution PyPI offers, and the relatively large (compared, again, to alternatives) audience which becomes instantly accessible when a package is on PyPI. Which is just another thing that busts the whole maintainer-only perspective — 2FA is not even really being “demanded” of him since he can opt out of PyPI, and he’s getting tangible benefits as a user of PyPI that he wouldn’t get, or wouldn’t get as easily, from using an alternative distribution mechanism. It’s very much a multi-way relationship with benefits for him and for PyPI and for other users of PyPI.
“Us” does not exist! “Nobody else” is not a coherent group!
The only way this makes sense is if it also implies that groups like “package maintainers” or “open source developers” don’t exist. I haven’t seen you going after anyone for mentioning such groups in other comments, though.
Some famous people vehemently criticised my effort in the name of security.
My career has been noticeably and positively impacted by this work.
In security circles, people are keenly aware of negative externalities. It is most obvious in cryptography where the knee-jerk reaction is “don’t roll your own crypto!!” (which I disagree with by the way), but it also applies to pretty much anything that at some point has to handle adversarial input. Even simple bugs have a significant negative impact when you have enough users. The benefits of your code better be greater than the curse of its bugs, otherwise you’re just polluting the internet with your crap.
Back to my cryptographic library, if instead of releasing it seriously I wrote a toy just so I could learn, I would have learned less, and I would have had less professional opportunities. But I would also wouldn’t have the associated responsibilities, and I would certainly wouldn’t have had the criticism and contempt I’ve had from a couple people.
Still, it was all worth it. If I had to do it all over again, I would.
Indeed, the post has an inkling of contempt for Armin. And the irony is palpable; it is easy to imagine that Armin might “choose not to maintain software for you, in the exact form you personally prefer, for free, forever, anymore,” (PyPI towards PyPy) at which point, “the rest of the world can take back all the opportunities and other things he’s been given In exchange.” (PyPI towards Armin)
PyPI is a luxury, not a necessary component of a collaborative ecosystem. I would be willing to directly give git repositories to pip and pin my own hashes, like when I use Gentoo or Nix. Delivering a Python supply chain is cool, but nobody’s paying Armin for their part in it.
As always I’d like to link people to the full evidence of my villainy. I’m amazed not to have been banned from the site for such awful behavior, but perhaps standards are slipping everywhere.
Anyway, I don’t see why it’s ironic to take the argument being made by people like Armin, and extend it to its logical conclusion — if he literally owes us nothing, we literally owe him nothing, and there’s nothing inconsistent in pointing that out.
This also doesn’t contradict anything I ever said about the majority of the Python community moving on from supporting Python 2. You are free to withdraw your contributions as retaliation for me no longer supporting Python 2, if you so choose. The rest of us gave it an extremely extended support period, communicated our plans and set expectations accordingly, and then moved on. If anything, that harmonizes nicely with what I described in the post as basic social obligations around open source.
Delivering a Python supply chain is cool, but nobody’s paying Armin for their part in it.
I devoted a bit of space in the article to explaining that Armin most certainly has benefited significantly from his open source work. As have I. Claiming that “nobody’s paying” is disingenuous in light of that.
Anyway, I don’t see why it’s ironic to take the argument being made by people like Armin, and extend it to its logical conclusion — if he literally owes us nothing, we literally owe him nothing, and there’s nothing inconsistent in pointing that out.
I agree with this, but it seems to me the post went significantly beyond this. Armin’s position is not some sort of “reward for services rendered” for his open-source work. It’s an effect, not a trade-in. Even putting aside the nonexistent “we.”
There’s no way around “we don’t owe him anything”. Even if you claim that there’s never any sort of hope on the part of maintainers that their open-source work will further their career, that just means any furthering of their career which does come out of it must be a no-obligation-to-the-giver gift to the maintainer, which can be “ungiven” at any time just as it was initially given.
Sure, and any PyPI maintainer can quit at any time, or make any change they like (within the bounds of that project’s governance structure). My disagreement is with the idea that first, there’s an implicit reciprocity, and second, that the author assumes to speak for “the community.”
I agree that the PyPI people can do this. So does Armin! I further think he’s under no obligation to like it, or go along with it. Not to overreach, but I think we’re all here voluntarily, contributing our free time because we want open source software to exist and have certain features. It’s not a compact, except in the precise sense laid out in the license. Anyone can leave at any time. As a matter of courtesy, we appreciate when people give early warnings, and may get upset when they don’t, but anything beyond that is in the realm of debate. And it poisons any debate to fill it with nebulous threats like “nice career you have there, shame if something were to happen to it.”
edit PS:
One of the most pleasing things about opensource to me is that if everybody in the world were to stop working on it, my computer would still run. I could still edit the source of my installed programs, I could still rebuild them, I could still share my changes with others (should there be others again), there is no single point of failure or central organization to which I am beholden. All the teams and projects and companies in the world cannot take away from my ability to run my system as I see fit. And this power was given to me freely, not in hope of reward, but simply because people thought that this was the way the world ought to work. The Four Freedoms are not a means to an end, they themselves are the end. Now I do agree that the development of open source is a largely social activity, but it’s an activity that fundamentally starts from a position of freedom to act on your own, without approval, and should be seen as colored by it. There’s a reason Git baked forking directly into the workflow.
My point is: Nothing about Armin’s position is somehow “out of line” with open source.
And it poisons any debate to fill it with nebulous threats like “nice career you have there, shame if something were to happen to it.”
If someone wants the benefits of participation in open source, they need to… y’know, actually be willing to participate. Which is a messy social activity defined and redefined by human interactions, rather than a legal activity exhaustively summarized by the clauses of a particular software license. Some projects, for example, impose requirements on how others can participate in their development process, their governance, their discussion forums, and so on. None of which are found in the project’s LICENSE file, which should in turn be a big big hint that there may be more expectations than are conveyed by just the license.
The 2FA requirement allows either TOTP authenticator apps or hardware keys, and PyPI has received coupon codes for a few thousand free hardware keys from Google which they are distributing to package maintainers who hadn’t already enabled 2FA.
I’m firmly in the “you don’t owe anyone a single thing” in open source camp, and I believe you should be able to throw your code out into the world and not give a shit what happens. But James is obviously correct when he says that mantra has to be applied equally to the pypi maintainers who are free to dictate mfa as a bare-minimum security practice for packages they handle, and therefore that truly does just end the conversation.
Even more the pypi maintainers are free not to deal with cracked accounts anymore because people are too lazy to use good password management. And there are two options: Enforce 2FA or simply let the cracked accounts run rampage.
Astonishing to me that this is somehow controversial to some people. Running a package index is really hard, thankless work, and when they do the most basic thing to protect themselves, developers throw a fit.
I agree and want to add that despite some regulations this is also true for commercial and closed source software and product’s in general.
Most services have something along the lines of “we can turn it off at any point and may delete your account at any time for any reason”. On top of that software for various reasons might stop eorking, because servers are shit down, even Google is famous for shutting down services, stopping to maintain software because they don’t want to pursue it.
In fact open source with no obligations gives you more guarantees cause you might fork or incorporate it, so are a lot more independent of creators and providers in just situations. Even when it’s just randomly put out there. Good luck trying to do that with any other product even if the company is dead it might sometimes be outright illegal.
One might say that there’s contracts in the commercial field, but other than one often being dependent in one direction while the other side bring able to just terminate you (GitHub if you do more than just code hosting), you might also just do contacts in open source.
I think we are lying when we act that this is somehow just a thing with open source when for the most part commercial products also come with very little a compy owes you. Any cloud provider even Google and Amazon can at least in theory just drop offering that service. Or force you to upgrade into something or change plans, etc. And unlike with open source you might not be able to just stick with what you have.
And for open source it’s the same. I would also argue that even when zero rules if there’s more than one dev or even just enough technically versed users you have more likely long time support than with even big companies, espt for things like smart devices, but even in must other areas.
And I think it will become worse, because the goal is to bind customers, upsell them, etc. For much open source that’s not the incentive and if it changes you might just fork. A relatively young example is Mapbox and Maplibre
Under one critical condition: say so. Make it clear that you’re releasing the stuff as-is, and that for real this time, there is no guarantee. Write this in the most obvious place possible: landing page, README…
If you don’t, I will judge you.
That would be nice but it can’t be all that critical a condition if most open source I come into contact with (eg npm packages) is unacknowledged abandonware, and the world keeps on turning.
My advice is that you invert your expectations.
I’m more in contact with cryptographic code on GitHub, for which the standards are… well, stringent enough that people sometimes nuke their code when I point out a bug.
That is indeed a VERY different world that should come with very different expectations for sure :)
I still don’t get why some people mix software development and software maintaining. Security guarantees are quite logical move if you’re part of a supply chain that is being used by people.
If I want to just make stuff I’ll only put it on a public repo and it is up to someone else to find it and incorporate if it is useful. Including that piece of software into some sort of repository - being so pypi or openbsd packages - is a completely different matter, and just as writing useful software includes obvious things “it has to build/work” the supply chain integration requires a verification and increased security/audit measures.
I want my code to be used by people, but I specifically don’t want it to be “part of a supply chain”. The open source world seems to have gotten into this extremely concerning state over the last decade where somebody’s hobby project or personal library that they threw out there for other hobbyists to use can be part of the infrastructure of a billion dollar corporation, and worse, that they are now somehow in a quasi-contractual relationship with said corporation.
There are a bunch of intertwined social and technical problems going on here, but one of them is certainly that the “everyone can publish to the same centralized package repository” system of package management simply shouldn’t exist. I’m as guilty as anyone of using them, but in retrospect, they’re clearly a bad idea. The other biggest problem is the recuperation of the radical potential of Free Software by capitalism as Open Source. Developers need to step up and insist that the commons is not a supply-chain.
If you want to write and release software that nobody is ever allowed to use in any commercial endeavor, you can accomplish that via licensing, but even the Free Software movement generally frowns on licenses which discriminate based on fields of endeavor, and prefers to just use things like the AGPL which accomplish the same end result via other means (sometimes too well, given that the AGPL is now ironically popular as a way to use copyright to enforce a monopoly on commercial exploitation).
And like I said in the post, if some “billion dollar corporation” gets a bit of benefit from something that also protects people who have far less resources to secure their projects, I am willing to accept that as the cost of protecting the other people. I’ve made peace with the fact that it’s hard and perhaps impossible to serve the underserved without creating the opportunity for at least a few free riders to get something they could have otherwise afforded.
Meanwhile, centralized services of all sorts, not just package indexes, are not going to go away any time soon, because social forces inevitably push us back to centralizing over and over again.
And it’s easier still to post a non sequitur quote and hope nobody notices it didn’t actually address any of the points made.
You’re always free to distribute a tarball, but package repositories ought to look out for the health of the overall ecosystem. I don’t think MFA is that onerous (neither was the GPG key I grumbled about for maven), but even if it is, better to suffer it.
The sooner we stop romanticizing open source development, the better for everyone.
That’s the only reason Open Source exists; the thought of freedom, creativity and providing value to the world. If you take that away, the only thing left is “work for free”, which I guess not a lot of people want to do.
Well, “work for free” and “provide value to the world” are the same thing in a lot of situations. If you opt to submit your work to a package index, then you are really steering to the “work for free” direction and not in the “freedom” and “creativity” direction.
The latter two would indeed be better served by a tarball or repository. Write some blog posts about it and submit it to communities for discussion, then you can provide value through creativity.
The problem here is perhaps not that obvious. But I am thinking about this angle. When you compare this to the “app stores”, it becomes clear. Epic games wants to sue Apple and Google for taking 30% cut. You can’t buy e-books through the Android Kindle App any more. Google and Apple get to decide what is “critical”, what is “spam” and everything in between. They already do that, more or less, but it isn’t to say that the system is flawless.
But the kicker in that case is, any app developer NOT publishing on the app stores absolutely has no chance. Play/App Stores hold monopolies in their respective ecosystems, and for any chance of global success, you can’t make it without them, and have to go by their rules.
Now, apply that back to pypi. Or npmjs.com. Or any such centralised package. If you’re not using them, your package has a lot, lot less influence. You can provide a lot less “value to the world”. For some niches, probably no value, since the not-so-good alternative is in the index and gets used instead, and your “value to the world” is totally wasted.
Then again, running an index - or an app store - costs resources. If those that invest the resources get some benefits - like setting their own rules - then they should be able to. If you want, you’re free to run your own index. Invest a lot of money, time and work into maintaining it, marketing it, making it so awesome that people WANT to come etc.
The answer to any question in this industry seems to always be “it depends”.
I think you’re both totally correct. Romanticizing open source is both detrimental to its well being and is also the only reason for it to exist. It lives in a perpetual state of self sabotage and we love it, sometimes for that reason.
(I think I just romanticized the self-sabotaging nature of romanticizing open source)
Thanks for this, your phrasing of the three values really is helpful.
What I referred to as the romantic view is probably best thought of as neglecting the tension between freedom, creativity and providing value. It seems like you can have all three, but there will be choices. Providing value means managing a community, enabling MFA and generally spending a lot of time on boring problems.
Here’s my TL;DR.
“Dude, your stuff – the product of your work that you gave away for free – has gotten so important that we’re going to ask you to do extra free labor above and beyond what we require of everyone else.”
Among many possible responses, “fuck that, I don’t wanna” is perfectly reasonable.
That is the crux of the matter. Any discussion of MFA or the like is really missing the point. The problem isn’t with requiring MFA. The problem is with waking up one day to be told that you have to do some extra unpaid work above and beyond what is being asked of most other contributors, because your work is now considered “critical”.
As a lifelong contrarian whose motto is “I don’t wanna”, I totally get this piece.
Calling MFA “extra free labor” is quite the stretch. I would rather they just enforce MFA to publish to the platform altogether.
That point was hammered home both in the article and in my TL;DR. To MFA or not to MFA is not the issue at hand.
From my faithful dict client:
I think “exertion of strength or faculties … not subject to the will” certainly fits the topic under discussion.
Is it reasonable for pypi to ask for MFA for everyone? Extremely. Is it reasonable for pypi to require MFA specifically from authors of “critical” packages? I suppose so. Is it reasonable to be upset about being asked all of a sudden to go the extra mile because your package becomes “critical”? Yep. If you answered no to the third, then maybe you have a vision for free software that differs from my own.
I disagree that MFA is going an extra mile. It’s kind of a bare minimum security posture in today’s age.
Well, that all depends on your threat model. See the MFA thread. As I’ve said I’m willing to grant that MFA is a reasonable requirement.
One person’s “a little nothingburger of an ask” may well be another’s burden. I had a cardiac event last fall. They had to shock my heart back into a normal rhythm, and I also required heart surgery. I have 30% cardiac function today. I don’t have near the spoons I used to have. If someone feels put-upon, listen to them, because you don’t know what their struggles are.
Maybe package indices are not a good pattern for distributing Free Software.
It’s closer than before tho. I think we need to separate the indexes from the machinery of package management before we can hone in on the next step though. Allow for example somebody like jfrog or similar to easily run their own indexes and/or additional vetting etc without having to replace the mechanics on devs’ workstations. You could set up your own index for your shop, or pay somebody to run an index of blessed and known-good-together packages, or any number of other things I haven’t thought up yet.
Sure. I specifically am concerned about attribution and assignment of namespaces. Every package index is a namespace, creating an economy where some names are more valuable than others and there is a natural scarcity of short/memorable/easy/branded names. This is not a healthy pattern for a software commons.
I want to imagine Free Software which doesn’t care who wrote it. The software has the appropriate license, and the precise identity of the author would not alter the rights granted to the user, so the packaging system’s design should trade off a precise identity for other possible benefits. One obvious benefit is that there is no longer an artificial division between standard libraries and third-party libraries.
The irony of complaining about restrictions imposed on an open source project by a freely-run package index is just to much.
On the other hand, holy shit, PyPI let’s you publish packages without MFA? I knew python packaging was bad but I didn’t know it was that bad.
I don’t really understand this part. Several ecosystems does not enforce MFA and this has been common for years, why are we suddenly regarding this as an absolute requirement for publishing?
Several package managers read directly from git repos (pip included), and github does not enforce anything either.
Oh dear. Ohhhhhh dear.
I guess it’s been a long time since I used any package repository other than Clojars. That one is relatively small but it’s required MFA for a few years now so I just assumed the more professional ones had been … well, professional about it. I certainly wouldn’t trust a package repository that treated it as optional.
Which professional ones are these that you’re thinking of?
In my head, npm, Maven Central, Rubygems, and PyPi are all big enough to have multiple full-time professional staff employed to run them, but I’ll admit I haven’t looked into any of them in detail since I’m not a user of those languages. On the other hand I am a user of Debian, and I know that they don’t accept any packages that aren’t signed by their maintainers using GPG, which IMO is a big step up over just using MFA for login.
npm currently requires MFA for maintainers of the top 500 most popular packages and will be expanding that. Sounds similar to PyPi. More info here: https://github.blog/2022-05-10-enhanced-2fa-experience-for-your-npm-account/
Debian gets to do what they do because they’re not an open-to-the-public repository for publishing. To get a package into Debian you specifically have to go through a small set of trusted gatekeepers who use their credentials, and have been vetted by the Debian project.
A public repository that lets anyone with a package sign up and start distributing simply cannot do that level of verification and vetting on every single package uploader, which is why they don’t do it.
Yeah, I understand the situation isn’t applicable to PyPi; it’s just an example of how having higher standards earns you a lot more trust.
Maybe Debian-level packaging curation is the solution to the recent high-profile open-source supply chain problems. Drew DeVault certainly thinks so. Unlike him, though, I think language-specific package managers have their place, particularly because they support platforms that aren’t free Unix-likes. Perhaps PyPI, npm, cargo, etc. should have subsets of their packages that are heavily curated as in the distro package managers, and some of us could start restricting our dependencies to those subsets. I would contribute some money to help make this happen.
I’m unsure about Maven, but the rest of them are underfunded infra mostly driven by volunteers.
Huh. I thought I remember reading a while back about npm, inc being a thing, and how they took venture capital or something.
NPM Inc is owned by GitHub now.
Ah, I forgot about this actually :)
As much as I disagree with the post, I think it’s pretty fair and not ironic. They acknowledge that the change is in the index and its users’ interest. They just want a different solution and make their opinion public. If more people agree, maybe someone will be motivated enough to run it.
[Comment removed by author]
I think the somewhat inflammatory tone of the post (understandable, IMHO, we’ve all had frustrating days…) hides a good part of the problem here.
When you see something labeled “critical”, it’s impossible not to raise the age-old question of “who is this critical for?”
The obvious answer is that this is critical for other independent software developers who work in these things in their spare time, and it sounds like if you don’t do your part, you’re a bit of an ass. After all, the community can benefit from it.
But the other answer that we all know and loathe is that this is critical for a whole lot of companies that rely on it for commercial services. This is an understandable part of open source, I mean, the software’s released under a free license for a reason. Not that this is mutually exclusive with the other one. They can both be true, but that doesn’t make this other answer vanish.
So of all the things that the “critical” label could come with – funding for infrastructure and development, coordinated QA efforts, or at least a bloody plush cat with a sign saying “Thank you for your critical contribution”, whatever – it had to come with… more requirements for maintainers, who weren’t even asked if they wanted their packages to get into the program. It cannot be surprising that some of them now have a detailed map for where whoever came up with this can stick their critical stuff.
I’ve seen a lot of “cake-having and -eating” in the arguments against this pypi change. I’d say it’s actually typically true that devs choose to have a critical package. They build it, document it for others, release it, advertise it, maintain it for years and years, constantly establishing reliability. If they didn’t, the project would wither into obscurity like the other 99.9% of pypi projects. These devs benefit too. Would we be reading this blog if not for the reputation of the author? Critical packages bring power and influence. And centralized, trusted package indexes help achieve that.
As a result, I don’t think it’s unfair to place a lot of restrictions on abuse of that power and influence (intentional or not). There will always be a push and pull between devs and pypi. It’s healthy to use your power in this arrangement to negotiate a better deal, but it strikes me as entitled when someone who gained significant power and influence with pypi’s help acts like playing by their (scant) rules is some kind of affront.
I posted this before the two threads were merged, but I’m happy to see James Bennett made this same argument but significantly more detailed and well-written! Go read that in the “It goes both ways” section.
You can’t unilaterally gain obligation by being given things.
I wrote this (making a link in case of merging) as a response to Armin’s post and discussion over here.
Yes, you have responsibilities when you use something like PyPI to release and distribute open-source code. No, 2FA is not too much to ask. Nor would some other things be too much, should PyPI want to start requiring them. And no, PGP still is not the magic solution to everything.
I think the author’s on the right track. The package someone writes may be critical to their own work, but the fact that it has become critical to a community is not the author’s problem. It is the community’s problem. If the community wants a convenient way of pulling critical packages with confidence, that needs to be done on the community level.
This is a solved problem, of course. Someone else mentioned Debian. Having a whole process for software and versions of software to be vetted before being made available via the distro’s channels is the whole point of Linux distributions.
In many cases a package author might also sign up to be the one who does the work of vetting it, but that need not be the case. Maybe it shouldn’t be the case in many cases (“Oh, what a nice pile of money from the NSA! Yes, I’ll certainly add this little patch they sent me.”). But it explicitly separates “I wrote this code, here, someone might like it” from “I take responsibility for this code’s support for the community.”
I feel like the real story here is that pypi is not funded well enough to take on the task of vetting “critical” packages, but everyone who considers a package “critical” to their infrastructure must share the responsibility for keeping it secure.
We do: it’s the ‘software is provided as-is, no warranties, no expectation of fitness for purpose’ etc. clause in the open source license. What, just because it’s a standardized boilerplate text, do people think they can just ignore it and ask for maintainers to declare what it already declared? Unfortunately even OSS veterans suffer from very basic misconceptions.
That legal boilerplate is in the license of so many free software projects (perhaps even the majority?) that is not abandonware and is actively supported by maintainers and a community that it can’t be taken as an indicator of the sentiment you are expecting it too.
In the absence of any overriding communications, however, it should take precedence.
The license expresses a stance on legal responsibility. It does not and cannot express a stance on social responsibility, which is an orthogonal concept.
Yes, an orthogonal concept that users like to use to beat OSS devs over the head with because the actual software license gives them no headroom to do so. But not one which carries any weight beyond what each of them imagines it does. Imagine saying that Microsoft should continue supporting Internet Explorer for corporations which keep using it because it has a ‘social responsibility’. It’s the same level of absurdity.
Microsoft infamously did continue extending support for old versions of IE, and Windows, on multiple occasions, to cater to corporate users who weren’t upgrading. They’re also notorious for their backwards-compatibility commitments, which are not required by anything I’m aware of in any of their licenses.
So, to me, this looks like another argument in favor of writing Free Software rather than Open Source. Open Source just boils down to free labor, and if writing it weren’t bad enough, you’re left on the hook to provide free maintenance down the road, both of which for companies that you know will never contribute back in any meaningful way. That said, I don’t think existing copyleft Free Software licenses do enough to combat this type of abuse, though I’m also not sure that licenses are the best place to be trying to prevent it.
A response to https://lobste.rs/s/w21yxt/congratulations_we_now_have_opinions_on from James Bennett of Django fame, which I found quite reasonable and covering most of the points raised in the linked discussion. I liked the part about responsibility that we take when we release something.
This post is the most reasonable, well-phrased, polite text I’ve ever seen make me angry.
Sorry, what “we” are you talking about here?
There’s this sort of collectivist view in this post, of open-source as one giant collaborative endeavour, a position with which I disagree strenuously, not to mention how James puts himself subtly in charge of it. No, not only do you not get to demand that Armin does anything, you don’t even get to define what other people should expect Armin to do. Certainly if you want to underhandedly imply that “the world” has these expectations, you need to do a lot more work to support this thesis. Otherwise, well, it was said to not be an asshole, and this runs up against that line for me.
PyPI wanted something from Armin and announced that they would stop allowing Armin to update his package on their index unless Armin complied. Putting aside that this violates the precise “set expectations” rule that this post just espoused, yes, that is where it stops. The next step would then be to fork PyPI, create an alternative “unreviewed” version, or whatever. Or do none of that and just delete your package! Which Armin did! From my point of view, this is the most basic freedom available - the freedom to stop interacting with people for any reason at any time, but certainly at least if they try to change the rules on you.
In addition, this post smacks of victim olympics. “Armin says he is the victim, but actually look at how poor and overworked PyPI are, and how much Asshole Armin has profited!” Even putting aside the matter of the facts, this is not how this issue, or any issue should ever be decided. Is it the core of the post? No, but then it shouldn’t be in there at all. It adds only bad taste.
Armin didn’t delete any of his packages from PyPI that I’m aware of.
And PyPI is setting expectations — they’re announcing a policy change well ahead of time through multiple communication channels (remember, the timeline is “coming months”). As I suggested in the post, the basic social obligation is to communicate such things to one’s users.
Armin has had a successful career culminating, so far, in a Director of Engineering post at a notable tech company, almost certainly due in large part to his open source involvement. PyPI is a chronically understaffed project supported by a non-profit and by volunteers. If we are going to talk about overburdened open source maintainers, the PyPI team are closer to that description than Armin is.
If you can explain to me how open source isn’t collaborative by definition, I’m all ears. But like I said: it’s a social activity. It literally makes no sense outside of a social context, and the entire point of Open Source (the uppercased form) is that multiple people collaborating can produce better software than any one of them working alone.
You seem not to like that it’s social/collaborative, or perhaps not to like some of the consequences of it being that way, but I can’t help with that.
Oh, fair enough, I must have misremembered that he deleted it. Probably mixing it up with something else.
Fair enough, though I’m genuinely unsure if this is sufficient. By the same logic here, if library developers have a responsibility, surely repository maintainers have a much greater responsibility because they’re the point of access for many libraries, and also have network effects buoying them.
I think my main disagreement here is that it’s not a question of charity or acceptable burdens. Each person has the right to set their own level of acceptable effort at any point they like. Armin saying he feels overburdened by this is not at all affected by the PyPI maintainers also being overburdened; it’s not a zero-sum competition. Armin is not asking for our charity, he is providing a rationale, though he was not obligated to.
I think that there’s different kinds of collaborative efforts, and open source is a rule-driven one. Our projects literally have legal documents describing acceptable interactions as defining traits and points of contention. (GPL vs BSD, fight!) My view is that “open source” is first and foremost a collection of software with certain traits and licenses, and only dimly and secondarily a collection of people. Actually, the intense thing- and rule-focus is something that I appreciate about it!
If you insist on phrasing it in these terms, it comes down to this: you’re going to overburden somebody, now pick who you’ll do it to. I pick not overburdening the PyPI maintainers, for a variety of reasons.
The software doesn’t exist without the people, and the licenses are there to set baseline expectations for the way the people will interact with the software and with each other.
Like, if there were an apocalypse tomorrow and you were the last person left on earth and you sat down and wrote some software and slapped a BSD license on it, there would be no meaningful sense in which you were doing “open source”, because there would be nobody else to share it or collaborate on it with. Open source is made of people and is a social activity.
Sure, but that goes for any rule-driven activity where the rules are phrased in language. Rules are always implemented on human minds; the point of rules is that you want to take the ambiguity of those human minds out of the equation. Else, every license could just read: “Do the right thing.” Inasmuch as it’s social, it’s anti to start.
I believe - as a statement of what I consider justice - that there’s a foundational right to avoid overburdening yourself in any voluntary activity. Any reduction of burden on any other person is nice, but strictly supererogatory. Simply put, that’s not your job.
If people want to throw abandonware tarballs on the internet, disclaim any and all “maintainership”, and walk away, that’s their right and they can and should do that. And if “please take a bare-minimum baseline level of responsibility for securing your package-index account” is overburdening to someone, then they can and should walk away.
But the issue here really is people who want to try to have it both ways. They want the benefits that come from participating in the larger ecosystem around Python and PyPI — which can include everything from just occasional people helping out and contributing back, up to the sort of lottery-winner situation of people like Armin or myself where it basically makes your whole career for you. But they want it to be a one-way thing, and it isn’t and can’t be a one-way thing.
Meanwhile, unmaintained/abandonware/“throw a tarball over the wall” packages don’t hit top 1% by accident in the Python world. Flask, for example, wasn’t some teeny-tiny barely-ever-did-anything-with-it side project of Armin’s that he woke up one day and found out had become popular without his knowledge — that was the result of years of maintaining it, of documenting it, of evangelizing it, of cultivating a community around it. And if someone wants that, then they want that, but it absolutely does come with social obligations and expectations. Like, say, protect the community of users you’ve cultivated for your package by enabling 2FA on your package-index account. And notably, Armin did in fact hand Flask over to other people to maintain, and from what I hear they’re doing a good job of it. If he doesn’t want PyPI to ask him to secure his account, he could always remove himself from the project. Of course, then he loses some of the cachet of continued involvement/ownership of it, but just as he would say he doesn’t owe anybody else anything, nobody else owes him that on a continuing basis.
I agree with the first half of this.
The point I’d argue here is that it’s not for you - and arguably not even for PyPI! Though the PyPI people may and do disagree, and their disagreement has power as they run the project - to get between Armin and his community and tell them what level of safety is acceptable for them. They’re, presumably, mostly adults; they can take responsibility for their own safety standards.
Or remove the project from the index. Or argue against the decision but go along with it. I think it’s not your place to delineate in advance how people are allowed to respond. The choice of how to move forward lies solely with PyPI and Armin, and I don’t believe that’s anywhere near the only option on offer.
Agreed - what raises my hackles is the article adopting an “us vs Armin” framing. “Us” does not exist! “Nobody else” is not a coherent group! Taking a contentious topic and implicitly saying “this should not be contentious, so I’ll blithely assume to speak for everyone else who, of course, agrees with me” is just not good behavior.
If Armin has chosen to put his package on PyPI, then it absolutely is PyPI’s prerogative to “get between him and his community”, except that really it’s about being between him and the Venn diagram of (people who use Armin’s packages) x (people who use PyPI as a package source).
And I strongly suspect he wants access to the relative ease (compared to alternatives) of distribution PyPI offers, and the relatively large (compared, again, to alternatives) audience which becomes instantly accessible when a package is on PyPI. Which is just another thing that busts the whole maintainer-only perspective — 2FA is not even really being “demanded” of him since he can opt out of PyPI, and he’s getting tangible benefits as a user of PyPI that he wouldn’t get, or wouldn’t get as easily, from using an alternative distribution mechanism. It’s very much a multi-way relationship with benefits for him and for PyPI and for other users of PyPI.
The only way this makes sense is if it also implies that groups like “package maintainers” or “open source developers” don’t exist. I haven’t seen you going after anyone for mentioning such groups in other comments, though.
Here’s a couple anecdotes about me:
In security circles, people are keenly aware of negative externalities. It is most obvious in cryptography where the knee-jerk reaction is “don’t roll your own crypto!!” (which I disagree with by the way), but it also applies to pretty much anything that at some point has to handle adversarial input. Even simple bugs have a significant negative impact when you have enough users. The benefits of your code better be greater than the curse of its bugs, otherwise you’re just polluting the internet with your crap.
Back to my cryptographic library, if instead of releasing it seriously I wrote a toy just so I could learn, I would have learned less, and I would have had less professional opportunities. But I would also wouldn’t have the associated responsibilities, and I would certainly wouldn’t have had the criticism and contempt I’ve had from a couple people.
Still, it was all worth it. If I had to do it all over again, I would.
Indeed, the post has an inkling of contempt for Armin. And the irony is palpable; it is easy to imagine that Armin might “choose not to maintain software for you, in the exact form you personally prefer, for free, forever, anymore,” (PyPI towards PyPy) at which point, “the rest of the world can take back all the opportunities and other things he’s been given In exchange.” (PyPI towards Armin)
PyPI is a luxury, not a necessary component of a collaborative ecosystem. I would be willing to directly give git repositories to pip and pin my own hashes, like when I use Gentoo or Nix. Delivering a Python supply chain is cool, but nobody’s paying Armin for their part in it.
As always I’d like to link people to the full evidence of my villainy. I’m amazed not to have been banned from the site for such awful behavior, but perhaps standards are slipping everywhere.
Anyway, I don’t see why it’s ironic to take the argument being made by people like Armin, and extend it to its logical conclusion — if he literally owes us nothing, we literally owe him nothing, and there’s nothing inconsistent in pointing that out.
This also doesn’t contradict anything I ever said about the majority of the Python community moving on from supporting Python 2. You are free to withdraw your contributions as retaliation for me no longer supporting Python 2, if you so choose. The rest of us gave it an extremely extended support period, communicated our plans and set expectations accordingly, and then moved on. If anything, that harmonizes nicely with what I described in the post as basic social obligations around open source.
I devoted a bit of space in the article to explaining that Armin most certainly has benefited significantly from his open source work. As have I. Claiming that “nobody’s paying” is disingenuous in light of that.
I agree with this, but it seems to me the post went significantly beyond this. Armin’s position is not some sort of “reward for services rendered” for his open-source work. It’s an effect, not a trade-in. Even putting aside the nonexistent “we.”
There’s no way around “we don’t owe him anything”. Even if you claim that there’s never any sort of hope on the part of maintainers that their open-source work will further their career, that just means any furthering of their career which does come out of it must be a no-obligation-to-the-giver gift to the maintainer, which can be “ungiven” at any time just as it was initially given.
Sure, and any PyPI maintainer can quit at any time, or make any change they like (within the bounds of that project’s governance structure). My disagreement is with the idea that first, there’s an implicit reciprocity, and second, that the author assumes to speak for “the community.”
I agree that the PyPI people can do this. So does Armin! I further think he’s under no obligation to like it, or go along with it. Not to overreach, but I think we’re all here voluntarily, contributing our free time because we want open source software to exist and have certain features. It’s not a compact, except in the precise sense laid out in the license. Anyone can leave at any time. As a matter of courtesy, we appreciate when people give early warnings, and may get upset when they don’t, but anything beyond that is in the realm of debate. And it poisons any debate to fill it with nebulous threats like “nice career you have there, shame if something were to happen to it.”
edit PS:
One of the most pleasing things about opensource to me is that if everybody in the world were to stop working on it, my computer would still run. I could still edit the source of my installed programs, I could still rebuild them, I could still share my changes with others (should there be others again), there is no single point of failure or central organization to which I am beholden. All the teams and projects and companies in the world cannot take away from my ability to run my system as I see fit. And this power was given to me freely, not in hope of reward, but simply because people thought that this was the way the world ought to work. The Four Freedoms are not a means to an end, they themselves are the end. Now I do agree that the development of open source is a largely social activity, but it’s an activity that fundamentally starts from a position of freedom to act on your own, without approval, and should be seen as colored by it. There’s a reason Git baked forking directly into the workflow.
My point is: Nothing about Armin’s position is somehow “out of line” with open source.
If someone wants the benefits of participation in open source, they need to… y’know, actually be willing to participate. Which is a messy social activity defined and redefined by human interactions, rather than a legal activity exhaustively summarized by the clauses of a particular software license. Some projects, for example, impose requirements on how others can participate in their development process, their governance, their discussion forums, and so on. None of which are found in the project’s
LICENSEfile, which should in turn be a big big hint that there may be more expectations than are conveyed by just the license.[Comment removed by author]
Did PYPI offer to send him a security token (or buy him a phone)? Otherwise he should just use oathtool.