Thanks for putting together your thoughts Bryce,
These are my considerations for why I've changed my mind somewhat (although not completely) in terms of how we should layout project funding.
First, let me share my thoughts on Patreon and why we should not rely on it for our *project* needs.
This sounds like you would be happy to have patreon be a part of the mix. And I'd be happy to conspire to have both, more below.
Patreon looks interesting for individual developers, but for the Inkscape project in general what we really need is a mechanism to direct and focus funds towards the issues our donors, users, and developers care about collectively, and to provide them with a level of accountability that the funds are being put to good use for tangible, predictable benefits. Patreon is undirected, simply providing funding for whatever the recipient wishes to do. It provides no mechanisms for review, guidance, or transparency.
The mechanisms are one to many. i.e. they act to patreon users from thier funded projects. Each person on the site is responsible for their upkeep to make sure their users are happy. The mechanism for keeping users happy is transparency.
From a project perspective; we don't get special guidance or review.
Only normal guidance and review, that we would normal have with any developer.
And to my mind, this is good. Part of what makes this a good option is that users themselves have more direct control over what the developer spends their time on without excessive filtering by gate keepers. To an odd degree, patreon fits better with inkscape's flat developer model than the majority of more rigid foss project hierarchies.
However, website placement is likely going to be contentious since it relies on donors selecting who to fund. ... We can strive very hard to make it "fair"
Yeah, that's not an easy thing to solve. But random plus funding step sort would be most useful I think. The funding step is how patreon organises how productive you can be for your users at each funding level. And this information would be invaluable to any placement links we do on our website.
but with money involved there will always be complaints, and someone feeling that someone else is getting more funding priority than they "deserve". Despite our best of intentions, this feels likely to turn into a can of worms.
There are no more or fewer worms or possible complaints about unfairness. We know the thicket of risk on this one.
The use of trademark enforcement is an interesting angle, by restricting who can label themselves as "Inkscape Developers". However, I believe trademark law does not work that way,
I think you're right. No need to make it complicated.
But we needn't overthink it to that level - fundamentally, restricting how other developers define themselves within our community is at odds with our egalitarian principles, and does not respect the development freedom we cherish. If someone wants to refer to themselves as an Inkscape Developer, we should encourage it.
Without any sort of control over who does and does not add themselves to patreon, we will be the most egalitarian possible. That has it's own risks of course. But I'm happy to proceed on the basis of trust.
Paid developer work has been long discussed in our project. We've looked at bounty systems, direct patron sponsorship, straight up contracting, and so on, that other projects have experimented with. We approached the Software Conservancy with these ideas and hashed them out into a workable system, after months of discussion and drafting.
We all put work into (although you the most) the project mechanism. We should be careful though, it could be a sunken time fallacy if we're not careful.
The process is strongly modeled after Google Summer of Code, which has been proven effective for us historically. It builds in several checkpoints to ensure bad actors don't enter the system, and to ensure accountability and transparency into the development work. It also empowers and leverage donors to influence where their money gets invested, both to give them a level of ownership and to use their donation decisions as "crowd wisdom" to ensure we're putting money where it will most benefit the Inkscape community's needs.
The number of steps required, the amount of intervention from volunteer project members. It's a HEAVY system. By comparison, the weight of the patreon model is mostly self-contained and responsibility is placed on the individual developer.
This also goes so far as the weight and costs in regards to the conservancy. The conservancy's responsiveness makes me very scared, since they'd be the ones paying people real money for real rent. This has all sorts of issues and the conservancy may not even be able to pay some developers in some countries.
I'm not saying the conservancy couldn't pull it out. But they're a small team without the same level of automation of the patreon system.
One important distinction from GSoC is that jobs don't need to be fixed sized to fit 3-month summer schedules. This system should work for quick turn-around 1-2 week projects, up to multi-month or even year-long efforts. Whatever we need. It also doesn't have to be feature work, but could target bug fixing, website work, documentation. Whatever we need.
One of the advantages of having a more fluid system, is that a developer could focus on bug triage, or making icons, or any number of smaller tasks and could report on it to their patreons. The project model is focused on larger proejcts and we know we're retrofitting it to work for smaller items.
This system is set up to make payments after completion, rather than reliably regular monthly payments, and I know that will be an issue for people needing predictable income for covering monthly rent and so on. One way we can hack around that is instead of defining one big 3- month job, to break it up into three 1-month (160 hr, $2000+) jobs assigned to them that they perform sequentially. This will require more reviewer involvement, but that's not necessarily a bad thing.
For all of this to work, though, I would need to recruit a number of you to help out in various roles. I don't think these roles will be time consuming, but you'd need to commit to being available regularly as stuff comes up.
How does this plan sound in concept?
So, the parts that are missing is the types of donators to both types of funding models. Patreon donators are more likely to be small, individual users. $1, $5 amounts and the 5% cut goes to patreon when the money is withdrawn.
The project funding however can come from donors who give us $10k, or $100. If we promoted patreon, we'd probably see a reduction in smaller donations to the main fund, but we'd probably still get quite a lot. The conservancy will take 10% at donation time.
The project model is still a good model, but it's a different model. We shouldn't kid ourselves that all the filtering, reviewing and deep personal attention means projects are what /developers/ want for the project. Which is not a bad thing at all. But part of the filtering is filtering out user direction.
Having patreons doesn't mean we shouldn't have projects. It just means we have a more user directed, developers contracted by a mass of users, sort of method too.
I support the promotion of both with the idea that our projects are run more like GSoC projects with known rewards with known reviews and the alternative fluid, more risky but less work patreon system which can run along side.
Thoughts?
Best Regards, Martin Owens