🗻 Make it easier for companies to fund open source

[chadwhitacre]

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

• Integrate npm
• Give to package.json
• Relaunch: #BackTheStack
• Takeoff on the project board

---

✈️ This is the flight deck for the Make it easier for companies to fund open source epic. ✈️

---

[chadwhitacre]

FOCUS:

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

[chadwhitacre]

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 Make it easier for companies to fund open source gratipay.com#4135.

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

[chadwhitacre]

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]

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—done!
2. mirror all npm packages on Gratipay—done!
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 Integrate npm 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]

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.

• Have pages on Gratipay representing open source packages, /on/npm/express/, /on/pypi/requests/, etc. (Integrate npm gratipay.com#4148)
• Bring back pledging (Bring back pledging gratipay.com#4195).
• Bring back widgets, and/or README integration like OC has.
• Bring back top givers (and receivers?) on the homepage (Recognize companies gratipay.com#2695).
• Bring back a charitable element (Add "percentage to charity" like Humble Bundle has gratipay.com#4209).

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]

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]

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

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

[chadwhitacre]

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]

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]

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]

Maybe. What does "stage 2" mean?

[chadwhitacre]

#964 (comment) ...

the scope is too much for stage 1

And what is stage 1? :-)

[nobodxbodon]

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

[chadwhitacre]

Ah, gotcha. :-)

[chadwhitacre]

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]

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]

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

[chadwhitacre]

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]

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]

#dothingsthatdontscale 👍

[chadwhitacre]

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]

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—literally—a spreadsheet.

Could it be any clearer what direction to go next?

[chadwhitacre]

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

• land adopt a cooperative operating agreement #72 so that we can unequivocally say, "We are a worker-owned coop,"
• apply to Indie.vc (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]

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

[chadwhitacre]

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]

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]

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

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

Still hoping to land this.

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

Applied. Rejected.

• figure out how to wrap up the Give to package.json project, and

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—makes me think we shouldn't. Let's revisit post-#920.

• kick off a new project around Khan-style splitting.

@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:

• deploy bulk claiming,
• deploy package.json discovery, and
• bring @clone1018 on as a second owner (bring on a second owner #196) under adopt a cooperative operating agreement #72

before then, with bonus points for:

• any other bugfixes,
• progress on cleaning up exchanges, and/or
• publicizing giving to package.json (Introduce aggregation story w/ npm announcement(s) #1045).

[chadwhitacre]

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]

Mini-rant from slack:

Gosh I am excited about gratipay/gratipay.com#1153.
That’s “open source perks program.”
Think about $100 per month per developer.
100 developers.
1,000 developers.
10,000 developers.
100,000 developers.
That’s $10,000 per month.
$100,000/mo.
$1,000,000/mo.
$10,000,000/mo.
That’s how we price it and pitch it.
I don’t 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’s time to apply for YC again in the fall?
Can we reach 100 devs participating before then?

[chadwhitacre]

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]

Had a strategy session w/ @nobodxbodon last week the day after Sustain. We met at Coupa—same 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]

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]

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]

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]

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—in other words, getting back to where we were at Peak Gittipay. Today we are at zero companies giving, and $800/wk.

I guess we ought to revise that. :o)

[chadwhitacre]

Revised!

[chadwhitacre]

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]

Unless ... gratipay/gratipay.com#4427 (comment)

[chadwhitacre]

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

[chadwhitacre]

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.