On Jul 23, 2016, at 12:11 PM, Donald Stufft wrote:

...

On Jul 23, 2016, at 2:40 PM, Nicholas Chammas 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...>. 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

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 wrote:

On 23Jul2016 1211, Donald Stufft wrote:

...

...

On Jul 23, 2016, at 2:40 PM, Nicholas Chammas 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

- 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 wrote:

On Sat, Jul 23, 2016 at 3:35 PM Daniel Holth 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 29 July 2016 at 02:09, Nicholas Chammas 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

On Sat, Jul 23, 2016 at 12:22 PM, Nathaniel Smith 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 -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

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

https://donate.pypi.io/ - 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 wrote:

On 24 July 2016 at 04:40, Nicholas Chammas 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