馃椈 Make it easier for companies to fund open source #987

Closed
chadwhitacre opened this Issue Jan 16, 2017 · 66 comments

Comments

Projects
None yet
4 participants
@chadwhitacre
Contributor

chadwhitacre commented Jan 16, 2017

Picking up from gratipay/gratipay.com#4135 ...


鉁堬笍 This is the flight deck for the Make it easier for companies to fund open source epic. 鉁堬笍


Why?

See http://inside.gratipay.com/big-picture/strategy.

When are we done?

The definition of "done" is an order of magnitude change from the status quo:

  • $40,000/yr 鈥 our present volume as of Q3 2017
  • $728,000/yr 鈥 our volume at Peak Gittipay
  • $20,000,000/yr
  • $200,000,000/yr 鈥 status quo
  • $2,000,000,000/yr

We are going to succeed by getting good marketing and product development loops going.

Todo


鉁堬笍 This is the flight deck for the Make it easier for companies to fund open source epic. 鉁堬笍


@chadwhitacre chadwhitacre referenced this issue in gratipay/gratipay.com Jan 16, 2017

Closed

#4296

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

FOCUS:

  • Find early adopters
  • Offer testing
  • Currency testing
  • Utility testing
  • Scale to fit

five-experiments

Contributor

chadwhitacre commented Jan 16, 2017

FOCUS:

  • Find early adopters
  • Offer testing
  • Currency testing
  • Utility testing
  • Scale to fit

five-experiments

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

I consider us to be at the utility testing phase. Here is my reasoning:

  1. Find early adopters. The state of the art is OpenCollective, which is essentially Gittipay 1.0: a couple dozen companies giving low six figures a year in aggregate. A few popular projects (webpack) receive most of the money. All of the companies on Gittipay 1.0 and OpenCollective are early adopters. They are solving their problem poorly today using OpenCollective.
  2. They want your help solving it. They did under Gittipay 1.0, and, as @clone1018 pointed out, Gratipay still has some brand recognition (see also Gratipay mention here). OpenCollective picked them up from us, which means they still want help from someone.
  3. They will "pay" you to solve it. This was never in question under Gittipay 1.0, and it stands to reason: companies that are pwyw'ing for open source are going to pwyw for the platform, too. We saw 5%. 馃憤
  4. You can solve it. We did solve it, and OpenCollective is solving it now: they're the new status quo, pretty close to the old status quo. The question is whether we can solve it even better. This is where the idea of aggregation comes in, as discussed on gratipay/gratipay.com#4135.

What is the MVP for aggregation? That's what we need to define and build and test.

Contributor

chadwhitacre commented Jan 16, 2017

I consider us to be at the utility testing phase. Here is my reasoning:

  1. Find early adopters. The state of the art is OpenCollective, which is essentially Gittipay 1.0: a couple dozen companies giving low six figures a year in aggregate. A few popular projects (webpack) receive most of the money. All of the companies on Gittipay 1.0 and OpenCollective are early adopters. They are solving their problem poorly today using OpenCollective.
  2. They want your help solving it. They did under Gittipay 1.0, and, as @clone1018 pointed out, Gratipay still has some brand recognition (see also Gratipay mention here). OpenCollective picked them up from us, which means they still want help from someone.
  3. They will "pay" you to solve it. This was never in question under Gittipay 1.0, and it stands to reason: companies that are pwyw'ing for open source are going to pwyw for the platform, too. We saw 5%. 馃憤
  4. You can solve it. We did solve it, and OpenCollective is solving it now: they're the new status quo, pretty close to the old status quo. The question is whether we can solve it even better. This is where the idea of aggregation comes in, as discussed on gratipay/gratipay.com#4135.

What is the MVP for aggregation? That's what we need to define and build and test.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

Actually, we are at (5), because Gittipay 1.0/OpenCollective was/is the manual step. Utility testing is done. Now we need to scale by automating and streamlining the process of pairing companies with projects. This is our chance to get back in the game!

Contributor

chadwhitacre commented Jan 16, 2017

Actually, we are at (5), because Gittipay 1.0/OpenCollective was/is the manual step. Utility testing is done. Now we need to scale by automating and streamlining the process of pairing companies with projects. This is our chance to get back in the game!

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

From @nobodxbodon at #964 (comment):

below is an attempt of drafting a very rough timeline:

Jan 28, get user story settle down, start dev work
Feb 17, finish pretotypes of UI design
Feb 20 - Apr 7, dev + testing
April 10, official launching
April 10-28, gather feedback, find solutions, fix & improve

Hopefully it's not too ridiculous?

I think we want to be way more fine-grained than this. My two best attempts to date to define and sequence the work required are

List A | gratipay/gratipay.com#4135 (comment)

  1. load up npm in the Gratipay db鈥攄one!
  2. mirror all npm packages on Gratipay鈥攄one!
  3. enable npm packages to opt-in to receive funding
  4. enable pledging to projects that haven't opted in yet
  5. aggregate opt-in so maintainers can opt-in many at once
  6. maybe naive package.json parsing with no deep traversal and equal split
  7. possibly deep traversal (deps of deps)
  8. eventually maybe fine-tuning of "bundles" like you're talking about

and the todo in the description of the Integrate npm flight deck:

List B | gratipay/gratipay.com#4148

Checkpoint 1: Inert /on/npm/foo/ Pages

  • wrap marky-markdown (#4154)
  • load up npm (#4153, #4158)
  • load up npm readmes (#4159, #4160, #4161, #4162, #4164, #4176, #4179, #4180, #4181, #4182)
  • stop storing readmes after all (#4211)
  • add inert (can't actually give to them) /on/npm/foo pages (#4212)

Checkpoint 2: Giving to Packages

  • link packages to teams (#4155)
  • opt in or out from /on/npm/foo/ pages via email verification
  • add payment widget on /on/npm/foo/ pages

Checkpoint 3: Easy Sign-up

  • bulk manage payments from /on/npm/ pages

Nice to Have

  • move search into {% content %} (leaving social network jump in sidebar)
  • merge current result types together (~user via username, ~user via profile statement)
  • add Teams to local index for inclusion in results
  • mix npm packages into search (#4147)
  • pledging to as-yet-unclaimed packages
  • load up npm incrementally (reticket from #4153)
  • deal intelligently with unpublished packages (reticket from gratipay/gratipay.com#4148 (comment))
  • we seem to get two H1s on https://www.npmjs.com/package/resize-img
  • syntax highlight

Promotion

  • update the "鈽 announcement 鈽" link (#4149)
  • Publish a blog post.
  • Promote the heck out of it!
Contributor

chadwhitacre commented Jan 16, 2017

From @nobodxbodon at #964 (comment):

below is an attempt of drafting a very rough timeline:

Jan 28, get user story settle down, start dev work
Feb 17, finish pretotypes of UI design
Feb 20 - Apr 7, dev + testing
April 10, official launching
April 10-28, gather feedback, find solutions, fix & improve

Hopefully it's not too ridiculous?

I think we want to be way more fine-grained than this. My two best attempts to date to define and sequence the work required are

List A | gratipay/gratipay.com#4135 (comment)

  1. load up npm in the Gratipay db鈥攄one!
  2. mirror all npm packages on Gratipay鈥攄one!
  3. enable npm packages to opt-in to receive funding
  4. enable pledging to projects that haven't opted in yet
  5. aggregate opt-in so maintainers can opt-in many at once
  6. maybe naive package.json parsing with no deep traversal and equal split
  7. possibly deep traversal (deps of deps)
  8. eventually maybe fine-tuning of "bundles" like you're talking about

and the todo in the description of the Integrate npm flight deck:

List B | gratipay/gratipay.com#4148

Checkpoint 1: Inert /on/npm/foo/ Pages

  • wrap marky-markdown (#4154)
  • load up npm (#4153, #4158)
  • load up npm readmes (#4159, #4160, #4161, #4162, #4164, #4176, #4179, #4180, #4181, #4182)
  • stop storing readmes after all (#4211)
  • add inert (can't actually give to them) /on/npm/foo pages (#4212)

Checkpoint 2: Giving to Packages

  • link packages to teams (#4155)
  • opt in or out from /on/npm/foo/ pages via email verification
  • add payment widget on /on/npm/foo/ pages

Checkpoint 3: Easy Sign-up

  • bulk manage payments from /on/npm/ pages

Nice to Have

  • move search into {% content %} (leaving social network jump in sidebar)
  • merge current result types together (~user via username, ~user via profile statement)
  • add Teams to local index for inclusion in results
  • mix npm packages into search (#4147)
  • pledging to as-yet-unclaimed packages
  • load up npm incrementally (reticket from #4153)
  • deal intelligently with unpublished packages (reticket from gratipay/gratipay.com#4148 (comment))
  • we seem to get two H1s on https://www.npmjs.com/package/resize-img
  • syntax highlight

Promotion

  • update the "鈽 announcement 鈽" link (#4149)
  • Publish a blog post.
  • Promote the heck out of it!
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

I also want to capture the following comment from #637 (comment), because it explains the bigger picture that aggregation fits into. "Making it easy for companies to give to open source" means making it technically easy through aggregation, invoicing, etc., but also socially easy through virality and consequent new cultural norms.

The fundamental idea is to get a viral loop going again like we had under Gittipay 1.0. As @clone1018 points out, that happened with a not-so-fancy visual design, suggesting that we could remove that piece from this grant without detracting from the fundamental idea. At the very least, we could plow it in with feature development rather than itemizing it separately.

Here's the way Gittip worked:

  • We had pages on Gittip representing social media accounts, /on/github/bbangert/, /on/twitter/oprah/, etc.
  • You could "pledge" to any of these "accounts elsewhere." A pledge was just that: a promise to give money if the person accepted it by joining Gittip. This created incentive for people to join: free money!
  • Once you signed up, you would put a badge on your README, and/or a widget on your blog. Now you're promoting the network by promoting yourself.
  • Top givers and receivers were on the homepage.
  • We really started taking off when you could give charitably to diversity activists and more pragmatically to open source projects.

List C | #637 (comment)

Basically I think we need to reimplement that, but for projects instead of individuals.

I do think there's a role for package manager integration (more on that at gratipay/gratipay.com#4135 (comment)), but the bigger picture is bigger.

Contributor

chadwhitacre commented Jan 16, 2017

I also want to capture the following comment from #637 (comment), because it explains the bigger picture that aggregation fits into. "Making it easy for companies to give to open source" means making it technically easy through aggregation, invoicing, etc., but also socially easy through virality and consequent new cultural norms.

The fundamental idea is to get a viral loop going again like we had under Gittipay 1.0. As @clone1018 points out, that happened with a not-so-fancy visual design, suggesting that we could remove that piece from this grant without detracting from the fundamental idea. At the very least, we could plow it in with feature development rather than itemizing it separately.

Here's the way Gittip worked:

  • We had pages on Gittip representing social media accounts, /on/github/bbangert/, /on/twitter/oprah/, etc.
  • You could "pledge" to any of these "accounts elsewhere." A pledge was just that: a promise to give money if the person accepted it by joining Gittip. This created incentive for people to join: free money!
  • Once you signed up, you would put a badge on your README, and/or a widget on your blog. Now you're promoting the network by promoting yourself.
  • Top givers and receivers were on the homepage.
  • We really started taking off when you could give charitably to diversity activists and more pragmatically to open source projects.

List C | #637 (comment)

Basically I think we need to reimplement that, but for projects instead of individuals.

I do think there's a role for package manager integration (more on that at gratipay/gratipay.com#4135 (comment)), but the bigger picture is bigger.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

So that's three lists of work for this epic, plus the (unsequenced) user stories from

List D | #964 (comment)

  • giver searches by keywords in all the npm packages, and result is sorted in some order (popularity?)
  • giver uses the dependency file to retrieve all the contained packages
  • giver pays to 1 npm package
  • giver pays to multiple num packages, specifying amount for each
  • giver pays to multiple num packages, with one total amount
    • gratipay decides how to allocate the amount among the packages
  • giver gets reports about how much of their giving is claimed by which team, and how much is not
  • gratipay reaches out to receiver that's not signed up on gratipay to notify there's giving to them
  • gratipay holds the amount that no one clams
  • if no one claims for the giving to a certain project for too long, gratipay notifies the giver, and let them choose how to deal with the giving
Contributor

chadwhitacre commented Jan 16, 2017

So that's three lists of work for this epic, plus the (unsequenced) user stories from

List D | #964 (comment)

  • giver searches by keywords in all the npm packages, and result is sorted in some order (popularity?)
  • giver uses the dependency file to retrieve all the contained packages
  • giver pays to 1 npm package
  • giver pays to multiple num packages, specifying amount for each
  • giver pays to multiple num packages, with one total amount
    • gratipay decides how to allocate the amount among the packages
  • giver gets reports about how much of their giving is claimed by which team, and how much is not
  • gratipay reaches out to receiver that's not signed up on gratipay to notify there's giving to them
  • gratipay holds the amount that no one clams
  • if no one claims for the giving to a certain project for too long, gratipay notifies the giver, and let them choose how to deal with the giving
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

tumblr_m6p5v8xlyd1rn81gb

From where you stand now (A), you see the mountaintop you鈥檙e trying to reach in the distance (Z), and you have a general idea of what lies between, but the only step you鈥檙e really clear on is the next one (B). So take the next step!

http://blog.gittip.com/post/26568603571/the-plan/

Contributor

chadwhitacre commented Jan 16, 2017

tumblr_m6p5v8xlyd1rn81gb

From where you stand now (A), you see the mountaintop you鈥檙e trying to reach in the distance (Z), and you have a general idea of what lies between, but the only step you鈥檙e really clear on is the next one (B). So take the next step!

http://blog.gittip.com/post/26568603571/the-plan/

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

What's the next step? Basically I think we close out the "Integrate npm" ticket and project, since we've reached its Checkpoint 1 and the scope is way big over therex. This new Epic ticket gives us another level of abstraction at which to manage the whole thing. Checkpoint 2 becomes our next project under this epic. Checkpoint 2 is about "claiming" packages, which turns them into projects on Gratipay that can be given money to. Reticketing that now ...

Contributor

chadwhitacre commented Jan 16, 2017

What's the next step? Basically I think we close out the "Integrate npm" ticket and project, since we've reached its Checkpoint 1 and the scope is way big over therex. This new Epic ticket gives us another level of abstraction at which to manage the whole thing. Checkpoint 2 becomes our next project under this epic. Checkpoint 2 is about "claiming" packages, which turns them into projects on Gratipay that can be given money to. Reticketing that now ...

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 16, 2017

Contributor

Actually, let's try a project board for this epic, to include both issues and cards for the project boards for the actual projects. 馃惌 I'm putting #964 and #969 on there ...

Contributor

chadwhitacre commented Jan 16, 2017

Actually, let's try a project board for this epic, to include both issues and cards for the project boards for the actual projects. 馃惌 I'm putting #964 and #969 on there ...

@nobodxbodon

This comment has been minimized.

Show comment
Hide comment
@nobodxbodon

nobodxbodon Jan 17, 2017

About allow for one-off tips and prefund team account, are they on stage 2? I imagine company would prefer to do a one-off (and paid out weekly) instead of an recurring payment, even more than an individual giver.

About allow for one-off tips and prefund team account, are they on stage 2? I imagine company would prefer to do a one-off (and paid out weekly) instead of an recurring payment, even more than an individual giver.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 17, 2017

Contributor

Maybe. What does "stage 2" mean?

Contributor

chadwhitacre commented Jan 17, 2017

Maybe. What does "stage 2" mean?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 17, 2017

Contributor

#964 (comment) ...

the scope is too much for stage 1

And what is stage 1? :-)

Contributor

chadwhitacre commented Jan 17, 2017

#964 (comment) ...

the scope is too much for stage 1

And what is stage 1? :-)

@nobodxbodon

This comment has been minimized.

Show comment
Hide comment
@nobodxbodon

nobodxbodon Jan 17, 2017

Oh stage 1 is meant for pre-OSCON, and stage 2 for post-OSCON

Oh stage 1 is meant for pre-OSCON, and stage 2 for post-OSCON

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 18, 2017

Contributor

Ah, gotcha. :-)

apollo_11_first_stage_separation

Contributor

chadwhitacre commented Jan 18, 2017

Ah, gotcha. :-)

apollo_11_first_stage_separation

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 18, 2017

Contributor

Yeah, I'm not thinking of this epic as having a deadline of OSCON (#948). This epic ain't done until we go from 0 to 24 company givers and from $800 to $14,000 per week in volume. If anything, OSCON will be the beginning of the curve that will get us there, not the end.

We basically want to get as far as we can with product development by May so that we have something potentially interesting to show people at #948 and also #920. If we have one company (attn: @jdorfman) giving to three projects by OSCON using these new features, I'll be thrilled.

The point of #987 (comment) was that we don't know all of the steps along the way, just the goal and the next step. This is fractal, actually. We don't even know all the steps between here and OSCON, let alone between OSCON and landing this epic by reaching 24 companies giving $14,000/wk. But we do know the next step: Claiming packages.

Let's go! 馃椈

Contributor

chadwhitacre commented Jan 18, 2017

Yeah, I'm not thinking of this epic as having a deadline of OSCON (#948). This epic ain't done until we go from 0 to 24 company givers and from $800 to $14,000 per week in volume. If anything, OSCON will be the beginning of the curve that will get us there, not the end.

We basically want to get as far as we can with product development by May so that we have something potentially interesting to show people at #948 and also #920. If we have one company (attn: @jdorfman) giving to three projects by OSCON using these new features, I'll be thrilled.

The point of #987 (comment) was that we don't know all of the steps along the way, just the goal and the next step. This is fractal, actually. We don't even know all the steps between here and OSCON, let alone between OSCON and landing this epic by reaching 24 companies giving $14,000/wk. But we do know the next step: Claiming packages.

Let's go! 馃椈

@chadwhitacre chadwhitacre referenced this issue in gratipay/gratipay.com Jan 19, 2017

Closed

Spec out claim/unclaim/reclaim packages #4297

0 of 5 tasks complete
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 20, 2017

Contributor

In slack we're considering that the next step should maybe be "Recognize companies" instead of "Claim packages," since historically that and the associated step of breaking anonymity has historically been such a strong feature request. Maybe we should listen to our users! 馃槺

Contributor

chadwhitacre commented Jan 20, 2017

In slack we're considering that the next step should maybe be "Recognize companies" instead of "Claim packages," since historically that and the associated step of breaking anonymity has historically been such a strong feature request. Maybe we should listen to our users! 馃槺

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 20, 2017

Contributor

Yeah, +1s from @nobodxbodon @mattbk @JessaWitzel. Let's do it!

Contributor

chadwhitacre commented Jan 20, 2017

Yeah, +1s from @nobodxbodon @mattbk @JessaWitzel. Let's do it!

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jan 20, 2017

Contributor

I'm casting about for the scope here. There seem to be two broad cases:

  1. Receivers want to know who their givers are, for various reasons, but especially so they can provide services/products/rewards to them; gratipay/gratipay.com#236 is mostly about this.
  2. Givers want to advertise that they give and to whom, as a way of self-promotion. This is the companies paying open source case, and is what gratipay/gratipay.com#2695 is about.

The two can overlap but don't necessarily. We could satisfy (partially? wholly?) givers under (2) by promoting their giving in aggregate: "top giver to npm packages" vs. "top giver to webpack." The former actually sends us right back to Claim packages, while the latter is the current status quo on Open Collective.

We could largely satisfy (1) without public sharing, except insofar as projects want to reward their sponsors precisely with recognition. ;-)

Contributor

chadwhitacre commented Jan 20, 2017

I'm casting about for the scope here. There seem to be two broad cases:

  1. Receivers want to know who their givers are, for various reasons, but especially so they can provide services/products/rewards to them; gratipay/gratipay.com#236 is mostly about this.
  2. Givers want to advertise that they give and to whom, as a way of self-promotion. This is the companies paying open source case, and is what gratipay/gratipay.com#2695 is about.

The two can overlap but don't necessarily. We could satisfy (partially? wholly?) givers under (2) by promoting their giving in aggregate: "top giver to npm packages" vs. "top giver to webpack." The former actually sends us right back to Claim packages, while the latter is the current status quo on Open Collective.

We could largely satisfy (1) without public sharing, except insofar as projects want to reward their sponsors precisely with recognition. ;-)

@chadwhitacre chadwhitacre referenced this issue in gratipay/gratipay.com Feb 8, 2017

Merged

Integrate initial package claiming PRs #4305

25 of 25 tasks complete

@chadwhitacre chadwhitacre changed the title from Make it easier for companies to fund open source to 馃椈 Make it easier for companies to fund open source Feb 8, 2017

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 14, 2017

Contributor

From https://news.ycombinator.com/item?id=13643580:

I really think there's an opportunity to make it easier for companies (large and small) to pay for work on open source projects. The complexities I see (as someone who has done it often):

  • Knowing who (as an individual or an organization) you can give money to to reliably perform the work. So working out a way of managing this would be huge e.g. I want a feature added to Postgres, who the hell do I speak to? Are they reliable? Is their contribution likely to be accepted upstream?
  • The tax/employment logistics can be painful, an intermediary could make that simpler. For large contributions you often have to support multiple people, and this becomes logistical complex VERY easily
  • A lot of folks who make their living being supported to work on open source are scornful or outright malevolent towards the things that corps need (e.g. invoicing, statement of work, liability protection)
Contributor

chadwhitacre commented Feb 14, 2017

From https://news.ycombinator.com/item?id=13643580:

I really think there's an opportunity to make it easier for companies (large and small) to pay for work on open source projects. The complexities I see (as someone who has done it often):

  • Knowing who (as an individual or an organization) you can give money to to reliably perform the work. So working out a way of managing this would be huge e.g. I want a feature added to Postgres, who the hell do I speak to? Are they reliable? Is their contribution likely to be accepted upstream?
  • The tax/employment logistics can be painful, an intermediary could make that simpler. For large contributions you often have to support multiple people, and this becomes logistical complex VERY easily
  • A lot of folks who make their living being supported to work on open source are scornful or outright malevolent towards the things that corps need (e.g. invoicing, statement of work, liability protection)
@kaguillera

This comment has been minimized.

Show comment
Hide comment
@kaguillera

kaguillera Feb 14, 2017

Contributor

馃槺 so what happened to our applications.

Contributor

kaguillera commented Feb 14, 2017

馃槺 so what happened to our applications.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 14, 2017

Contributor

Meaning #836, @kaguillera?

Yes. Not that I disagree with the other way of paying, but it needs to be handled differently:

  • The 'pay someone to do X, which has Y value for us in return' is a very simple value proposition for even the most luddite of finance/legal folks to grok. The details are different, but you're essentially hiring a contractor.
  • On the other hand, it's much less clear to those people what the value proposition is for paying for 'past work' or some amphorphus future work that it's difficult to quantify will have any value to the organization.
  • That's why the above is much better framed as 'sponsorship' and put under PR/dev relations/talent/HR. They're the ones who can best track value from concepts like community engagement and enhancement, improved standing of the company etc
Contributor

chadwhitacre commented Feb 14, 2017

Meaning #836, @kaguillera?

Yes. Not that I disagree with the other way of paying, but it needs to be handled differently:

  • The 'pay someone to do X, which has Y value for us in return' is a very simple value proposition for even the most luddite of finance/legal folks to grok. The details are different, but you're essentially hiring a contractor.
  • On the other hand, it's much less clear to those people what the value proposition is for paying for 'past work' or some amphorphus future work that it's difficult to quantify will have any value to the organization.
  • That's why the above is much better framed as 'sponsorship' and put under PR/dev relations/talent/HR. They're the ones who can best track value from concepts like community engagement and enhancement, improved standing of the company etc
@mattbk

This comment has been minimized.

Show comment
Hide comment
@mattbk

mattbk Feb 18, 2017

Contributor

I added explicit "Why?" and "When are we done?" headers to the top.

I was thinking tonight about @whit537's Slack comments regarding whether we're going to right way, and how we need an ultimate why for every epic, project, and PR. This why should point back to the mission and ideally be noted on the roadmap.

The why I've identified for this epic is "it鈥檚 about getting money into the system in the first place."

Contributor

mattbk commented Feb 18, 2017

I added explicit "Why?" and "When are we done?" headers to the top.

I was thinking tonight about @whit537's Slack comments regarding whether we're going to right way, and how we need an ultimate why for every epic, project, and PR. This why should point back to the mission and ideally be noted on the roadmap.

The why I've identified for this epic is "it鈥檚 about getting money into the system in the first place."

@mattbk mattbk referenced this issue in gratipay/gratipay.com Feb 18, 2017

Closed

Create a corporate giving page #4341

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 11, 2017

Contributor

Alright, we have 3.5 weeks until OSCON. I think our goal should be to deploy claiming before OSCON (#948), and pledging before $ustain (#920).

Here's a schedule for claiming, working backwards from May 5 when I fly to OSCON:

Day of Week Day of Month Goal Other
Wednesday April 12 finish claiming
Thursday April 13 finish claiming
Friday April 14 finish claiming
Saturday April 15
Sunday April 16
Monday April 17 review claiming claiming pre-reqs
Tuesday April 18 review claiming claiming pre-reqs
Wednesday April 19 review claiming claiming pre-reqs
Thursday April 20 review claiming claiming pre-reqs
Friday April 21 review claiming claiming pre-reqs
Saturday April 22
Sunday April 23
Monday April 24 integrate claiming claiming pre-reqs; YC?
Tuesday April 25 integrate claiming claiming pre-reqs; YC?
Wednesday April 26 integrate claiming claiming pre-reqs; YC?
Thursday April 27 integrate claiming claiming pre-reqs; YC?
Friday April 28 integrate claiming claiming pre-reqs; YC?
Saturday April 29
Sunday April 30
Monday May 1 merge & deploy claiming
Tuesday May 2 regressions
Wednesday May 3 regressions
Thursday May 4 prep
Friday May 5 fly to OSCON
Contributor

chadwhitacre commented Apr 11, 2017

Alright, we have 3.5 weeks until OSCON. I think our goal should be to deploy claiming before OSCON (#948), and pledging before $ustain (#920).

Here's a schedule for claiming, working backwards from May 5 when I fly to OSCON:

Day of Week Day of Month Goal Other
Wednesday April 12 finish claiming
Thursday April 13 finish claiming
Friday April 14 finish claiming
Saturday April 15
Sunday April 16
Monday April 17 review claiming claiming pre-reqs
Tuesday April 18 review claiming claiming pre-reqs
Wednesday April 19 review claiming claiming pre-reqs
Thursday April 20 review claiming claiming pre-reqs
Friday April 21 review claiming claiming pre-reqs
Saturday April 22
Sunday April 23
Monday April 24 integrate claiming claiming pre-reqs; YC?
Tuesday April 25 integrate claiming claiming pre-reqs; YC?
Wednesday April 26 integrate claiming claiming pre-reqs; YC?
Thursday April 27 integrate claiming claiming pre-reqs; YC?
Friday April 28 integrate claiming claiming pre-reqs; YC?
Saturday April 29
Sunday April 30
Monday May 1 merge & deploy claiming
Tuesday May 2 regressions
Wednesday May 3 regressions
Thursday May 4 prep
Friday May 5 fly to OSCON
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 12, 2017

Contributor

I'm expecting to self-merge claiming week after next in order to keep on track, if no other reviewers step forward.

Contributor

chadwhitacre commented Apr 12, 2017

I'm expecting to self-merge claiming week after next in order to keep on track, if no other reviewers step forward.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 12, 2017

Contributor

Sounds like @dowski may be able to help us with review!

Per slack the integration branch is gratipay/gratipay.com#4305 and the next PR is gratipay/gratipay.com#4335.

Thanks for any help you can lend, and let me know if you get stuck!

!m @dowski 馃拑

Contributor

chadwhitacre commented Apr 12, 2017

Sounds like @dowski may be able to help us with review!

Per slack the integration branch is gratipay/gratipay.com#4305 and the next PR is gratipay/gratipay.com#4335.

Thanks for any help you can lend, and let me know if you get stuck!

!m @dowski 馃拑

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 20, 2017

Contributor

One day and a week before it's time to ship gratipay/gratipay.com#4305. Getting down to the wire! We'll likely have to shed some weight in order to achieve lift-off. Will consider ...

Contributor

chadwhitacre commented Apr 20, 2017

One day and a week before it's time to ship gratipay/gratipay.com#4305. Getting down to the wire! We'll likely have to shed some weight in order to achieve lift-off. Will consider ...

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 27, 2017

Contributor

We're a day or two behind schedule, which isn't too bad. I think we can make it up. I hope and expect that we'll have gratipay/gratipay.com#4305 deployed as well as updated syncing (pre-req) before I fly to Austin. There will certainly be some things to improve, though. I guess we take those in stride here?

Contributor

chadwhitacre commented Apr 27, 2017

We're a day or two behind schedule, which isn't too bad. I think we can make it up. I hope and expect that we'll have gratipay/gratipay.com#4305 deployed as well as updated syncing (pre-req) before I fly to Austin. There will certainly be some things to improve, though. I guess we take those in stride here?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 27, 2017

Contributor

Alright, using gratipay/gratipay.com#4427 as the new flight deck for the "Claim packages" project, with #1045 for storytelling to accompany the release of that feature.

The thing to think about here is how we plan to go from zero to one. We are building a three-sided marketplace:

  • projects鈥攕upply
  • foundations鈥攊ntermediary
  • companies鈥攄emand

Recall from above:

The definition of "done" is at least two dozen companies supporting open source with at least $14,000/wk[.] Today we are at zero companies giving, and $800/wk.

We need to go from zero companies giving to one company giving.

We also need to go from zero foundations involved to one foundation involved. It's probably worth a discussion about whether foundations are essential to the equation here. I'm currently assuming that they are.

The plan is to prime the demand side through pledging to any npm package.

Once that is deployed we can approach the supply side and say "Hey look what we have over here!"

The two pressure points that foundations resolve are:

  • Pressure from the supply side for fiscal sponsorship.
  • Pressure from the demand side because all of the big enterprises that are already investing heavily in open source are doing so through foundations, chiefly the Linux Foundation and its 30-40 subfoundations. If we're not partnered with LF then we come across as competition ("We're already giving lots of money through LF, why would we need to give through you instead?").

I guess that's the dual importance of foundations to the equation.

Contributor

chadwhitacre commented Apr 27, 2017

Alright, using gratipay/gratipay.com#4427 as the new flight deck for the "Claim packages" project, with #1045 for storytelling to accompany the release of that feature.

The thing to think about here is how we plan to go from zero to one. We are building a three-sided marketplace:

  • projects鈥攕upply
  • foundations鈥攊ntermediary
  • companies鈥攄emand

Recall from above:

The definition of "done" is at least two dozen companies supporting open source with at least $14,000/wk[.] Today we are at zero companies giving, and $800/wk.

We need to go from zero companies giving to one company giving.

We also need to go from zero foundations involved to one foundation involved. It's probably worth a discussion about whether foundations are essential to the equation here. I'm currently assuming that they are.

The plan is to prime the demand side through pledging to any npm package.

Once that is deployed we can approach the supply side and say "Hey look what we have over here!"

The two pressure points that foundations resolve are:

  • Pressure from the supply side for fiscal sponsorship.
  • Pressure from the demand side because all of the big enterprises that are already investing heavily in open source are doing so through foundations, chiefly the Linux Foundation and its 30-40 subfoundations. If we're not partnered with LF then we come across as competition ("We're already giving lots of money through LF, why would we need to give through you instead?").

I guess that's the dual importance of foundations to the equation.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 27, 2017

Contributor

So I guess what that means is that once Claim packages is deployed, we should do a round of outreach to npm maintainers, applying what we've learned from #948 (comment). Let's see what percentage of npm packages (weighted by downloads) we can get on Gratipay. Then we can go to companies and foundations鈥攕ome of whom I've already started conversations with鈥攁nd say "In the past month we've signed up 8% of the packages on npm," or whatever, "Wanna see?"

Contributor

chadwhitacre commented Apr 27, 2017

So I guess what that means is that once Claim packages is deployed, we should do a round of outreach to npm maintainers, applying what we've learned from #948 (comment). Let's see what percentage of npm packages (weighted by downloads) we can get on Gratipay. Then we can go to companies and foundations鈥攕ome of whom I've already started conversations with鈥攁nd say "In the past month we've signed up 8% of the packages on npm," or whatever, "Wanna see?"

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 3, 2017

Contributor

From gratipay/gratipay.com#4148 (comment):

the 400,000 packages on npm dwarf the 200 projects currently on Gratipay

Libraries.io doesn't include OS-level packages, but it turns out Debian only has 57k anyway. I had thought it might be another order of magnitude more, but then again npm is famously microlithic.

Contributor

chadwhitacre commented May 3, 2017

From gratipay/gratipay.com#4148 (comment):

the 400,000 packages on npm dwarf the 200 projects currently on Gratipay

Libraries.io doesn't include OS-level packages, but it turns out Debian only has 57k anyway. I had thought it might be another order of magnitude more, but then again npm is famously microlithic.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 6, 2017

Contributor

I pitched @clone1018 this evening on the idea of doing a manual test of the "Give us $10,000 and a package.json and we will distribute it for you in a way that makes the most sense" proposition by emailing 500 companies and finding 25 to pay into an open source "fund" (think how VCs raise a "fund") that we then distribute based on:

  1. usage in their company,
  2. developer input,
  3. metrics such as pony factor, Open Source Census, and bus factor, and
  4. project wishes (not everyone wants money).

The idea would be to do this with a spreadsheet and private email vs. features on Gratipay.com. Actually what we would do on the site is improve the marketing pages (landing pages? about pages, etc.).

Contributor

chadwhitacre commented May 6, 2017

I pitched @clone1018 this evening on the idea of doing a manual test of the "Give us $10,000 and a package.json and we will distribute it for you in a way that makes the most sense" proposition by emailing 500 companies and finding 25 to pay into an open source "fund" (think how VCs raise a "fund") that we then distribute based on:

  1. usage in their company,
  2. developer input,
  3. metrics such as pony factor, Open Source Census, and bus factor, and
  4. project wishes (not everyone wants money).

The idea would be to do this with a spreadsheet and private email vs. features on Gratipay.com. Actually what we would do on the site is improve the marketing pages (landing pages? about pages, etc.).

@mattbk

This comment has been minimized.

Show comment
Hide comment
@mattbk

mattbk May 6, 2017

Contributor

#dothingsthatdontscale 馃憤

Contributor

mattbk commented May 6, 2017

#dothingsthatdontscale 馃憤

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 7, 2017

Contributor

Last night @clone1018 and I workshopped this idea of a "Raise a round for open source" campaign. PR forthcoming with a marketing page and FAQ. Idea would be to start signing up companies here in Austin through face-to-face conversations, and then build support more broadly based on initial commitments.

Contributor

chadwhitacre commented May 7, 2017

Last night @clone1018 and I workshopped this idea of a "Raise a round for open source" campaign. PR forthcoming with a marketing page and FAQ. Idea would be to start signing up companies here in Austin through face-to-face conversations, and then build support more broadly based on initial commitments.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 16, 2017

Contributor

Okay! Back from #948. Lots of learnings! Our most important meeting was with three open-source advocates from inside Salesforce. We learned about their work, and presented #1057 to them. As @clone1018 notes at #948 (comment), they were kinda "meh" on a company-sized Kickstarter. However, when the conversation eventually came around to gratipay/gratipay.com#1153, the response was much stronger: "That's a fuckin' cool idea!" 馃拑

Looking back over gratipay/gratipay.com#1153, we've actually had some fairly strong demand for this idea over the years. I count +10-ish, including (now) Yahoo and Salesforce.

But to put an even finer point on it, up above under #987 (comment) (I think?) we have the idea that we need to find the problem that people are already solving in a half-baked, manual way with Excel, and build a better, more automated solution. Well, folks, we literally have John literal Resig building a literal half-baked, manual solution with鈥攍iterally鈥攁 spreadsheet.

Could it be any clearer what direction to go next?

Contributor

chadwhitacre commented May 16, 2017

Okay! Back from #948. Lots of learnings! Our most important meeting was with three open-source advocates from inside Salesforce. We learned about their work, and presented #1057 to them. As @clone1018 notes at #948 (comment), they were kinda "meh" on a company-sized Kickstarter. However, when the conversation eventually came around to gratipay/gratipay.com#1153, the response was much stronger: "That's a fuckin' cool idea!" 馃拑

Looking back over gratipay/gratipay.com#1153, we've actually had some fairly strong demand for this idea over the years. I count +10-ish, including (now) Yahoo and Salesforce.

But to put an even finer point on it, up above under #987 (comment) (I think?) we have the idea that we need to find the problem that people are already solving in a half-baked, manual way with Excel, and build a better, more automated solution. Well, folks, we literally have John literal Resig building a literal half-baked, manual solution with鈥攍iterally鈥攁 spreadsheet.

Could it be any clearer what direction to go next?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 16, 2017

Contributor

My goals between now and Sustain (#920) are to:

  • land #72 so that we can unequivocally say, "We are a worker-owned coop,"
  • apply to Indie.vc (#1034) so that we can keep up our momentum,
  • figure out how to wrap up the Give to package.json project, and
  • kick off a new project around Khan-style splitting.

I'm not sure how much actual development I'm going to get done in the near future, especially compared to the past six months. With @rohitpaulk back online and potentially @clone1018 and others as well, I think it's time to see about bringing in some capital so we can start functioning more as a team again. Thoughts?

Contributor

chadwhitacre commented May 16, 2017

My goals between now and Sustain (#920) are to:

  • land #72 so that we can unequivocally say, "We are a worker-owned coop,"
  • apply to Indie.vc (#1034) so that we can keep up our momentum,
  • figure out how to wrap up the Give to package.json project, and
  • kick off a new project around Khan-style splitting.

I'm not sure how much actual development I'm going to get done in the near future, especially compared to the past six months. With @rohitpaulk back online and potentially @clone1018 and others as well, I think it's time to see about bringing in some capital so we can start functioning more as a team again. Thoughts?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 17, 2017

Contributor

Fairly deep discussion in slack about the value of open source perks relative to recognizing companies.

Contributor

chadwhitacre commented May 17, 2017

Fairly deep discussion in slack about the value of open source perks relative to recognizing companies.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
Contributor

chadwhitacre commented May 17, 2017

I've moved the remaining issues from the "Refocus on Corporate Sponsorship of Open Source" milestone to the project board for this epic and have closed the milestone.

gratipay/gratipay.com#2695
gratipay/gratipay.com#1513
gratipay/gratipay.com#1199
gratipay/gratipay.com#1153
gratipay/gratipay.com#1149
gratipay/gratipay.com#1052
gratipay/gratipay.com#894
gratipay/gratipay.com#236
gratipay/gratipay.com#5

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 29, 2017

Contributor

Feedback from Yahoo (I've posted bits around but not finding that I've posted the whole thing yet):

Thinking about it purely from the perspective of the corporation who seeks to help open source projects, I think of a few needs.

  1. We seek a way to know when we are taking a risk by relying upon a project that is at risk of being abandoned. The risk is some measure that takes into account -- how much we rely upon it, how fragile or needy it is, how complex or impossible to assume maintenance on our own if we needed to, how much more funding is needed, etc. Given the plethora of open source project we use, we could use some objective way to ensure we support the ones that we need to support the most (based on our expected value for doing so).
  2. We seek to measure the impact of our support. This helps us report back to the people with budget and show how their investment in support is paying off. It's one thing to give a developer $5K, it's another to show the impact metric resulting from it. This part is tricky since we're not looking to hire open source projects to do "work for hire" or fix specific bugs. Rather, think of how we invest in non-profits in the charity space -- we ask to measure impact to see things like "how many clients served" or "given this funding level, we can complete project X."
  3. We seek to celebrate the donors in a branded way (either we grant money to our employees who select projects, or we solicit ideas from them and grant for them, something like that). So we'd want to co-brand and say something that acknowledges both [an individual developer] and Yahoo for [their] sponsorship of this very important Node.JS module.
  4. In terms of the payment execution itself, it depends on the amounts we're talking about. Turns out its often easier for us to make one large payment than to make multiple smaller ones. The reason: we have to submit expense reports and approval forms for expenses. I'd rather do it once and have an allocation account than have to issue multiple transactions that I'd have to expense and get approved.

One of the things that I've always been interested in is not just " gives $x to project", but also the flip side of that too. I would like a way for " to give $x developer, for their contributions to project".

Not just giving back to the projects that we use, but to the developers that donate their time to our open source projects.

Contributor

chadwhitacre commented May 29, 2017

Feedback from Yahoo (I've posted bits around but not finding that I've posted the whole thing yet):

Thinking about it purely from the perspective of the corporation who seeks to help open source projects, I think of a few needs.

  1. We seek a way to know when we are taking a risk by relying upon a project that is at risk of being abandoned. The risk is some measure that takes into account -- how much we rely upon it, how fragile or needy it is, how complex or impossible to assume maintenance on our own if we needed to, how much more funding is needed, etc. Given the plethora of open source project we use, we could use some objective way to ensure we support the ones that we need to support the most (based on our expected value for doing so).
  2. We seek to measure the impact of our support. This helps us report back to the people with budget and show how their investment in support is paying off. It's one thing to give a developer $5K, it's another to show the impact metric resulting from it. This part is tricky since we're not looking to hire open source projects to do "work for hire" or fix specific bugs. Rather, think of how we invest in non-profits in the charity space -- we ask to measure impact to see things like "how many clients served" or "given this funding level, we can complete project X."
  3. We seek to celebrate the donors in a branded way (either we grant money to our employees who select projects, or we solicit ideas from them and grant for them, something like that). So we'd want to co-brand and say something that acknowledges both [an individual developer] and Yahoo for [their] sponsorship of this very important Node.JS module.
  4. In terms of the payment execution itself, it depends on the amounts we're talking about. Turns out its often easier for us to make one large payment than to make multiple smaller ones. The reason: we have to submit expense reports and approval forms for expenses. I'd rather do it once and have an allocation account than have to issue multiple transactions that I'd have to expense and get approved.

One of the things that I've always been interested in is not just " gives $x to project", but also the flip side of that too. I would like a way for " to give $x developer, for their contributions to project".

Not just giving back to the projects that we use, but to the developers that donate their time to our open source projects.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 7, 2017

Contributor

My goals between now and Sustain (#920) are to:

  • land #72 so that we can unequivocally say, "We are a worker-owned coop,"

Still hoping to land this.

  • apply to Indie.vc (#1034) so that we can keep up our momentum,

Applied. Rejected.

I don't see us wrapping this up before Sustain.

I have as background a meeting that COS was involved with last year that was parallel to Sustain for us: a meeting of various stakeholders and solution-providing institutions to noodle on a shared problem. COS stole the show by rushing to market with a real, live solution to the problem that was far advanced compared to anything anyone else brought to the table.

I don't see us doing that. For one I don't think the market's desired solution is focused enough in our case. For two we have limited bandwidth to get product shipped between now and the 19th.

I think at the very least though we can demo something interesting if we can land minimal package.json discovery. That should actually be pretty straightforward, and together with bulk claiming will be at least a bit of an interesting move beyond the status quo.

We could call Give to package.json done at that point, but looking at all of the bugs and finishing touches ready for take-off on the project board鈥15 currently鈥攎akes me think we shouldn't. Let's revisit post-#920.

@rohitpaulk and I have been having some interesting discussion around this idea, which has evolved into an "open source perks program." Too early to say that we've kicked it off as a project, though.


We are now 12 days out from Sustain. My hope is that we can:

before then, with bonus points for:

Contributor

chadwhitacre commented Jun 7, 2017

My goals between now and Sustain (#920) are to:

  • land #72 so that we can unequivocally say, "We are a worker-owned coop,"

Still hoping to land this.

  • apply to Indie.vc (#1034) so that we can keep up our momentum,

Applied. Rejected.

I don't see us wrapping this up before Sustain.

I have as background a meeting that COS was involved with last year that was parallel to Sustain for us: a meeting of various stakeholders and solution-providing institutions to noodle on a shared problem. COS stole the show by rushing to market with a real, live solution to the problem that was far advanced compared to anything anyone else brought to the table.

I don't see us doing that. For one I don't think the market's desired solution is focused enough in our case. For two we have limited bandwidth to get product shipped between now and the 19th.

I think at the very least though we can demo something interesting if we can land minimal package.json discovery. That should actually be pretty straightforward, and together with bulk claiming will be at least a bit of an interesting move beyond the status quo.

We could call Give to package.json done at that point, but looking at all of the bugs and finishing touches ready for take-off on the project board鈥15 currently鈥攎akes me think we shouldn't. Let's revisit post-#920.

@rohitpaulk and I have been having some interesting discussion around this idea, which has evolved into an "open source perks program." Too early to say that we've kicked it off as a project, though.


We are now 12 days out from Sustain. My hope is that we can:

before then, with bonus points for:

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 15, 2017

Contributor

From @Jaimeyann in slack:

Hi @whit537, quick heads up. Chatted with the french director of one percent for the planet.

Some things I gleaned were:

  • They only make money from their donors memberships to the foundation, and from selling the donors right to use the 1% logo on their website. Apparently people pay for it because it increases their credibility and reputation
  • Money goes directly from the donor to the organisation they want to fund, so 1% for the planet doesn't handle any exchange of money.
  • 1% for the planet spends has operational and salary costs of around 4% of the total donations (so 4% of the 1% if you will).
  • Marketing amounts to around 15% of their costs
  • They've never gotten any public companies to commit, except for public companies who made their commitment to donate when they were private.
  • Their main contributors are family and private companies. These are the easiest to convince the main decision takers apparently. Which makes perfect sense.
  • Their main marketing channels are word of mouth (70%) and other events or direct outreach (30%)

So it seems to confirm that we should first focus on the going after small-ish businesses first and not lose much time with big business, even though they are those who should give more...

Contributor

chadwhitacre commented Jun 15, 2017

From @Jaimeyann in slack:

Hi @whit537, quick heads up. Chatted with the french director of one percent for the planet.

Some things I gleaned were:

  • They only make money from their donors memberships to the foundation, and from selling the donors right to use the 1% logo on their website. Apparently people pay for it because it increases their credibility and reputation
  • Money goes directly from the donor to the organisation they want to fund, so 1% for the planet doesn't handle any exchange of money.
  • 1% for the planet spends has operational and salary costs of around 4% of the total donations (so 4% of the 1% if you will).
  • Marketing amounts to around 15% of their costs
  • They've never gotten any public companies to commit, except for public companies who made their commitment to donate when they were private.
  • Their main contributors are family and private companies. These are the easiest to convince the main decision takers apparently. Which makes perfect sense.
  • Their main marketing channels are word of mouth (70%) and other events or direct outreach (30%)

So it seems to confirm that we should first focus on the going after small-ish businesses first and not lose much time with big business, even though they are those who should give more...

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 17, 2017

Contributor

Mini-rant from slack:

Gosh I am excited about gratipay/gratipay.com#1153.
That鈥檚 鈥渙pen source perks program.鈥
Think about $100 per month per developer.
100 developers.
1,000 developers.
10,000 developers.
100,000 developers.
That鈥檚 $10,000 per month.
$100,000/mo.
$1,000,000/mo.
$10,000,000/mo.
That鈥檚 how we price it and pitch it.
I don鈥檛 think the size of the company matters.
I think we go for all of them.
Large and small.
Ideally accounts are portable 鈥 when a dev switches companies they keep their same Gratipay account and history.
Can we get a pilot project under our belt before it鈥檚 time to apply for YC again in the fall?
Can we reach 100 devs participating before then?

Contributor

chadwhitacre commented Jun 17, 2017

Mini-rant from slack:

Gosh I am excited about gratipay/gratipay.com#1153.
That鈥檚 鈥渙pen source perks program.鈥
Think about $100 per month per developer.
100 developers.
1,000 developers.
10,000 developers.
100,000 developers.
That鈥檚 $10,000 per month.
$100,000/mo.
$1,000,000/mo.
$10,000,000/mo.
That鈥檚 how we price it and pitch it.
I don鈥檛 think the size of the company matters.
I think we go for all of them.
Large and small.
Ideally accounts are portable 鈥 when a dev switches companies they keep their same Gratipay account and history.
Can we get a pilot project under our belt before it鈥檚 time to apply for YC again in the fall?
Can we reach 100 devs participating before then?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 17, 2017

Contributor

We are now 12 days out from Sustain.

We did it! We rolled out bulk claiming and package.json discovery, and brought on @clone1018 as a second owner under a cooperative operating agreement!

!m * 馃摝 馃捀 馃拑 馃尰

So awesome! 馃槏 鈽猴笍

I leave for Sustain (#920) tomorrow, and then when I get back after a few days, our family is planning to head out for a six-week road trip. I hope to be online during much of that, but my productivity will be lower. I will try to keep up with notifications, basic maintenance and PR review. If I'm lucky I'll be able to knock out a few npm-related bugs. But in general I'm keeping my expectations low for what I will be able to accomplish between now and September.

At this point, my hope for the fall is to:

  1. finish the rest of the npm-related cleanup,
  2. clean up exchanges and finally get our accounting system on track, and
  3. launch an open source perks offering.
Contributor

chadwhitacre commented Jun 17, 2017

We are now 12 days out from Sustain.

We did it! We rolled out bulk claiming and package.json discovery, and brought on @clone1018 as a second owner under a cooperative operating agreement!

!m * 馃摝 馃捀 馃拑 馃尰

So awesome! 馃槏 鈽猴笍

I leave for Sustain (#920) tomorrow, and then when I get back after a few days, our family is planning to head out for a six-week road trip. I hope to be online during much of that, but my productivity will be lower. I will try to keep up with notifications, basic maintenance and PR review. If I'm lucky I'll be able to knock out a few npm-related bugs. But in general I'm keeping my expectations low for what I will be able to accomplish between now and September.

At this point, my hope for the fall is to:

  1. finish the rest of the npm-related cleanup,
  2. clean up exchanges and finally get our accounting system on track, and
  3. launch an open source perks offering.
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 26, 2017

Contributor

Had a strategy session w/ @nobodxbodon last week the day after Sustain. We met at Coupa鈥攕ame place as seven months ago. :o)

Caught up on the past six months and talked about priorities. What we converged on is as follows:

  • Day 0 is when we complete the full "Give to package.json" loop for the first time.
    • corporate giver discovers packages via package.json
    • sets up payment to packages*
    • package owners are notified
    • package owners accept or reject (lock) the payment
  • Until Day 0, our top priority is to get to Day 0.
    • Build out the product!
    • Warm up some companies to be our first customers.
      • Go through a sales exercise with smaller tech companies to complement the sales exercise we did with large companies.
      • Notify large company contacts when we hit Day 0 but don't count on interest--our product for them is Open Source Perks, and this is just a step on the way.
    • Do not pay down tech debt yet.

* Our current payment flow is idiosyncratic and therefore frictive. dmk246 suggests making it more like a normal "shopping cart" checkout flow, which would be awesome but should maybe (probably) wait until after Day 0 ... except that one-time payments might be on the critical path for this to reduce friction for company givers.

This represents some significant shifts to our current flow that will take some significant effort to accomplish. Risk factor: this could spiral out of control into a full redesign.

Contributor

chadwhitacre commented Jun 26, 2017

Had a strategy session w/ @nobodxbodon last week the day after Sustain. We met at Coupa鈥攕ame place as seven months ago. :o)

Caught up on the past six months and talked about priorities. What we converged on is as follows:

  • Day 0 is when we complete the full "Give to package.json" loop for the first time.
    • corporate giver discovers packages via package.json
    • sets up payment to packages*
    • package owners are notified
    • package owners accept or reject (lock) the payment
  • Until Day 0, our top priority is to get to Day 0.
    • Build out the product!
    • Warm up some companies to be our first customers.
      • Go through a sales exercise with smaller tech companies to complement the sales exercise we did with large companies.
      • Notify large company contacts when we hit Day 0 but don't count on interest--our product for them is Open Source Perks, and this is just a step on the way.
    • Do not pay down tech debt yet.

* Our current payment flow is idiosyncratic and therefore frictive. dmk246 suggests making it more like a normal "shopping cart" checkout flow, which would be awesome but should maybe (probably) wait until after Day 0 ... except that one-time payments might be on the critical path for this to reduce friction for company givers.

This represents some significant shifts to our current flow that will take some significant effort to accomplish. Risk factor: this could spiral out of control into a full redesign.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 26, 2017

Contributor

In other words, confirmation of the basic "hope for the fall" plan but with a bit more urgency and consequent cutting of corners on tech debt, prioritization of shipping features.

Contributor

chadwhitacre commented Jun 26, 2017

In other words, confirmation of the basic "hope for the fall" plan but with a bit more urgency and consequent cutting of corners on tech debt, prioritization of shipping features.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Aug 10, 2017

Contributor

Back from summer road trip. Time to dial the plan way back. We're not going to reach perks this year. How far can we get package.json before YC applications (#1139) in less than two months?

Contributor

chadwhitacre commented Aug 10, 2017

Back from summer road trip. Time to dial the plan way back. We're not going to reach perks this year. How far can we get package.json before YC applications (#1139) in less than two months?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Aug 10, 2017

Contributor

Next Two Months

Su Mo Tu We Th Fr Sa
August      馃拑 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16  OSSummit
17 18 19 20 21 22 23
24 25 26 27 28 29 30
 1  2  3  4  5  6  7  YC/apply
Contributor

chadwhitacre commented Aug 10, 2017

Next Two Months

Su Mo Tu We Th Fr Sa
August      馃拑 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16  OSSummit
17 18 19 20 21 22 23
24 25 26 27 28 29 30
 1  2  3  4  5  6  7  YC/apply
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Aug 10, 2017

Contributor

I spent some time over the past few days revising our big picture docs (#1132). I think this epic should remain our priority. In fact, my main proposal over there is to prioritize this epic even more by shifting our primary customer focus away from open source maintainers (receivers) and onto tech company open source program managers (givers). I also put some numbers together around the size of the problem and what it will take to make a dent:

Open source clearly suffers from free-rider abuse. It creates between $100B and $1T/yr in value, and captures at most 0.2% of that value. Gratipay's strategic plan is to solve the free-rider problem in open source by persuading companies to pay for open source software. There are 20M programmers in the world. If 10% of them had an annual budget of $1,000 to pay for open source, the distributed open source community would have revenues equivalent to Red Hat.

That's our initial target: $2B/yr revenue for the open source community, an order of magnitude change from the status quo.

Here's our current definition of done in the description for this ticket:

The definition of "done" is at least two dozen companies supporting open source with at least $14,000/wk鈥攊n other words, getting back to where we were at Peak Gittipay. Today we are at zero companies giving, and $800/wk.

screen shot 2017-01-16 at 5 05 16 pm

I guess we ought to revise that. :o)

Contributor

chadwhitacre commented Aug 10, 2017

I spent some time over the past few days revising our big picture docs (#1132). I think this epic should remain our priority. In fact, my main proposal over there is to prioritize this epic even more by shifting our primary customer focus away from open source maintainers (receivers) and onto tech company open source program managers (givers). I also put some numbers together around the size of the problem and what it will take to make a dent:

Open source clearly suffers from free-rider abuse. It creates between $100B and $1T/yr in value, and captures at most 0.2% of that value. Gratipay's strategic plan is to solve the free-rider problem in open source by persuading companies to pay for open source software. There are 20M programmers in the world. If 10% of them had an annual budget of $1,000 to pay for open source, the distributed open source community would have revenues equivalent to Red Hat.

That's our initial target: $2B/yr revenue for the open source community, an order of magnitude change from the status quo.

Here's our current definition of done in the description for this ticket:

The definition of "done" is at least two dozen companies supporting open source with at least $14,000/wk鈥攊n other words, getting back to where we were at Peak Gittipay. Today we are at zero companies giving, and $800/wk.

screen shot 2017-01-16 at 5 05 16 pm

I guess we ought to revise that. :o)

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Aug 10, 2017

Contributor

Revised!

Contributor

chadwhitacre commented Aug 10, 2017

Revised!

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Aug 10, 2017

Contributor

How far can we get package.json before YC applications (#1139) in less than two months?

Answer: not very far. With only six work weeks, we'll be lucky to get a few more bugs fixed between now and then. 馃惌

Contributor

chadwhitacre commented Aug 10, 2017

How far can we get package.json before YC applications (#1139) in less than two months?

Answer: not very far. With only six work weeks, we'll be lucky to get a few more bugs fixed between now and then. 馃惌

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
Contributor

chadwhitacre commented Aug 10, 2017

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Aug 10, 2017

Contributor

Yeah no. We're not getting anything else major shipped in six weeks. Okay! Six months, maybe ...

Contributor

chadwhitacre commented Aug 10, 2017

Yeah no. We're not getting anything else major shipped in six weeks. Okay! Six months, maybe ...

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Sep 27, 2017

Contributor

Alright, did some serious cleanup of the project board. I made a new project for Relaunch: #BackTheStack and moved most tickets there. I moved some tickets off a project entirely. The ones remaining in take-off on the board for the "Make it easier" project are big-picture product ideas.

Contributor

chadwhitacre commented Sep 27, 2017

Alright, did some serious cleanup of the project board. I made a new project for Relaunch: #BackTheStack and moved most tickets there. I moved some tickets off a project entirely. The ones remaining in take-off on the board for the "Make it easier" project are big-picture product ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment