sort out "Teams of one" #82
Comments
|
cc: @book @davorg @gkz @drypot @bzg @briandfoy @cobbzilla @pjf We're reviewing our reviewing policies around "Teams of one." You're welcome to weigh in. :-) |
|
I'm not sure I understand the underlying issue. I would love to weigh in, but I'm not sure I even understand the possible dimensions along which potential policy options could be proposed. Would you be able to offer some suggestions/examples? |
|
If I understand correctly, teams of one shouldn't be treated any differently. Most teams have a single specific project they are working on, but some teams of one are saying "look at all these things I do" which can't be considered a specific project (i.e., the only thing in common among those projects is the author, in which case it is unclear to which project the money is going--is this a legal issue?). Gratipay 2.0 was supposed to be about open work with money tied to a specific project. Isn't the secondary point that we want to help "teams of one" become "teams of more than one"? In which case, Alice joining Bob's "team of one" means that Alice may be receiving funding for projects of Bob's that she didn't work on. One project = one team seems the simplest way to deal with accounting, both for Gratipay and the teams themselves. A project may span multiple repositories, but the theme and goals should be consistent. |
|
@mattbk I think this is the right idea. I have paying work, but I do dream some day of supporting myself more based on my open source work, which runs the gamut of utilities, frameworks and applications. I'd like to remain able to accept donations for all of my projects under one umbrella account. I'm not ready to establish a C corp or LLC for this sort of thing, because in California that means $800/year in fees (+ filing tedium). So I count it as personal income. That said it's such a small amount I wonder if solo developers are not very desirable customers from Gratipay's POV. |
|
The current structure allows you to accept donations under one (~user) account, while keeping the projects separate, because you can have as many teams as you want. This is good for you and good for anyone who begins contributing to one of your projects so much that you want to bring them on as a team member in Gratipay. The more I think about it, the more I see it as a feature, not a bug. Even if each project/team brings in only a small amount of money, if you are able to contribute to several at once, you can theoretically be funded fairly steadily, as can anyone else who is working on one or more projects.
I think the small teams (the long tail) are exactly what Gratipay needs to be supporting. Sometimes the price of a coffee every week is enough for a person to keep working on a project, because someone (or multiple someones) out there thinks it's worthwhile. The 2.0 purpose of Gratipay is to fund open work. I think part of that is bringing together people who think that's a good idea, and who can cross-pollinate on projects. This isn't very well built-in right now, but my ideal that not only would Gratipay exist to fund the open work, it would connect those one-person teams to other people--and then you've doubled the amount of time that can go into the project. |
|
I am yet another "team of one". While encouraging collaboration is great, I have a lot of one-off projects that aren't typically worth formalizing into full fledge Gratipay teams. However, I would love to still get donations if someone wants to thank me for my work. https://github.com/twolfson?tab=repositories I know that historically I haven't gotten many funds but iirc |
Maybe this is the kicker for Gratipay to solve. What's the lowest bar we can put on team formation while still fulfilling our legal obligation for payments to be for specific goods and services? For example, is it implied that a public Github repository fulfills all requirements except "fit" (I don't know, that's why I'm asking)? |
This strikes me as a good rule of thumb for projects that don't fit on Gratipay. We certainly want to encourage small side projects on Gratipay, but the question is, what could a project become? We want projects that could grow naturally into larger projects that sustain multiple contributors, even if at any given moment, most of the Teams on Gratipay are small. |
... and we want that because we're trying to build an open economy, where individuals can move relatively freely between Teams offering work. As an individual I should be able to visit Gratipay and know that I could start working for any Team I find on there. |
|
Maybe my work isn't relevant with Gratipay any more. I initially joined Gratipay to receive recurring donations for my efforts on personal projects. Based on this thread, it sounds like that's no longer the case -- Gratipay is moving towards a team oriented/full time developer approach. Unfortunately, my workflow and most of my projects don't fit that mold. To clarify, they are typically personal and usually developed in one fell swoop (focusing on one thing well). There are revisions and patches added on at later/more sparse points in time but typically everything is upfront. A lot of effort is still put into each of those chunks of time (I think of open source as my part time job) but if we look at all of the time I spend, it's never focused on a single project. |
|
@twolfson I feel like I'm in the same boat. I understand Gratipay has a business to run; every startup has to find its own way. Perhaps there is another company more focused on indy open source developers? I would sign up today if I knew of one. |
|
Same here. I don't think Gratipay should put any constraint on the governance of the projects it helps getting donation for. I primarily used Gratipay to avoid Paypal, and to be part of a community of individuals who dare to ask donations for what they do - individually or collectively. The concept of teams is fine, and the way Gratipay handles them is good too, but personal projects should definitely be accepted. |
On the other hand, think of all the small businesses that take their name from their owner: "Alice's Restaurant," "Bob's Truck and Shoe Repair." How is "gkz-open-source" or "cobzilla software" any different? I'm coming around to the opposite position from where I started: I'm now inclined to say that Teams deriving their brand identity from an individual is fine. I'm realizing that my big concern is that we not surprise small Teams on Gratipay with the bureaucracy that's going to hit you when someone wants to join your Team. Having a Team on Gratipay involves both a right and a responsibility:
By creating a Team on Gratipay, you are opening yourself up to the possibility that someone will contribute some work to your project/company, and then expect to share your revenue. On Gratipay, it's the worker's right to initiate the work relationship and expect this share of revenue, and it's the Team's responsibility to accept the work (assuming sufficient quality) and to provide the share of revenue. But the brand identity of the Team is orthogonal: Bob's Truck and Shoe Repair might well employ a few others besides Bob, and there's no reason Cobzilla Software couldn't do the same. And of course there are limits: Carl can't take revenue that Bob doesn't have! And Bob himself gets to control how much revenue is available to share. Even then, if Bob isn't making any revenue available to share, then he's not going to attract any collaborators. I can imagine someone abusing the system—making a lot of money through Gratipay but not sharing any of it—but probably our up-front "open work" filter will lessen the chance of that, and the system will be largely self-balancing. More to the point, though, this is all academic until we bring back payroll. :-) |
|
P.S. See gratipay/inside.gratipay.com#242 for lengthy discussion on how to legally relate members to Teams. |
|
Glad to hear solo teams are back on the table =) For reference, any time I get a major contributor on a personal project, I will likely create a separate Gratipay team (as you listed in your example): |
This is a good goal to have. I guess my fear is still that the "Bob's Truck and Shoe Repair" team might make most of its money on the truck repair. If Alice contributes substantially to the shoe repair side of things, she should receive commensurate payroll--but should her pay be commensurate with the shoe repair aspect of things, or the entire operation? I guess this is the part about openness and trust. ACTUALLY, since a team is the smallest unit, there's no telling (within Gratipay) which side of Bob's Truck and Shoe Repair is bringing in more gifts! So a team set up in this way really is all-or-nothing, and then each team member may feel more free to float between/contribute to projects within that team, because they're already on the payroll. There's a certain amount of positive feedback and/or justice in that. |
|
Okay! Hearing no objections, I'm going to close this and proceed to |
|
Hooray! Sorry I've not been around for the discussion, the Australian conference season has had me in a different city every week! x_x ~ pjf |
|
!m @pjf :-) |
|
@whit537 Can you explain the new "teams of one" policy at http://inside.gratipay.com/howto/review-teams? Does it need to be in TOS anywhere? |
|
@mattbk I think "teams of one" is up in the air again on gratipay/inside.gratipay.com#432. |
We're being inconsistent in how we apply the "open work" criterion to "Teams of one." Let's review the cases at hand and rationalize our policy for these cases.
The text was updated successfully, but these errors were encountered: