Contributing money to package authors/maintainers via PyPI
This may be a heretical idea, and it’s definitely not something anyone is likely to take on anytime soon, but I’d like to put it up for discussion and see what people think.
I often find myself wanting to show gratitude to the authors or maintainers of a package by giving money. Most of the time, it is easier for me to give money than time. After all, contributing time in a meaningful way to a project can be quite difficult. I wonder how many others find themselves in a similar situation, wanting to chip a few bucks in as a token of gratitude for someone’s work, either one-time or on an ongoing basis.
You can already do this today, of course, with services like PayPal, Gratipay https://gratipay.com/, and Salt https://salt.bountysource.com/. But the process is scattered and different for each Python package and the group of people behind it. What’s more, it seems wrong that these third-party services should capture some of the value generated by the Python community (e.g. by charging some transaction fee) without any of it going back to support that community (e.g. via the PSF).
So that raises the question: How about if people could contribute money to the people behind projects they felt grateful for via PyPI? PyPI is already the community’s central package hub. Perhaps it could also be the community’s central hub for contributing money.
The central goal would be to create a low-friction ecosystem of monetary contributions that benefits Python package authors/maintainers, as well as the larger Python ecosystem. At a high-level, the ecosystem would be opt-in, and contributions would go directly to their intended recipients, with tiny cuts of each transaction going to the payment processor and some Python community organization like the PSF.
I know a more concrete proposal would have to address a lot of details (e.g. like how to split contributions across multiple maintainers), and perhaps there is no way to find the resources to build or maintain such a thing in the first place. But just for now I’d like to separate essence of idea from the practical concerns of implementing it.
Assume the work is already done, and we have such a system of monetary contributions in place today. My questions are:
- Would such a system benefit the Python community? - Would the cut of transactions that went to the PSF (or similar) be enough to cover the cost of maintaining the system and meaningfully impact other Python efforts? - Would such a system create perverse incentives? - Would it just be a dud that very few people would use?
I’m trying to get a feel for whether the idea has any potential.
Nick
On Jul 23, 2016, at 2:40 PM, Nicholas Chammas nicholas.chammas@gmail.com wrote:
I know a more concrete proposal would have to address a lot of details (e.g. like how to split contributions across multiple maintainers), and perhaps there is no way to find the resources to build or maintain such a thing in the first place. But just for now I’d like to separate essence of idea from the practical concerns of implementing it.
I’m mulling over the idea in my head, but one other thing we’d need to figure out is the *legality* of doing this and if it’s something the PSF is willing to do at all.
— Donald Stufft
On Jul 23, 2016, at 12:11 PM, Donald Stufft donald@stufft.io wrote:
On Jul 23, 2016, at 2:40 PM, Nicholas Chammas <nicholas.chammas@gmail.com mailto:nicholas.chammas@gmail.com> wrote:
I know a more concrete proposal would have to address a lot of details (e.g. like how to split contributions across multiple maintainers), and perhaps there is no way to find the resources to build or maintain such a thing in the first place. But just for now I’d like to separate essence of idea from the practical concerns of implementing it.
I’m mulling over the idea in my head, but one other thing we’d need to figure out is the *legality* of doing this and if it’s something the PSF is willing to do at all.
This was my initial reaction as well.
It would be awesome if it worked! It would potentially go a long way to addressing the now much-discussed problem of funding open source infrastructure <https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind... https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind-spot-b9aa23618c58#.tvr6exin9>. But it is also a legal and financial mine-field. Even if a lawyer says it's OK and it's possible to comply with the law, you still generate a lot of work for an accountant to actually do the complying.
https://gratipay.com https://gratipay.com/ is a good, recent example of an apparently simple idea like this running into severe legal consequences and nearly imploding as a result. Another potential problem that may not be initially obvious; due to the somewhat ambiguous nature of the funding structure, they also became a popular payment processor for nazis and white supremacists, since it's hard to get paid for producing nazi propaganda on other platforms. Of course, PyPI might always be used as an update platform for malware or a C&C control point too, so it's not like there are no risks in operating it as it currently stands, but money always has the potential to make things worse.
I don't want to be doom-and-gloom here, in fact I would _very_ much like to see this project happen. I just think that in order to do it in a way which doesn't backfire horribly, it has to be responsibly staffed at the outset so that problems like these, that we know about, can be addressed up front, and the inevitable ones that don't seem obvious at the moment have a clearly responsible person to go fix them as they arise, in a timely way.
-glyph
On 23Jul2016 1211, Donald Stufft wrote:
On Jul 23, 2016, at 2:40 PM, Nicholas Chammas <nicholas.chammas@gmail.com mailto:nicholas.chammas@gmail.com> wrote:
I know a more concrete proposal would have to address a lot of details (e.g. like how to split contributions across multiple maintainers), and perhaps there is no way to find the resources to build or maintain such a thing in the first place. But just for now I’d like to separate essence of idea from the practical concerns of implementing it.
I’m mulling over the idea in my head, but one other thing we’d need to figure out is the *legality* of doing this and if it’s something the PSF is willing to do at all.
Maybe it's as simple as a user profile "Donations URL" field that is also listed on any packages owned by that user? Or possibly a per-package URL? (The latter may work out better for people who manage both personal and work packages, which is currently the system we're using at Microsoft until we get a centralised publishing system set up.)
Cheers, Steve
Have you seen https://rubytogether.org ? It looks like exactly what you are proposing, only with more blocks.
On Sat, Jul 23, 2016 at 3:25 PM Steve Dower steve.dower@python.org wrote:
On 23Jul2016 1211, Donald Stufft wrote:
On Jul 23, 2016, at 2:40 PM, Nicholas Chammas <nicholas.chammas@gmail.com mailto:nicholas.chammas@gmail.com> wrote:
I know a more concrete proposal would have to address a lot of details (e.g. like how to split contributions across multiple maintainers), and perhaps there is no way to find the resources to build or maintain such a thing in the first place. But just for now I’d like to separate essence of idea from the practical concerns of implementing it.
I’m mulling over the idea in my head, but one other thing we’d need to figure out is the *legality* of doing this and if it’s something the PSF is willing to do at all.
Maybe it's as simple as a user profile "Donations URL" field that is also listed on any packages owned by that user? Or possibly a per-package URL? (The latter may work out better for people who manage both personal and work packages, which is currently the system we're using at Microsoft until we get a centralised publishing system set up.)
Cheers, Steve
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Sat, Jul 23, 2016 at 3:35 PM Daniel Holth dholth@gmail.com wrote:
Have you seen https://rubytogether.org ? It looks like exactly what you are proposing, only with more blocks.
Interesting. I hadn't heard of that before now.
I'm not sure what you mean by "with more blocks", but that idea seems focused on funding core Ruby infrastructure, whereas I'm proposing a way for users to fund any Python project they want, with the added benefit that by funding those projects they automatically also fund core Python infrastructure too.
A rough -- but in my view very apt -- analogy for what I'm proposing would be the iOS App Store. Users buy apps they want; when that happens, the app developers benefit by getting paid for their work, and the general iOS ecosystem also benefits since the maintainer of that ecosystem, Apple, gets a cut of those payments.
Of course, in our case we are talking about voluntary monetary contributions and not prices, and we are talking about tiny fees and not 15-30% cuts. But the basic idea is the same: Fund the core infrastructure by capturing some of the value generated by that infrastructure.
The core infrastructure would be things like PyPI, tooling like pip, and Python itself. The value generated by that infrastructure, for the purposes of this discussion, would be the monetary contributions people made to projects they appreciated. And capturing some of that value would be taking a tiny cut out of those contributions and reinvesting it in the core.
Nick
- https://en.wikipedia.org/wiki/Micropayment - https://en.wikipedia.org/wiki/Micro-donation - https://en.wikipedia.org/wiki/Gratis_versus_libre - https://en.wikipedia.org/wiki/Business_models_for_open-source_software#Volun...
- http://alternativeto.net/software/gittip/ (TIL GitTip is now Gratipay) - https://gratipay.com/about/
... https://en.wikipedia.org/wiki/Capitalization_table ... https://en.wikipedia.org/wiki/Bug_bounty_program ...
On Saturday, July 23, 2016, Nicholas Chammas nicholas.chammas@gmail.com wrote:
On Sat, Jul 23, 2016 at 3:35 PM Daniel Holth <dholth@gmail.com javascript:_e(%7B%7D,'cvml','dholth@gmail.com');> wrote:
Have you seen https://rubytogether.org ? It looks like exactly what you are proposing, only with more blocks.
Interesting. I hadn't heard of that before now.
I'm not sure what you mean by "with more blocks", but that idea seems focused on funding core Ruby infrastructure, whereas I'm proposing a way for users to fund any Python project they want, with the added benefit that by funding those projects they automatically also fund core Python infrastructure too.
A rough -- but in my view very apt -- analogy for what I'm proposing would be the iOS App Store. Users buy apps they want; when that happens, the app developers benefit by getting paid for their work, and the general iOS ecosystem also benefits since the maintainer of that ecosystem, Apple, gets a cut of those payments.
Of course, in our case we are talking about voluntary monetary contributions and not prices, and we are talking about tiny fees and not 15-30% cuts. But the basic idea is the same: Fund the core infrastructure by capturing some of the value generated by that infrastructure.
The core infrastructure would be things like PyPI, tooling like pip, and Python itself. The value generated by that infrastructure, for the purposes of this discussion, would be the monetary contributions people made to projects they appreciated. And capturing some of that value would be taking a tiny cut out of those contributions and reinvesting it in the core.
Nick
On Sat, Jul 23, 2016 at 3:11 PM Donald Stufft donald@stufft.io http://mailto:donald@stufft.io wrote:
On Jul 23, 2016, at 2:40 PM, Nicholas Chammas nicholas.chammas@gmail.com wrote:
I know a more concrete proposal would have to address a lot of details (e.g. like how to split contributions across multiple maintainers), and perhaps there is no way to find the resources to build or maintain such a thing in the first place. But just for now I’d like to separate essence of idea from the practical concerns of implementing it.
I’m mulling over the idea in my head, but one other thing we’d need to figure out is the *legality* of doing this and if it’s something the PSF is willing to do at all.
Would it simplify things for the PSF if they partnered with someone who took care of moving the money around?
The PSF, via PyPI, would bring a large, opt-in user base to their doorstep, and in return the payment provider (e.g. Gratipay, Salt) would cut the PSF some tiny slice of each transaction.
I don’t know if this tweak makes the proposal more realistic (again, maybe the margins wouldn’t work for the provider), but at least on first blush I think would help us accomplish the following:
- We offer the community a low-friction, standardized way to support projects they care about. - The PSF doesn’t have to handle thorny legal and accounting issues, at least not as bad as they would if they handled the payments directly. - The PSF builds up a funding stream that can support our core infrastructure.
Nick
On 29 July 2016 at 02:09, Nicholas Chammas nicholas.chammas@gmail.com wrote:
Would it simplify things for the PSF if they partnered with someone who took care of moving the money around?
If a global payments provider came to the PSF (or the Packaging Working Group within the PSF) and said "Here's a proposal for you to consider and suggest amendments to before we start sending implementation patches to Warehouse", then it would likely simplify things somewhat (the PSF would mainly just need to review the proposal to ensure it didn't jeopardise the PSF's non-profit status, that the platform operator had a clear escalation process for folks sending and receiving money, and that the terms of the proposal for individual publishers were something the PSF was happy to promote to PyPI's users).
However, in terms of designing such a system from scratch, picking a default payment platform is a relatively easy part of the problem - the design work around how the program is presented to package publishers and users, how folks raise questions regarding problems with money sent or received, and how we mitigate the chance of horror stories as folks naively fail to comply with their local tax laws all remain as complex problems to be addressed. (There may also end up being some challenges around age verification, as PyPI doesn't currently require you to specify your age when signing up, but also doesn't currently provide any services where that's a potential problem)
The PSF, via PyPI, would bring a large, opt-in user base to their doorstep, and in return the payment provider (e.g. Gratipay, Salt) would cut the PSF some tiny slice of each transaction.
I don’t know if this tweak makes the proposal more realistic (again, maybe the margins wouldn’t work for the provider)
It does make it more realistic, but as you note in your parenthetical comment, it's an open question as to whether it would be worth the investment in design and implementation effort from the side of the platform provider (especially if they assume the PSF itself will eventually get around to funding something along these lines).
Regards, Nick.
I assert that a PayPal Donate link in a readme is sufficient. Anything more is a pure waste of precious PSF and -sig resources. If a project is large and needs significant funding, there are better avenues to get funding from or through the PSF. Besides, I do not want to ask Donald to deal with PCI compliance; no matter who writes the patch, he would be the one that needs to make sure its correct.
-----Original Message----- From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Nick Coghlan Sent: Friday, July 29, 2016 6:41 AM To: Nicholas Chammas nicholas.chammas@gmail.com Cc: distutils-sig distutils-sig@python.org Subject: Re: [Distutils] Contributing money to package authors/maintainers via PyPI
On 29 July 2016 at 02:09, Nicholas Chammas nicholas.chammas@gmail.com wrote:
Would it simplify things for the PSF if they partnered with someone who
took
care of moving the money around?
If a global payments provider came to the PSF (or the Packaging Working Group within the PSF) and said "Here's a proposal for you to consider and suggest amendments to before we start sending implementation patches to Warehouse", then it would likely simplify things somewhat (the PSF would mainly just need to review the proposal to ensure it didn't jeopardise the PSF's non-profit status, that the platform operator had a clear escalation process for folks sending and receiving money, and that the terms of the proposal for individual publishers were something the PSF was happy to promote to PyPI's users).
However, in terms of designing such a system from scratch, picking a default payment platform is a relatively easy part of the problem - the design work around how the program is presented to package publishers and users, how folks raise questions regarding problems with money sent or received, and how we mitigate the chance of horror stories as folks naively fail to comply with their local tax laws all remain as complex problems to be addressed. (There may also end up being some challenges around age verification, as PyPI doesn't currently require you to specify your age when signing up, but also doesn't currently provide any services where that's a potential problem)
The PSF, via PyPI, would bring a large, opt-in user base to their doorstep, and in return the payment provider (e.g. Gratipay, Salt) would cut the PSF some tiny slice of each transaction.
I don’t know if this tweak makes the proposal more realistic (again, maybe the margins wouldn’t work for the provider)
It does make it more realistic, but as you note in your parenthetical comment, it's an open question as to whether it would be worth the investment in design and implementation effort from the side of the platform provider (especially if they assume the PSF itself will eventually get around to funding something along these lines).
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Jul 23, 2016 11:40 AM, "Nicholas Chammas" nicholas.chammas@gmail.com wrote:
[...]
You can already do this today, of course, with services like PayPal,
Gratipay, and Salt. But the process is scattered and different for each Python package and the group of people behind it. What’s more, it seems wrong that these third-party services should capture some of the value generated by the Python community (e.g. by charging some transaction fee) without any of it going back to support that community (e.g. via the PSF).
These kinds of money transfer services are pretty competitive, and AFAIK their transaction fees are largely set by companies like VISA, plus the actual costs of running this kind of business. (And this is much more than just shuffling bits around - there are all kinds of complicated regulations you have to comply with around issues like "how do you know that organized crime isn't using your service for money laundering". IIRC every country and US state has their own idea about what counts as adequate safeguards.) I think it's vanishingly unlikely that the PSF could provide these services more efficiently than these dedicated companies. So I don't think the PSF is going to get rich on transaction fees.
OTOH, if we give up on that part of the idea, then it becomes much easier :-). It'd be straightforward for PyPI to provide a "how to donate to this project" box on each project page, that has links to whatever donation processing service(s) the project prefers.
-n
On Sat, Jul 23, 2016 at 3:22 PM Nathaniel Smith njs@pobox.com wrote:
On Jul 23, 2016 11:40 AM, "Nicholas Chammas" nicholas.chammas@gmail.com wrote:
[...]
You can already do this today, of course, with services like PayPal,
Gratipay, and Salt. But the process is scattered and different for each Python package and the group of people behind it. What’s more, it seems wrong that these third-party services should capture some of the value generated by the Python community (e.g. by charging some transaction fee) without any of it going back to support that community (e.g. via the PSF).
These kinds of money transfer services are pretty competitive, and AFAIK their transaction fees are largely set by companies like VISA, plus the actual costs of running this kind of business. (And this is much more than just shuffling bits around - there are all kinds of complicated regulations you have to comply with around issues like "how do you know that organized crime isn't using your service for money laundering". IIRC every country and US state has their own idea about what counts as adequate safeguards.) I think it's vanishingly unlikely that the PSF could provide these services more efficiently than these dedicated companies. So I don't think the PSF is going to get rich on transaction fees.
Agreed that it doesn't make sense for us to reinvent this wheel, at least not unless the idea is massively successful.
I was thinking the PSF could perhaps start off by partnering with one of these organizations who have already figured this stuff out. The PSF/PyPI would bring a whole new group of users to their service, and in return the service provider (e.g. Salt) would give the PSF some cut of their fee.
Not sure if that's viable (maybe the margins are too low?), but that's what I was thinking.
Nick
On Sat, Jul 23, 2016 at 12:22 PM, Nathaniel Smith njs@pobox.com wrote:
OTOH, if we give up on that part of the idea, then it becomes much easier :-). It'd be straightforward for PyPI to provide a "how to donate to this project" box on each project page, that has links to whatever donation processing service(s) the project prefers.
+1 on this one -- shift all the legal hassles to the projects, but provide a tiny bit of infrastructure to make it easier for people to find.
note: for a higher level of support, the PSF _could_ follow the numfocus approach:
NumFocus is a properly set-up non-profit that can act as a gateway for particular projects, so that the individual projects don't need to set up all that accounting and legal infrastructure:
http://www.numfocus.org/information-on-fiscal-sponsorship.html
However, there is still a pretty big barrier to entry to become a sponsored organization, as there should be.
So I think it would be great if PyPi could simply put a donate button in there, but not try to get into the money laundering business.
-CHB
On 26 July 2016 at 04:52, Chris Barker chris.barker@noaa.gov wrote:
On Sat, Jul 23, 2016 at 12:22 PM, Nathaniel Smith njs@pobox.com wrote: note: for a higher level of support, the PSF _could_ follow the numfocus approach:
NumFocus is a properly set-up non-profit that can act as a gateway for particular projects, so that the individual projects don't need to set up all that accounting and legal infrastructure:
http://www.numfocus.org/information-on-fiscal-sponsorship.html
However, there is still a pretty big barrier to entry to become a sponsored organization, as there should be.
The PSF has considered this, but there's not a lot of value we could provide above and beyond other organisations that already do this for open source projects in general. For example:
- Software Freedom Conservancy - Software in the Public Interest - Outercurve Foundation
However, similar to the more direct crowdfunding options, pointing folks towards organisations like these via the publisher-facing pages in Warehouse is certainly something that could be done, especially as their download counts start to grow.
Cheers, Nick.
On Jul 26, 2016, at 01:24 PM, Nick Coghlan wrote:
The PSF has considered this, but there's not a lot of value we could provide above and beyond other organisations that already do this for open source projects in general. For example:
- Software Freedom Conservancy
- Software in the Public Interest
- Outercurve Foundation
The Free Software Foundation also runs a donation program, and GNU Mailman has benefited from this to some extent. They do take a healthy cut, which is okay with us because it helps fund their own programs and administrative costs.
One thing to keep in mind is that not all developers can or want to accept donations. It can cause tax and employment headaches. But in GNU Mailman's case, having donations go to a project-centric fund has allowed us to help pay for travel and Pycon attendance for our GSoC students, at least one of which has since become a core developer. At our size, that's been way more valuable to the project than paying individual developers.
Cheers, -Barry
On 24 July 2016 at 04:40, Nicholas Chammas nicholas.chammas@gmail.com wrote:
This may be a heretical idea, and it’s definitely not something anyone is likely to take on anytime soon, but I’d like to put it up for discussion and see what people think.
The PSF wouldn't want to get involved in the actual money transfer (facilitating international monetary transfers is complicated at the best of times, facilitating them without jeopardising the PSF's public interest charity status would be even worse), but one of the things I'd personally like to see happen post Warehouse migration is along the lines of what Nathaniel Smith suggested: we could adjust the publisher facing UX to explicitly nudge people towards explaining how ongoing development of their project is funded, and make it not only acceptable, but encouraged, for people to engage in fundraising activities on their project pages. The public project pages would then include that sustainability information, and we'd also make it available as part of the project metadata available through the service API.
It would then be up to publishers to decide if and how how they wanted to seek funds (PayPal, Patreon, Gratipay, BountySource Salt, etc), rather than the PyPA or the PSF making that decision on their behalf. (However, we could also consider being open to code contributions from those kinds of companies that made it easy for publishers to integrate their services with PyPI)
If folks publishing software through PyPI didn't personally want or need additional funds (e.g. when it's a fully funded institutional project, or if it's someone's personal side project that they have no interest in turning into a paid job), then we could let them opt in to using the relevant space on the project page to display the logo(s) of the sponsoring institution(s), encourage contributions to the PSF, or leave it blank entirely.
Cheers, Nick.
P.S. As far as RubyTogether goes, that's closer to what the PSF is doing with the Packaging Working Group - providing a centrally administered shared funding pool for sustaining engineering on common community infrastructure. The Python equivalent to that is now for organisations to either sign up as PSF Sponsors (or at least explain to the PSF what they would like to see in improved expenditure reporting before they would sign up as sponsors), or else to make an earmarked donation specifically to the community packaging infrastructure via https://donate.pypi.io/
It's not the same process or problem as the "help Python project users to effectively manage their supply chain by providing them with ways to fund Python project publishers"
- Minimum donation: $5 - 1 year PSF Associate Member: $99
( https://en.wikipedia.org/wiki/CiviCRM )
SSL certs were a primary cost before letsencrypt (which is sponsored by a large number of organizations):
- https://letsencrypt.org/ - https://mozilla.github.io/server-side-tls/ssl-config-generator/
... Third party payment services handle PCI-DSS (: https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
On Saturday, July 23, 2016, Nick Coghlan ncoghlan@gmail.com wrote:
On 24 July 2016 at 04:40, Nicholas Chammas <nicholas.chammas@gmail.com javascript:;> wrote:
This may be a heretical idea, and it’s definitely not something anyone is likely to take on anytime soon, but I’d like to put it up for discussion
and
see what people think.
The PSF wouldn't want to get involved in the actual money transfer (facilitating international monetary transfers is complicated at the best of times, facilitating them without jeopardising the PSF's public interest charity status would be even worse), but one of the things I'd personally like to see happen post Warehouse migration is along the lines of what Nathaniel Smith suggested: we could adjust the publisher facing UX to explicitly nudge people towards explaining how ongoing development of their project is funded, and make it not only acceptable, but encouraged, for people to engage in fundraising activities on their project pages. The public project pages would then include that sustainability information, and we'd also make it available as part of the project metadata available through the service API.
It would then be up to publishers to decide if and how how they wanted to seek funds (PayPal, Patreon, Gratipay, BountySource Salt, etc), rather than the PyPA or the PSF making that decision on their behalf. (However, we could also consider being open to code contributions from those kinds of companies that made it easy for publishers to integrate their services with PyPI)
If folks publishing software through PyPI didn't personally want or need additional funds (e.g. when it's a fully funded institutional project, or if it's someone's personal side project that they have no interest in turning into a paid job), then we could let them opt in to using the relevant space on the project page to display the logo(s) of the sponsoring institution(s), encourage contributions to the PSF, or leave it blank entirely.
Cheers, Nick.
P.S. As far as RubyTogether goes, that's closer to what the PSF is doing with the Packaging Working Group - providing a centrally administered shared funding pool for sustaining engineering on common community infrastructure. The Python equivalent to that is now for organisations to either sign up as PSF Sponsors (or at least explain to the PSF what they would like to see in improved expenditure reporting before they would sign up as sponsors), or else to make an earmarked donation specifically to the community packaging infrastructure via https://donate.pypi.io/
It's not the same process or problem as the "help Python project users to effectively manage their supply chain by providing them with ways to fund Python project publishers"
-- Nick Coghlan | ncoghlan@gmail.com javascript:; | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org javascript:; https://mail.python.org/mailman/listinfo/distutils-sig
participants (11)
-
Barry Warsaw -
Chris Barker -
Daniel Holth -
Donald Stufft -
Glyph Lefkowitz -
Nathaniel Smith -
Nicholas Chammas -
Nick Coghlan -
Steve Dower -
tritium-list＠sdamon.com -
Wes Turner