Additional financial or other support #7610
Comments
I setup GitHub Sponsors last year because a user wanted to express gratitude, and found that I didn't have to set tiers, only a recommended amount and a minimum amount ($1). hugovk has some tiers, but they are just for expressing different levels of gratitude.
Fun fact: Looking through my e-mails, it took... six minutes for my GitHub Sponsors to be approved.
Others might easily agree with me, but I'll say it anyway - I don't personally want to support ideas that money creates an obligation for more-than-usual work. If I haven't looked at a complex issue, it's likely because I've already spent a bunch of time solving a myriad of simpler ones. Money would be an encouragement, and considerable amounts of money definitely so, but I would like to imagine it more as 'thanks for the years of work already put in' and not as 'ok, now you really need to get down to it'. |
Thanks for the feedback! I don't want anyone to ever feel like they are obligated to work in ways they don't want to. What I do want to do is find ways to scale the amount of income proportionately to the perceived value. A financial framework to support the following:
So for (extreme) example, let's say someone (M$ or Meta or NVidia) gives us 1M USD for 2024 to "keep doing what we are doing". I would then:
That could support scenarios like the following. Scenario 1We decide the living wage cap is infinity and we all take 250K/year. Nothing left over for bounties. Scenario 2We decide the living wage cap is 200K and we all take 200K with 200K left over for bounties. Scenario 3We decide the living wage is 50K and we all take 50K with 800K left over for bounties. Any money left at the end of the year is added to the following year's income. Any form of this that ever came close to existing in real life beyond what Tidelift has already done would obviously have many complicating factors but my goal in writing it down is to riff on the mission of paying the maintainers. |
|
Thanks for the response. The only additional suggestion I have to your scenarios is perhaps the ability to, at our discretion, offer funds to users that we think have provided significant value without necessarily fulfilling a predetermined need - I'm thinking of nulano, who has provided a lot of value, but may not primarily focus on closing issues. We've suggested core membership before, but he hasn't taken us up on that offer. Although an alternative strategy, that you may have mentioned already, would be for these funds could incentivise him, and theoretically similar people, to join the core team. That topic is a secondary matter though, not the main focus here. |
|
@radarhere I think bounties could definitely be managed to cover long term coverage of platforms or packaging. In general I'm +1 here, with the caveat that once there's significant money involved, there are responsibilities that come from that. Either by continually justifying to the granters/donors about progress or effectiveness, legal responsibilities of a legal entity to handle the finances, or generally people's altered behavior when there's money at stake*. I'll also say that the Tidelift model is ideal for us at the moment -- because the complicated bits are handled by them, and we just have to agree that "this is what we're doing". Thanks.dev, on the other hand, has a single payout which we'd have to split manually, and it's not enough at the moment to justify jumping through any hoops to deal with. (* Note, I'm not specifically saying that something would happen, but we're a loose group, and I've seen money tear families apart.) |
|
On a related note, we may want to apply for OSS-Fuzz integration rewards. It's a once-off payment, rather than recurring, and if you want to distribute it there's still that problem, but the potential sum is not insignificant. |
|
There have already been two rounds of rewards on the OFF-fuzz from a few years back -- one for the initial integration by someone outside of the core team, and one to me for the improvements to the corpus, a bunch of fixes, and the additional font-fuzz entrypoint. |
|
I don't know what the Academy Software Foundation is. Please could you explain what it is, and what exactly the proposal is? |
It's a Linux Foundation umbrella project.
To be under a Linux Foundation umbrella which, of course, does not necessarily mean I want Pillow to be under a Linux Foundation umbrella just that I'd like to talk to ASWF about it. |
We have the "in progress" badge, which I don't think counts, as we're not yet at "passing" ("silver" and "gold" are next). There's one final criterion we couldn't decide on. I suggest we remove the badge if we can't complete it. |
What are the blockers and is there an open issue about it? We should probably be completing in general anyway… but sure, feel free to remove if you think "In Progress" is misleading. |
|
There's not an open issue. I think this is the last question to become "passing".
|
What exactly does being under a Linux Foundation umbrella mean? |
|
|
Gave this talk today and it went about as well as expected, given what it actually was: a long shot pitch combined with some thinly veiled attempts at other things. The ASWF TAC folks were very gracious in hearing my pitch, and I learned a lot just by being there. In particular:
In my perfect world, we'd spend time implementing #1888 "just for fun", assuming there were no obvious blockers to prohibit that effort. |
Up to 30K!? That's impressive. But seriously, if I ever got around to writing these things down, I would make a policy (perhaps agreed to in a CLA!) that such payments be disclosed here, assuming they are accepted and not just offered. Not because I want to talk about who gets what and whether or not they should get it, I don't want to talk about that (unless it's significant as @wiredfool mentioned) but more just that I'm curious about those processes and would love to keep track of them over the lifespan of the project. E.g. https://github.com/python-pillow/grant-proposal, https://github.com/python-pillow/grant-proposal2, etc. |
You're right, it doesn't. As I mentioned above, ASWF and probably the majority of folks are primarily looking for passing, and there's probably not universal consensus that silver and gold levels (or whatever they are called) are worth the effort. All the more reason we should finish #7873. If anyone has an outline or details of how to complete that one, I'd appreciate hearing about it! |
Yes, see the top of https://www.bestpractices.dev/en/projects/6331:
I don't think we can easily achieve silver or gold, but we can check off some of the criteria if they're relevant. I just did for half a dozen silver ones. |
I don't think we need a CLA, especially if we don't have a reason for one. If we did add one, we could make sure future contributors signed it, but it would be impossible to get all the past contributors to do so. I understand the CLA would not apply to code from old contributors who can't or won't sign it; any relicensing would need the old code removed or rewritten. This open source guide says most projects probably don't need them:
|
|
Reply from ASWF TAC here: AcademySoftwareFoundation/tac#631 (comment) |
In #3469 we discussed Tidelift funding which has gone very well and I hope lasts far into the future. Now I'd like to discuss funding via GitHub Sponsors which I know almost nothing about, but I am considering it now because I am considering additional funding in general, and that seems like a good place to start.
I love the Tidelift model because they abstract away a lot of the details like payment splitting and international payments. With this model, members of the @python-pillow/pillow-team have been able to receive payments monthly for about the last 4 years based on correspondence with Tidelift about which members of the core team should get paid. 4/5ths of the core team have elected to receive payments and we split the payments evenly.
Back to GitHub Sponsors, at a glance it has a Patreon feel to it which I don't particularly like because I don't want to think about tiered payments, payment amounts or getting sponsors. At least, I don't want to think about them more than maybe once a year. So for example if an organization wants to support development, I'd like to have those discussions ahead of time, get some commitments, and then sign up. But if I'm going to do that, I'm not sure I need GitHub Sponsors particularly since the payout method is either bank account or fiscal host.
Unless there is some overwhelming desire by one of the fiscal hosts to support us, I think we'd choose payout via bank account and that means I'd be splitting payments to the core developers myself, which I've always said I don't want to. I am reconsidering that now, but that still doesn't make GitHub Sponsors a good idea. It formalizes the process, which is nice, but not necessarily in ways that are compelling enough to make the decision easy.
Anyway, would love to hear thoughts from the core team, end users and organizations using Pillow. I'm not going to join the wait list until a majority of the core team is interesting in doing so, but I will begin to explore new funding opportunities for Pillow assuming a large consensus that there's still a massive disparity between economic value provided by Pillow and corresponding financial investment from its beneficiaries.
The text was updated successfully, but these errors were encountered: