Relax Open Work Requirement

[chadwhitacre]

Right now we require Teams on Gratipay to use both our payin and our payouts products (though of course payouts doesn't really exist right now). I think this makes it harder to sign up new customers, especially established ones. It would be great to be able to pay for Wikipedia, Internet Archive, Firefox, etc. on Gratipay, but it'd be a much harder sell to get them on the platform if they have to agree to take-what-you-want payouts, too.

---

✈️ This is the flight deck for the Relax Open Work Requirement project. ✈️

⚠️ Moved to gratipay/gratipay.com#4221 ⚠️

[chadwhitacre]

@mattbk at #389 (comment):

Just got an email from Wikipedia asking for donations. Wouldn't it be cool to have them as a Team? 😍 Then I considered that they wouldn't be eligible, because they would choose not to use payroll. Just some thoughts for the morning. Gratipay seems to be focusing on the long tail of teams that are marginally viable but have not established internal financial structures. Is this a problem, or just wherw we want to be?

[chadwhitacre]

At the other end of the size spectrum, we've encountered a number of small projects that would like to use us for payments but not necessarily for payroll (gratipay/project-review#82).

The flip side would be an organization that wanted to use us for payroll but not for payments. @timothyfcook has asked for this before. He wants to use Gratipay to distribute payroll for projects that are grant funded outside of Gratipay.

[webmaven]

In general, I think decoupling the two is the correct move, and would bring on many more organizations (including, potentially, projects under fiscal sponsors like the Software Freedom Conservancy) and individuals.

Each service can then be a lead generator for the other that we can 'upsell' (though not too aggressively).

That said, for payroll alone to be sustainable, we would need to make sure that the users are prompted to donate to Gratipay in a similar way as for payments.

[chadwhitacre]

How would decoupling affect our "open work" requirement? It seems to me that open work refers more to the payroll side than the payment side. Using payroll is de facto open work. One approach on the payments side would be to shift the question to one of licensing of the product or service being offered. We could require open licenses (OSI-approved, Creative Commons, ... etc.?), which in effect enforces that payments are "pay-what-you-want".

[chadwhitacre]

I do tend to agree with you, @webmaven, that decoupling will help adoption. It's the sort of situation where, by requiring Teams to use payroll, let's say we'd end up with 1,000 Teams on Gratipay, whereas by not requiring payroll, we'd end up with 100,000 organizations on Gratipay, with 10,000 of them using payroll: a net win, even if the percentage is smaller.

[chadwhitacre]

We could require open licenses (OSI-approved, Creative Commons, ... etc.?), which in effect enforces that payments are "pay-what-you-want".

What about non-IP products and services? How do we define "pay-what-you-want" when the marginal cost is significantly greater than zero? Do we try to enforce pricing to cost? Gratipay itself is in this boat: we do charge hard fees, we just try to keep them as low as possible. Do we try to enforce this a priori during Team review, or do we try to encourage this without enforcing it?

[chadwhitacre]

For organizations that do have a split hard/soft fee model, such as Gratipay, do we want Gratipay to be generally usable for the hard fee? Or just for the soft fee?

[chadwhitacre]

"pay-what-you-want"

Or do we instead (or additionally) focus on alignment with the "commons" or the "collaborative economy"?

[mattbk]

How would decoupling affect our "open work" requirement? It seems to me that open work refers more to the payroll side than the payment side. Using payroll is de facto open work. One approach on the payments side would be to shift the question to one of licensing of the product or service being offered. We could require open licenses (OSI-approved, Creative Commons, ... etc.?), which in effect enforces that payments are "pay-what-you-want".

It might be possible to create tiers of openness rather than changing the TOS again to keep even more people out.

I do tend to agree with you, @webmaven, that decoupling will help adoption. It's the sort of situation where, by requiring Teams to use payroll, let's say we'd end up with 1,000 Teams on Gratipay, whereas by not requiring payroll, we'd end up with 100,000 organizations on Gratipay, with 10,000 of them using payroll: a net win, even if the percentage is smaller.

Exactly.

[chadwhitacre]

It might be possible to create tiers of openness rather than changing the TOS again to keep even more people out.

Maybe a "verified" program like Twitter does? Also, promoting verified open organizations on our homepage, etc.

[mattbk]

Yes. Teams meeting all the specifications for openness are given "Gratipay Platinum" status.

[mattbk]

Or, ideally, "Gratiplatinum."

[chadwhitacre]

Gratiplatinum

💃 🤘

[chadwhitacre]

Worked this through a little bit with @kaguillera. Here are a few badges we might offer:

• open product—licensed with OSI or CC
• open service—What does this mean? I mow lawns and anyone can schedule my available time without prearranging a payment amount? Does Catapult fit here?
• open franchise—business model is freely licensed (think Inside Gratipay)
• open work—take-what-you-want compensation for labor
• open investment—take-what-you-want return on investment

[chadwhitacre]

How do hard fees and soft fees relate to the above spectrum?

[chadwhitacre]

Do we allow non-open products and services? Or is that the minimum barrier to entry?

[chadwhitacre]

Or is brand fit the barrier to entry? But if openness is part of the brand, maybe brand fit ~= open product/service as a baseline?

[webmaven]

@whit537:

Do we allow non-open products and services? Or is that the minimum barrier to entry?

Or is brand fit the barrier to entry? But if openness is part of the brand, maybe brand fit ~= open product/service as a baseline?

I think at this point, only you can answer those Qs, Chad. Unless you want to start putting things to a vote?

[mattbk]

Perhaps baby steps? Keep current guidelines and stop requiring payroll. Then move from there.

[chadwhitacre]

I think at this point, only you can answer those Qs, Chad. Unless you want to start putting things to a vote?

Pretty sure those aren't the only options. 😛

[chadwhitacre]

I've started a todo in the description here so we can start to bring this milestone in for landing.

[chadwhitacre]

Just double-checked GitHub Organizations on casing. Looks there like they use capital Organizations for the product feature as a whole, but lower-case organization when referring to the actual entities themselves. Let's use projects instead of Projects (outside of the Terms, of course).

[mattbk]

Decouple in IG is almost done--just waiting on gratipay/gratipay.com#4117.

I can't wait for milestones that can encompass multiple repos.

[chadwhitacre]

I can't wait for milestones that can encompass multiple repos.

Projects! 💃

[chadwhitacre]

Okay! We are done revising the terms of service! Time to think about how to sequence the merging of that PR with the rest of the work here ...

[chadwhitacre]

Thinking about sequencing ...

[chadwhitacre]

I'm unbumping the codebase name changes from past gratipay/gratipay.com#4148. Let's observe some discipline and not introduce more tech debt.

[chadwhitacre]

I've just cleared out the todo from this ticket description, in favor of using the project board. Let's see how that goes. :)

[chadwhitacre]

Let's land the user-facing changes first, then the changes to the team-review repo, then dev-facing changes.

[chadwhitacre]

I've reorganized the project board using the columns like so:

• Takeoff → dev-facing changes
• In Flight → team-review changes
• Landing → user-facing changes

[chadwhitacre]

Alright, our decision under gratipay/gratipay.com#4148 (comment) to accept some tech debt means we can go light on phasing out tip migration, which means we can slip that in as part of this project instead of making it a project unto itself. I've moved the old takeoff cards over to the tech debt board. Let's bring the tip migration phaseout in for a landing, and then turn again to the UI-facing changes for teams → projects.

[chadwhitacre]

I think we should try out an integration branch for the various PRs involved in making this change across the site. GitHub's new base-changing feature ftw!

[chadwhitacre]

Moving to an integration PR in gratipay/gratipay.com#4221 ...