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 https://github.com/gratipay/gratipay.com/pull/4221 ⚠️

[chadwhitacre]

@mattbk at https://github.com/gratipay/inside.gratipay.com/issues/389#issuecomment-154095790:

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 (https://github.com/gratipay/team-review/issues/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

:dancer: :metal:

[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. :stuck_out_tongue:

[chadwhitacre]

tiers of openness

The Center for Open Science gives us a strong example of this approach: they have what they call "Transparency and Openness Promotion (TOP) Guidelines," which are graded standards for journals to adopt as they wish. In good scientific fashion, they also specify a Level 0 that is non-compliant, for comparison. Here's a chart from their Science article introducing TOP:

[mattbk]

How about a monetary incentive for "openness"? Closed projects can use the platform, but Gratipay takes a small cut.

[chadwhitacre]

Ooooooh ...

[chadwhitacre]

This is definitely something we need to get done. The Team review backlog is getting really clogged up. :-(

[chadwhitacre]

https://github.com/gratipay/gratipay.com/issues/2946 might tie into this.

[mattbk]

I'd like to nudge this along. What steps do we need to take?

[mattbk]

How would decoupling affect our "open work" requirement?

I don't think these requirements are related, although you try to conflate them, which I don't understand:

Using payroll is de facto open work.

I see two things here:

• Whether we should drop Gratipayroll as a Team requirement (I vote yes)
• Whether we should require a specific level of openness in order for Gratipay to be "free"
  • from there, we get into levels of openness, brand fit vs open, etc.

I think they can and should be addressed separately.

[mattbk]

Okay, I am beginning to understand. The question seems to be:

"Does it align with Gratipay's values that a Team can accept open work but be unwilling to share Team income among Team contributors?"

In that case, I think it makes sense to have two tiers of teams:

• Teams that use Gratipayroll owe no fees to Gratipay, although they are free to contribute.
• Teams that refuse to use Gratipayroll owe a certain percentage to Gratipay.

I'm just thinking that this method is 1) hard to enforce (are team members "real") and 2) subject to us having to moderate if there is a case where ~user A does work for Team B, but the owner of Team B refuses to allow anyone else onto the team.

[chadwhitacre]

In that case, I think it makes sense to have two tiers of teams:

And what's the value to us of having the second tier? Here's the best argument that's surfaced so far:

[B]y 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.

Here's the flaw: what would motivate the 100,000 organizations to use Gratipay in the first place? If they're not here for payroll then they're here for payments—but that's laughable, because payments is done, and we didn't do it. Patreon, PayPal, Stripe, etc., etc., etc.—nobody has a payments problem anymore. Gratipay is a highly inferior payment processor or crowdfunding platform.

But open projects do have a payroll problem (#179), and we've discovered a new and interesting solution to that problem: take-what-you-want payroll. We can differentiate by offering payments and payroll for open companies. Payroll for open companies is our blue ocean.

[chadwhitacre]

Gosh. You know what that brings me to the brink of suggesting? Maybe ... maybe ... maybe we should drop payments entirely. :flushed:

Gratipay: Take-what-you-want Payroll for Open Companies

Like, what if we said, "You handle your revenue stream however you want—Stripe, PayPal, whatever. Fund your Gratipay account with a wire or bank transfer each month, and we'll give you the tools to distribute that money to your voluntary workers on the take-what-you-want model."

[chadwhitacre]

But as soon as I say that, I realize that open projects also have another problem, which is that most of us are terrible at business and marketing and design and HR and accounting and anything non-code. Exceptions proving the rule would include Meteor, NPM, and Hashicorp. In our day we were starting to hint at solving a payments problem for open-source projects: the network effect of companies giving on Gratipay was powerful, and not to be denied.

[chadwhitacre]

So what am I saying? I'm saying that I think we want customers who are open companies that are going to have some business sense, and share their revenue through Gratipayroll. I think to benefit the open source community we'll have to do some outreach (cf. https://github.com/gratipay/gratipay.com/issues/1273), and that we should refer the Lone Ranger types to Patreon.

[chadwhitacre]

I mean, this ticket is about decoupling payments and payroll—but we don't have payroll at all right now! I think we should make payroll a reality again, and then revisit this conversation once we see how payroll is playing out in the real world.

[mattbk]

The reason I brought it up again is that these pending teams are supposedly blocked on this issue because they are teams named after people, not teams named after projects.

What can we do to unblock them?

[chadwhitacre]

because they are teams named after people, not teams named after projects.

It's okay to have teams named after people—remember Alice's Restaurant and Bob's Truck and Shoe Repair. The question is whether we should require Alice and Bob to participate in Gratipayroll, or whether we're okay with them using Gratipay for payments but not payroll.

Here's the flaw: what would motivate the 100,000 organizations to use Gratipay in the first place?

Hmmm ... but then I go back to the ticket description:

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 payroll, too.

But why would Wikipedia join Gratipay in order to receive money? Presumably because of a critical mass of users who would pay Wikipedia through Gratipay if they could. Now, we've got 11 teams currently blocked on this ticket, and that's 44% of our review backlog (11 / 25). In other words, the demand is real! We already have people who want to be part of Gratipay for payments alone. Both because of the flagship customers we want to court, and the smaller customers that have already applied, it seems that decoupling payments from payroll is the right way to go.

[chadwhitacre]

What can we do to unblock them?

How about this:

• [x] drop "I agree to be responsible for payroll" from the list of boxes on the Team application.
• [x] drop the "onboarding" and "to-do" URLs from the application form
• [x] stop displaying onboarding and to-do on Team pages (don't delete the data yet; bring the display back with payroll)
• [x] revise our "open work" criterion on team review
• [x] revise terms?

When we bring back payroll (#466), we'll implement it as an add-on product that requires additional steps, including business verification (https://github.com/gratipay/gratipay.com/issues/988), filling out onboarding and to-do, and perhaps agreeing to additional terms.

[mattbk]

Why does the open work requirement need to be tossed?

Look, I get that without payroll, Gratipay is a PayPal frontend. But that doesn't mean it doesn't have value.

[chadwhitacre]

without payroll, Gratipay is a PayPal frontend.

:dancer:

Why does the open work requirement need to be tossed?

Not tossed entirely, but at least revised, no? Right now we say in our terms:

The Service is a platform to enable Teams of Gratipay Participants to receive payments to fund Open Work. Open Work means that the Team provides a clear path for any individual to voluntarily begin contributing to the Team's work and to share in any revenue the Team generates. Some examples of Teams performing Open Work include an open source software project that pays contributors, or a hackerspace that pays individuals to teach classes or manage its operations.

(which I guess means that we'll actually have to change our terms, too ...)

And on Review Teams we say:

First, the Team must offer open work. Here's the thought experiment: "Could I as an individual voluntarily start doing the Team's work without having to coordinate with anyone?" Review their onboarding documentation and to-dos to make a determination. This is a positive criterion: we assume a Team is closed unless they can show us that they're open.

Without payroll, individuals cannot "share in any revenue the Team generates," which breaks our terms though not Review Teams. Of course, our terms are already broken since no-one is sharing in any revenue right now anyway!

[mattbk]

After thinking about this, I can see how it would open things up. Is team review then only about "brand fit" and "real product"?

This is a large change.

[mattbk]

Looking around, we don't talk about "real product" anywhere--but that was the reason for Gratipay 2.0, to make each team prove they have a real product for which they can receive funding, rather than Joe Schmoe who wants people to be able to give him money for no reason at all. I think the "open work" requirement makes it clear that teams need to exist in order to get things done, not just harvest money for vague and mysterious reasons.

[kaguillera]

I agree with @mattbk. The whole reason we had to move to 2.0 (as far as I understand) to ensure that Joe Schmoe can't get people to give him money for no reason at all.

[chadwhitacre]

we don't talk about "real product" anywhere the "open work" requirement makes it clear that teams need to exist in order to get things done

Right, we use the "Open Work" language in the terms:

When you make a payment to a Team, it is a payment to fund the Open Work the Team provides.

and:

By accepting a payment from a Participant, a Team forms an agreement with that Participant to perform the Open Work described in its profile.

Are you thinking we need to be more explicit about this outside of the terms?

[mattbk]

It should probably be in the terms as well as /new. It's especially important if you want to drop "open work," in which case Gratipay is "Payments and Payroll for..." work?

[mattbk]

It should probably be in the terms as well as /new. It's especially important if you want to drop "open work," in which case Gratipay is "Payments and Payroll take what you want for..." work?

Updated the wording. Still have 11 teams blocked on this issue.

[chadwhitacre]

Interestingly, Liberapay does moderate users. The idea over there is to allow anyone legal to use the payment features of the site, but only certain users to use the social features of the site (cf. https://github.com/liberapay/liberapay.org/issues/15).

[chadwhitacre]

I'm thinking about this ticket in the context of https://github.com/gratipay/gratipay.com/issues/3994. My thought is that perhaps we should keep twyw payouts on a weekly schedule, but run payins continuously—to include one-time as well as non-weekly giving.

[chadwhitacre]

This will also help alleviate the problems that Drupal had with Gittipay 1.0 distributions because we'll end with Teams somehow explicitly setting the amount to make available for distribution each week.

[mattbk]

(Edited after comments to retain clarity)

@whit537 and I discussed this while I was in Pittsburgh, which cleared some things up for me. I had to articulate a response to this comment today, which helped a little more.

• We need Teams in order to show that people are being given money in exchange for goods or services (anti-AML compliance). Hence the application process.
• We currently require teams to pledge to use take-what-you-want payroll payouts when it returns. The current issue is about removing this requirement.
• We currently require open work in order to be eligible for take-what-you-want payroll payouts when it returns. This is because of brand fit (a requirement for an approved team).
• We currently require teams to align with the brand fit. This is to avoid another Gittip Crisis. I don't see this going away.

Of those requirements, payroll take-what-you-want payouts and open work are optional. Can we treat them separately?

• Teams with payroll take-what-you-want payouts and without open work are Teams receiving donations but team membership is invite-only. This is conceivable, and leverages weekly take-what-you-want.
• Teams with open work but without payroll take-what-you-want payouts are Teams receiving donations but are either 1) teams of one or b) teams of many without sharing or using a different payroll payout method. I think both of those are conceivable.

So yes, it looks like we can treat them separately. If we want to use social ranking ("all the coolest people at the top of the page"), I propose this order:

1. Teams using payroll TWYW payouts with open work
2. Teams withpayroll TWYW payouts but without open work
3. Teams with open work but without payroll TWYW payouts
4. Teams without open work or payroll TWYW payouts

That's up to whether we think take-what-you-want or open work is more important and more worthy of promoting; or we combine 2 and 3 on the same internal-promotion level (front page, etc.) but promote them separately to different audiences externally. For example, open work teams promoted to OSS open company folks, but take-what-you-want teams promoted to guaranteed minimum income universal basic income folks.

Thoughts? Was good to make time to get this all down.

[chadwhitacre]

Awesome write-up, @mattbk, both here and on 3630. A couple quibbles:

payroll

s/payroll/take-what-you-want payouts because https://github.com/gratipay/gratipay.com/issues/3994#issuecomment-216836470 ;-)

We need Teams in order to show that people are being given money in exchange for goods or services (anti-AML compliance). Hence the application process.

Whether we call them Teams or participants or users or customers or whatever, the anti-money laundering (AML) requirement is that we "facilitate the purchase of goods or services" (details).

That we call them "Teams" is more to the third point:

We currently require open work in order to be eligible for take-what-you-want payroll when it returns.

As described in our current terms of service, Gratipay "is a platform to enable Teams of Gratipay Participants to receive payments to fund Open Work." The extent to which "[t]his is because of brand fit" is the open question here. What I sort of see us coming around to is that "brand fit" means no active trolls and/or troll-ish activists (activitrolls?). From the brand angle, at least, I'm comfortable expanding Gratipay to allow non-open work.

Teams with open work but without payroll are Teams receiving donations but are either 1) teams of one or b) teams of many without sharing or using a different payroll method. I think both of those are conceivable.

I can conceive of open-work-without-payouts as "using a different payroll method" but I'm not sure otherwise. I could maybe see (1) as transparent work according to our definitions (open = sharing control; transparency = sharing information). I think it's cleaner to say that "open work" builds on payouts:

Level 3: Open Payouts ← "open work" according to our current definition Level 2: Transparent Payouts ← public payouts, but no self-onboarding Level 1: Closed Payouts ← twyw, but private Level 0: No Payouts ← no twyw; "team of one" or closed company or what have you

[mattbk]

I edited my comment to align with your clarifications. Good stuff.

What I sort of see us coming around to is that "brand fit" means no active trolls and/or troll-ish activists (activitrolls?).

Plus they aren't created by "suspicious" ~users.

Level 3: Open Payouts ← "open work" according to our current definition Level 2: Transparent Payouts ← public payouts, but no self-onboarding

Does this ^ mean that the amounts everyone TWYW is public? Is that the way things are (will be)? Don't remember from the last time TWYW worked. Conversely, the "private" below.

Level 1: Closed Payouts ← twyw, but private Level 0: No Payouts ← no twyw; "team of one" or closed company or what have you

I like where this is going.