Closed chadwhitacre closed 9 years ago
This week I'm trying to push through a big confusion explosion from the end of last week, because confusion is painful. The two milestones we've been looking at for the past month are Pivot and Balanced Shutdown. One of the Pivot clean-up items exploded into a new milestone all its own: Payroll. Then, over on Balanced Shutdown, we got canned by Citizens (oh no!) and then picked up by Zipmark (yay!) ... but we've still got a lot of work to do to come into compliance: that's the new AML Program milestone.
This week we need to keep all four of these milestones topped up.
Ooh! Good find on blockdiag, @techtonik! What is "TeamsKill"?
@techtonik et al., here's a representation of the state of the onion as I see it:
@whit537 I thought that we killed Teams and now you can only get and give if you're a legal entity.
I thought that we killed Teams and now you can only get and give if you're a legal entity.
In that case, you are more clear-sighted than I am, because I just reached this conclusion yesterday. :)
Yes, I believe we need to "fine-tune the pivot" by replacing "teams" with "companies." Having raced down the rabbit-hole on #242 and #211, I think you're right that we need to kill Teams insofar as Teams are/were a light-weight revenue sharing mechanism. Light-weight isn't going to cut it, due to legal concerns vis-à-vis employment law (this is a second round in quick succession of responding to legal concerns; the first round was vis-à-vis AML law and is still on-going).
I'd like to process #179 before proceeding further down this path:
It's easier for a successful volunteer Free Software project to get money than it is to decide how to spend it. While paying developers is easy, it can carry unintended negative consequences. This essay explores problems and benefits of paying developers in volunteer free and open source projects and surveys strategies that projects have used to successfully finance development while maintaining their volunteer nature.
We should never replace people
with company
, because it then become de-personalized and turn people again into replaceable corporate assets. We need to save the team
concept and protect that vision. That legal system was created to help people, not to enslave and reformat them. It just wasn't created with distributed open source teams in mind, so our mission is to enable economy to for for those people, not vice versa.
Otherwise we are just became an accounting system. Something that SF Conservancy failed to crowdsource money for - http://sfconservancy.org/npoacct/ - and we can close that goal for them in exchange for some legal help.
Hey all, I wanted to share (with permission) some encouraging feedback from ~mitsuhiko (author of Flask, Jinja2, etc.). He joined Gratipay when we were seven days old and still called Gittip and still pronounced "Git Tip." He has been receiving since week three. I've highlighted some especially encouraging parts. I wanted to share this with you all because I think it's a good boost for our morale as we keep pushing through the Balanced shutdown and all of the fallout from that. Let's do this! :dancer:
First of all: I really like what you guys are doing and I also like where this is pivoting to. Tax reasons were a big reason why I asked to suspend payouts until I have things figured out on my side. I nearly forgot about this and was reminded of it after the recent Gratipay 2.0 announcement.
I like the team concept and I would love to use it. However for the balance that exists currently I would prefer if that was sent to my company instead which is used for taxing my personal income in relation to my Open Source projects.
My company: []
Projects funds were raised for: Pocoo Software Libraries Development of Flask, Jinja2, Werkzeug, MarkupSafe, Click Hosting of pocoo.org and related infrastructure for those projects
I would like to separately apply for a team later on which I would use to fund the server costs specifically and the ability to pay out to contributors to my projects, but that would have to be a separate step.
If a payout does take place (and is possible from your side) I would probably need some paper with your company’s information on their and a description of the money transfer that I can make tax on my side happy as well.
I like this idea of recording encouragement on the Radar. From FD2306:
I really like your product so I hope you keep charging ahead on it.
We should never replace
people
withcompany
, because it then become de-personalized and turn people again into replaceable corporate assets. We need to save theteam
concept and protect that vision. That legal system was created to help people, not to enslave and reformat them. It just wasn't created with distributed open source teams in mind, so our mission is to enable economy to [work] for those people, not vice versa.
I love you, @techtonik. :-)
!m @techtonik
We need to save the
team
concept and protect that vision.
I've been thinking that we should revisit the term "open company" for use on Gratipay, with a stronger definition than is used by OCI (where it's intentionally vague to provide a "big tent"):
An open company is a company with work that an individual can start performing without requiring explicit permission from the company, with a clear path to employment or ownership.
Gratipay—payments and payroll for open work companies.
Here's a simpler diagram showing our current hot spots (yellow):
Weeeeee have a lot of hot spots. :)
It's hard to tell what are the hottest. I'm thinking that this week it's 1.0 balances and Braintree.
Yeah, we need both of those for tomorrow's payday.
hot spot | source of pressure | relative pressure | relative difficulty | notes |
---|---|---|---|---|
releasing 1.0 balances | users | 4 | 1 | We should be able to implement a flag in the db and have payday look at it, with an admin knob on /~user/settings . |
payroll | team | 2 | 4 | @rohitpaulk's comment at https://github.com/gratipay/inside.gratipay.com/issues/242#issuecomment-110664966 takes some of the pressure off. |
closing accounts | users | 1 | 4 | Includes a "push upstream" final distribution method. |
Braintree | vendors | 5 | 3 | The migration to Braintree is done, but we have a regression: we need to stop charging failed cards. This is super-high pressure because we're actually on Wells Fargo's radar, and we have a history of getting canned by banks. :-( We should be able to implement a naive solution quickly. |
Zipmark | vendors | 3 | 3 | They have a data file from Balanced, and are waiting for us to implement sufficient AML controls before proceeding. Once we have the green light, the actual implementation shouldn't be too bad. |
Risk Program | regulators | 4 | 5 | There is a lot of work to do here. I can barely start thinking about it because I'm feeling so much pressure on the 1.0 balances and Braintree issues, which are also less work. |
Conclusion: let's focus on 1.0 balances and Braintree for this week, and then next week look in earnest at building out our AML program to clear Zipmark's bar.
Okay! https://github.com/gratipay/gratipay.com/issues/3481 :swimmer:
From https://snowdrift.coop/p/snowdrift/w/en/othercrowdfunding
Of the other sites, Gratipay is the closest and most philosophically aligned. Like Snowdrift.coop, Gratipay is FLO, focuses on FLO projects, takes no fee, and emphasizes ethical and honorable ideals. However, their unilateral regular donations are not a new funding model in any sense. The fundamental issues facing the FLO economy, particularly the snowdrift dilemma, are not answered by Gratipay’s system which has no mutual assurance. Beyond being yet another website where projects can solicit donations, Gratipay’s primary service is as a payroll system to facilitate the filtering of funds to the various members of project teams. Despite its own FLO code and FLO focus, Gratipay relies on third-party proprietary services for their communication (e.g. Google Hangouts), ticketing (GitHub), translation (Transifex), blogging (Medium), and so on. Although work is in progress to offer a built-in log-in, the site login currently requires the use of third-party log-ins with emphasis on the proprietary sites Twitter, GitHub, and Bitbucket (although they now also offer log-in through the FLO project OpenStreetMap). Of course, nearly all the other platforms we reviewed have similar problems and worse problems. We only point out such specific complaints regarding Gratipay because they are otherwise unusually honorable, well-intentioned, and community-oriented.
:-)
:-)
Alright, I'm at Inbox 2, GitHub 0. We're at Support 12, but there's nothing urgent in there that isn't blocking on payday (https://github.com/gratipay/gratipay.com/issues/3540).
https://github.com/gratipay/gratipay.com/issues/3540 :swimmer:
Feelin' good over here. Any day when we land seven pull requests is a good day. :sunglasses:
!m @rohitpaulk et al.
!m @whit537
Make that eight :wink:
:dancer:
Eventful day for @github too, they just simplified their UI a bit - https://cloudup.com/cn2gnism_eA
(Screenshot taken from https://twitter.com/jbrooksuk/status/609085435642544129)
Support 8.
@whit537 can you merge https://github.com/gratipay/inside.gratipay.com/pull/183 so that I can close the gestalt and pick next one? =)
:-)
!m @techtonik
Inbox 1, GitHub 0. Made a pass through support. We're at 9, including 3 security disclosures that I need to handle.
I'm doing a little banking this morning (consulting gig got called off for today), related to https://github.com/gratipay/inside.gratipay.com/issues/240 and https://github.com/gratipay/gratipay.com/issues/3531.
Alright! Done for the week. I think I may try to be offline all weekend. See you all on Monday! :-)
In the meanwhile..
What are you working on this week and why?
last week