turn the ship

[chadwhitacre]

Last week, Gratipay stopped processing payments because of legal concerns with our old terms of service that became apparent after our processor, Balanced, announced that they're going out of business, and Stripe wouldn't take us. So in addition to migrating our processing infrastructure (#3377), we also have to change our business model at the same time. No :sweat:, right? :)

We hashed out our new business model on https://github.com/gratipay/inside.gratipay.com/issues/180 and https://github.com/gratipay/inside.gratipay.com/issues/192. This ticket is to track implementation. See also the Pivot milestone.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rohitpaulk]

fix paypal bug

On it.

[chadwhitacre]

!m @rohitpaulk

[chadwhitacre]

Alright, if you're on that, @rohitpaulk, then I'm going to rewrite payday (#3414). :rage1:

[rohitpaulk]

Cool, start pushing commits as soon as you can, even if they're small - should help to have an extra pair of eyes on them :)

[chadwhitacre]

@rohitpaulk Good call.

[silverhook]

I got error "400 Bad Request: You must attach a bank account or PayPal to apply for a new team." although ~NuvolaPlayer does have PayPal account attached. Should I create a new ticket for this?

I have the same issue for ~Kiberpipa.

[rohitpaulk]

@silverhook - We have a fix on #3423, will be deployed soon...

[chadwhitacre]

@rohitpaulk In general can you work on getting people signed up?

[rohitpaulk]

Yep, will do. You'll have to deploy #3423 though.

[chadwhitacre]

Deployed. Try again @fenryxo @silverhook? https://gratipay.com/new

[jiri-janousek]

@whit537 Works without any issues ;-)

[chadwhitacre]

Huzzah! :dancer:

=> select name, owner from teams;
┌───────────────┬──────────────┐
│     name      │    owner     │
├───────────────┼──────────────┤
│ Gratipay      │ Gratipay     │
│ introtopython │ ehmatthes    │
│ Duo           │ mix          │
│ sudo room     │ sudoroom     │
│ Nuvola Player │ NuvolaPlayer │
└───────────────┴──────────────┘
(5 rows)

[chadwhitacre]

That is a good honkin' crew. Dang. :rocket:

@silverhook Hopefully you can join us soon? Your trip is short. :dancer:

[silverhook]

× Looks like you've found a bug! Sorry for the inconvenience, we'll get it fixed ASAP!

Bah, humbug!

[silverhook]

Ah, I got it – it doesn’t accept / in the name – I wanted to use Cyberpipe/Kiberpipa hackerspace

Submitted now :+1:

[chadwhitacre]

Yesssssssssss! :dancer:

[ehmatthes]

It's probably obvious, but I filled in the /new form in a very basic sense, with the intention of refining the copy as the new structure continues to take shape.

[ehmatthes]

PS !m everyone, it's been an exciting week to watch Gratipay development.

[rohitpaulk]

!m @ehmatthes :)

[chadwhitacre]

Okay, payday rewrite landed, proceeding with migration of tips to subscriptions ...

[chadwhitacre]

=> select name, owner, is_approved from teams;
┌───────────────┬──────────────┬─────────────┐
│     name      │    owner     │ is_approved │
├───────────────┼──────────────┼─────────────┤
│ Gratipay      │ Gratipay     │ t           │
│ introtopython │ ehmatthes    │ t           │
│ Duo           │ mix          │ t           │
│ sudo room     │ sudoroom     │ t           │
│ Nuvola Player │ NuvolaPlayer │ t           │
│ Cyberpipe     │ Kiberpipa    │ t           │
└───────────────┴──────────────┴─────────────┘
(6 rows)

[chadwhitacre]

/me deploys #3414 in order to pick up new schema ...

[chadwhitacre]

How's this look?

INSERT INTO subscriptions (ctime, subscriber, team, amount, is_funded)
(
    SELECT ctime
         , tipper
         , (SELECT slug FROM teams WHERE owner=tippee)
         , amount
         , is_funded
      FROM current_tips
      JOIN participants p
        ON p.username = tipper
     WHERE tippee IN (SELECT owner FROM teams WHERE team.is_approved)
       AND p.is_claimed IS NOT NULL
       AND p.is_suspicious IS NOT TRUE
       AND p.is_closed IS NOT TRUE
       AND amount > 0
);

/me testing on a backup ...

[rohitpaulk]

@whit537 - https://github.com/gratipay/gratipay.com/pull/3424. Basically the same thing, running the SQL directly would probably be faster than merging the PR and running the function on each of the teams though.

[chadwhitacre]

=# \i sql/migrate-tips-to-subscriptions.sql
INSERT 0 984

INSERT INTO subscriptions (ctime, subscriber, team, amount, is_funded)
(
    SELECT ct.ctime
         , ct.tipper
         , (SELECT slug FROM teams WHERE owner=tippee)
         , ct.amount
         , ct.is_funded
      FROM current_tips ct
      JOIN participants p
        ON p.username = tipper
     WHERE tippee IN (SELECT owner FROM teams WHERE is_approved)
       AND p.claimed_time IS NOT NULL
       AND p.is_suspicious IS NOT TRUE
       AND p.is_closed IS NOT TRUE
       AND amount > 0
);

[rohitpaulk]

claimed_time, not is_claimed..

[chadwhitacre]

Yeah, got it. Just ran it in production:

=> \i sql/migrate-tips-to-subscriptions.sql 
INSERT 0 984

O.O

[chadwhitacre]

Switching to #3415 ...

[chadwhitacre]

I made another pass through support to keep people topped up. We've got 14 open tickets there that we'll need to follow up on as things settle down. Next steps are to complete and clean up after payday (#3415), and make a blog post announcing the change (#3419). After that let's pick off the remaining tickets on the Pivot milestone. This ticket'll be the last one out the door.

[chadwhitacre]

Okay! Big day. :100:

Today we need to announce Gratipay 2.0 (#3419), so that we can get more people signed up in time for payday 155 tomorrow. There are a few things we should clean up before we publish that announcement. #3432 is a good example. There may be others as I think through this here ...

You around today, @rohitpaulk?

[rohitpaulk]

Yep, I'm here. Should I be focusing on Braintree or the Pivot?

[rohitpaulk]

Most of the cached amounts work has been done in #3449, should just be a matter of picking it out of the mess.

[chadwhitacre]

@rohitpaulk Huzzah! Pivot today, Braintree tomorrow. We need to get this announcement out the door ASAP so people can start signing up again before tomorrow. We're going to have to bump payroll and stats/caching past tomorrow, I'm afraid. :-/

Blockers for #3419 are at https://github.com/gratipay/gratipay.com/issues/3419#issuecomment-103870467.

[rohitpaulk]

We're going to have to bump payroll and stats/caching past tomorrow

Payroll is done in #3450, ready for review. Stats/caching will take a while, yh.

@whit537 - I'll work on #2387.

[chadwhitacre]

I'll work on #2387.

@rohitpaulk Perfect, thank you. I am finishing up a round of revisions to #3419 and then I'm going to handle https://github.com/gratipay/gratipay.com/issues/3366#issuecomment-103895393 on my way to the coffee shop. I will reappear in a couple hours with the goal of landing #3419 by suppertime.

[chadwhitacre]

Announcement is out the door! We have launched Gratipay 2.0! :dancer:

!m *

[chadwhitacre]

We pivoted (#180) to Gratipay 2.0. Now, we need to turn the :ship: a couple degrees more.

• Gratipay 2.0: Payments and payroll for open work.
• Gratipay 2.1: Payments and payroll for open companies.

Why? As before, we're being driven negatively by legal concerns, but also positively by business vision.

Gratipay 2.0 moved us clearly into the safe zone regarding direct BSA regulation, but we still have work to do to comply with AML law to the satisfaction of our prospective processing partners (currently #3491; see also: #3366 #417 #481). Separately, in trying to bring back payroll, we've started wrestling with our story relative to employment law. AML and employment law are the two negative constraints driving Gratipay 2.1.

The principle of business vision that is driving Gratipay 2.1 is that we want economic engines, because our mission is to cultivate an economy. We want companies. We don't just want "teams" that don't make any money. We want companies that make money and offer open work. We want open companies.

[chadwhitacre]

Here are the changes involved in Gratipay 2.1:

• Stop talking about teams and start talking about open companies.
• Attach a withdrawal route directly to the company.
• Stop talking about company owners and start talking about company managers.
• Allow for more than one manager.
• Allow for setting a withholding amount on individual takes.
• Takes now represent contractors, employees, and/or owners.
• Allow for managers to set takes rather than members always setting their own takes.
• Collect and verify company identity for all companies.
• Collect and verify personal identity for all members.

[tshepang]

Can't we keep things simple and only do teams?

[chadwhitacre]

@tshepang By "teams" I take it you are referring to the friction-free revenue sharing that we had under Gratipay 1.0. Unfortunately, that has been an over-simplification, lulling our users into a false sense of security. The best explanation we've had yet for the legal relationship between teams and members under Gratipay 1.0 is that the team isn't actually a party to the transaction:

[T]he members don't receive money from Gratipay LLC, they receive money from anonymous tippers.

And again at https://github.com/gratipay/inside.gratipay.com/issues/211#issuecomment-109513994:

I was under the assumption that Gratipay would function to make the distributions directly to the different members and each of us would be obligated to self-report our own income on our Schedule C

As I responded there, I don't think this line of thinking bears examination, because the flow of funds still has to be accounted for, and the only way I see of accounting for the flow of funds under the 1.0 model is too much of a stretch to be tenable:

Let's say Company A uses jshttp and pays $100, and that gets split between 10 developers on the jshttp team. Are those 10 each independent contractors of Company A? Does Company A get ten invoices, one from each of them, for their portion of the $100 payment? It seems less strained to me to say that jshttp is itself a company (a legal entity), that receives $100 in income from Company A, and pays the 10 developers either as contractors, employees, or legal owners of the jshttp legal entity.

[jiri-janousek]

Gratipay 2.1: Payments and payroll for open companies.

Is it necessary to have a company or is a sole proprietorship as a legal entity (+ contractors) enough?

[chadwhitacre]

[T]he only way I see of accounting for the flow of funds under the 1.0 model is too much of a stretch to be tenable[.]

Or, at least, to be safe. The model where jshttp is a company receiving income and distributing payroll—that model is well-established and understood, even if it is complex. If we say that Company A is independently contracting with 10 individuals, then we're going against the grain of the global economy and introducing a new model. I don't think that's where we want to spend our energy. Play it out: we get big enough for someone to care whether our model is legal, and the way questions of the form "Is this legal?" get answered is through litigation. Establishing new law is not our modus operandi. Our MO is finding ways to build our abstractions atop existing law.

[chadwhitacre]

Is it necessary to have a company or is a sole proprietorship as a legal entity (+ contractors) enough?

@fenryxo At this point I believe a sole proprietorship will be fine. I would love to find a way to provide a "company as a service," but for the foreseeable future Gratipay is going to have to offload nearly all of the responsibility for accounting for contractors, employees, and/or owners to you, the team/company customer.

[chadwhitacre]

@fenryxo Have you used contractors in the past? Is it a process you're familiar/comfortable with? Was that for Nuvola or was that in other contexts?

[jiri-janousek]

@whit537. No, I haven't used contractors yet as the Nuvola Player funding haven't reached the threshold for revenue sharing. However, I've talked to my accountant/tax advisor about this and it would be feasible to have contractors once project funding gets higher. On the other hand, it makes no sense to set up a (limited liability) company until really big money are involved.

[chadwhitacre]

However, I've talked to my accountant/tax advisor about this and it would be feasible to have contractors once project funding gets higher.

Awesome. :-)

On the other hand, it makes no sense to set up a (limited liability) company until really big money are involved.

Some day! :-)

[silverhook]

Gratipay 2.1: Payments and payroll for open companies.

Is it necessary to have a company or is a sole proprietorship as a legal entity (+ contractors) enough?

Will an NGO/NPO be enough? Or will hackerspaces fall through this filter?

[chadwhitacre]

Will an NGO/NPO be enough?

Definitely enough.

Or will hackerspaces fall through this filter?

I hope not! :-)

Echoing @ehmatthes comments at https://github.com/gratipay/inside.gratipay.com/issues/251#issuecomment-112550580, I'm using the term "open company" loosely. A non-profit can definitely be "an open company in gratipay's eyes."

[chadwhitacre]

Alright, let's bring this in for a landing. We have 24 tickets still open on the Pivot milestone, and this is the main ticket.

[chadwhitacre]

I've been looking at site copy (https://github.com/gratipay/gratipay.com/issues/3398) today, specifically the About pages. I guess I was feeling overwhelmed and that seemed like an easy place to start that will certainly provide value when we drive traffic for #3539. It also solidifies the work we did to standardize nomenclature, and queues us up to revise the Team application in https://github.com/gratipay/gratipay.com/issues/3677.