Python's PyPI Will Sell 'Organization Accounts' to Corporate Projects to Fund Staff (pypi.org) 14
Last year Python's massive PyPI repository of pre-written software packages had 235.7 billion downloads — a 57% annual growth in its download counts and bandwidth. So now Python's nonprofit Python Software Foundation has an announcement.
Their director of infrastructure said today that they're rolling out "the first step in our plan to build financial support and long-term sustainability of PyPI, while simultaneously giving our users one of our most requested features: organization accounts." Organizations on PyPI are self-managed teams, with their own exclusive branded web addresses. Our goal is to make PyPI easier to use for large community projects, organizations, or companies who manage multiple sub-teams and multiple packages.
We're making organizations available to community projects for free, forever, and to corporate projects for a small fee. Additional priority support agreements will be available to all paid subscribers, and all revenue will go right back into PyPI to continue building better support and infrastructure for all our users... Having more people using and contributing to Python every year is an fantastic problem to have, but it is one we must increase organizational capacity to accommodate. Increased revenue for PyPI allows it to become a staffed platform that can respond to support requests and attend to issues in a timeframe that is significantly faster than what our excellent (but thinly spread) largely volunteer team could reasonably handle.
We want to be very clear — these new features are completely optional. If features for larger projects don't sound like something that would be useful to you as a PyPI maintainer, then there is no obligation to create an organization and absolutely nothing about your PyPI experience will change for you.
We look forward to discussing what other features PyPI users would like to see tackled next...
Their director of infrastructure said today that they're rolling out "the first step in our plan to build financial support and long-term sustainability of PyPI, while simultaneously giving our users one of our most requested features: organization accounts." Organizations on PyPI are self-managed teams, with their own exclusive branded web addresses. Our goal is to make PyPI easier to use for large community projects, organizations, or companies who manage multiple sub-teams and multiple packages.
We're making organizations available to community projects for free, forever, and to corporate projects for a small fee. Additional priority support agreements will be available to all paid subscribers, and all revenue will go right back into PyPI to continue building better support and infrastructure for all our users... Having more people using and contributing to Python every year is an fantastic problem to have, but it is one we must increase organizational capacity to accommodate. Increased revenue for PyPI allows it to become a staffed platform that can respond to support requests and attend to issues in a timeframe that is significantly faster than what our excellent (but thinly spread) largely volunteer team could reasonably handle.
We want to be very clear — these new features are completely optional. If features for larger projects don't sound like something that would be useful to you as a PyPI maintainer, then there is no obligation to create an organization and absolutely nothing about your PyPI experience will change for you.
We look forward to discussing what other features PyPI users would like to see tackled next...
Re: (Score:2)
235 billion downloads (Score:3)
If every person on the planet downloaded this library 40 times during the last year, perhaps some caching would be in order
Re: (Score:2)
The biggest issue with these repositories is that they encourage laziness in the developers that use them. "Why would I write my own code when I can use this god-awful updated once seven years ago abandonware library with sixteen different, and often version conflicting, dependencies?"
The second is the vulnerabilities they never let die. "The end-users? Fuck 'em, it's one hour of my life back damn it. Who cares about their entire lives being exposed due to some an
Re: (Score:2)
Dynamically linking to these repositories actually enable security and other fixes to be shared far more quickly and effectively than static linking for example.
If a dev chooses to rely on "god-awful updated once seven years ago abandonware library with sixteen different, and often version conflicting, dependencies" and but not contribute to it, that's on them. It's on any of their team too, who let that shit slide.
Re: (Score:2)
Hmm... if only there were a way to have the best of both worlds.
I thought having things run on an interpreter or virtual machine was supposed to help with these kinds of problems. It's like we're still living in the 1970's.
Re: (Score:2)
Each project inventing their own version of modules that do basic functions, with slightly different names, is apparently the pythonic way. It gets very confusing very quickly resolving the dependencies among them: grouping them by sponsor or project owner mought be helpful to guide people to tools from people most familiar with the task needed, rather than some of the rapidly aging and unsupportable tools which now are permanently available.
Re: (Score:2)
Yep. Repos like this are nice for prototyping. You know when the code use is short-term and nothing depends on it working reliably or securely. They are the complete untergang for production code.
Re: (Score:2)
The biggest issue with these repositories is that they encourage laziness in the developers that use them. "Why would I write my own code when I can use this god-awful updated once seven years ago abandonware library with sixteen different, and often version conflicting, dependencies?"
Sounds like you have a case of Not Invented Here syndrome.
The second is the vulnerabilities they never let die. "The end-users? Fuck 'em, it's one hour of my life back damn it. Who cares about their entire lives being exposed due to some ancient exploit I've never heard of?"
This is why there are a number of tools that scan applications for out of date dependencies with vulnerabilities. On the other hand if you write everything on your own you're relying on obscurity to secure your application (and maybe static analysis tools which are generally annoying).
Re: (Score:1)
Haw haw!
The 235 billion is the total number of downloads of all the thousands of libraries on PyPi