Closed chadwhitacre closed 6 years ago
!m @mattbk @nobodxbodon @andrew ❤️
Okay! I've revisited https://github.com/gratipay/inside.gratipay.com/issues/637#issuecomment-236044779, in particular:
we need to make it really really easy for them to write a sentence of the form "This award will be used to __."
... and I've rewritten our grant application to focus on concrete outcomes. 👍
@andrew I've copy/pasted your comments from https://github.com/gratipay/inside.gratipay.com/issues/637#issuecomment-262232768 to the "Please share an endorsement from your endorser" section. Good for a first cut, I think. 👍 Does it work for you to further edit that section directly on the pad?
I feel much better about this version of the application. I think it gives MOSS something positive and concrete to say "Yes!" to. How is it looking to the rest of yinz?
Gratipay: $250,000. Gratipay is a website that helps companies pay the open source projects they depend on. This award will be used to redesign the site, integrate package managers, and improve operations.
Due in four days!
:) Looks good!
That's why we're approaching the Mozilla Foundation instead of pursuing venture capital
That isn't entirely true (https://github.com/gratipay/inside.gratipay.com/issues/68)
That's why we're approaching the Mozilla Foundation instead of pursuing venture capital
That isn't entirely true (#68)
Yeah, my thinking at this point is that if/when we land our first non-profit grant, then we will convert to a non-profit (#916) and close the door on venture capital. Do we need to change what we say in the application here?
@timothyfcook and I are workshopping the application.
Initial advice from @timothyfcook (who has a fair bit of experience with grantwriting via @saxifrage):
A year or two ago I referred a fairly straightforward website project that ended up costing $65,000.
Another data point is Zeldman's slider, which defaults to $100,000 on the low end, and bottoms out at $45,000.
I think of http://metalab.co/ as the top of the top shelf. They made Slack. If we email them with a budget of $95,000, they will ignore us.
Alright, whittled down to $185,000:
$95,000 will be used to hire a design firm to refresh the visual design and user experience of Gratipay. Design quality is the number one factor in website credibility, but open source has historically had a reputation for bad design. We're stuck in that rut, and we want to get out of it!
$60,000 will be distributed to Gratipay collaborators to integrate package managers into Gratipay. Today's open source funding options are geared towards isolated projects. In production, however, companies depend on a long tail of hundreds of open source packages. We want to use package managers to make it easy for companies to see and fund exactly the open source software they depend on.
$15,000 will be used for operations (customer support, issue tracker maintainance, legal, accounting, etc.).
$15,000 will be donated from Mozilla through Gratipay to other open source projects that are meaningful to Mozilla. Gratipay is a friend of MOSS. Let's #fundopensource together!
The $60,000 is for us, team (plus whatever of the $15,000 for operations we don't spend on lawyers and CPAs). I'm thinking of this as being for the year, for 2017. I think we want to come in solidly under $200,000, because the largest previous gift was $150,000 for Tor. I think if we start to push $200,000 then it will get increasingly harder to say "yes" to us. I also rewrote to work in multiples of 5 instead of 3 (95,000 instead of 96,000, etc.) based on the numbers I am seeing from round 1.
Alright, done drafting for now.
I think the last major piece here is the endorsement.
@andrew Does it still look like you'll be able to help us out with that? What do you need from me/us? We've recently set up Slack, so if it's easier feel free to drop in there to chat (I've sent you an invite). 🙇
You put a heavy price on design @whit537
@clone1018 in slack
$95,000 will be used to hire a design firm to refresh the visual design and user experience of Gratipay. Design quality is the number one factor in website credibility, but open source has historically had a reputation for bad design. We're stuck in that rut, and we want to get out of it!
I'm a bit concerned about putting more than half of the fund to UX design. I can't agree more that appeal is indeed very critical, but it sounds like trying our luck with too much to put down. Besides, is there any timeline about this?
$60,000 will be distributed to Gratipay collaborators to integrate package managers into Gratipay. Today's open source funding options are geared towards isolated projects. In production, however, companies depend on a long tail of hundreds of open source packages. We want to use package managers to make it easy for companies to see and fund exactly the open source software they depend on.
Do you mean npm only, or other package managers as well? If latter, maybe better to make it clear?
I'm a bit concerned about putting more than half of the fund to UX design. I can't agree more about appeal is indeed very critical, but it sounds like trying our luck with too much to put down.
Say more? What do you see as the risks? I think we risk more by budgeting too little, in which case we'll only be able to afford a third-rate firm, and we won't get a quality outcome.
Besides, is there any timeline about this?
I have in mind six months to a year.
Do you mean npm only, or other package managers as well? If latter, maybe better to make it clear?
The plan is to start with npm, get it working there, and then work with Libraries.io on integrating the rest of the package managers based on our experience with what we needed for npm. It's hard to say how far $60,000 will get us down that path. Do you think as it's written it is specific to npm?
A little more discussion here: http://gratipay.slackarchive.io/gratipay/-/1480095149.000138/1480368037.00024/1480367790000230/ (scroll up)
What do you see as the risks? I think we risk more by budgeting too little, in which case we'll only be able to afford a third-rate firm, and we won't get a quality outcome.
I agree in general that you get what you pay for. It's mostly about the way we put in the application, I suppose. With "to hire a design firm to" it sounds like a decision without due research or evaluation. Maybe it's better to have some references?
I have in mind six months to a year.
Shall we put in application to make the plan more concrete?
Do you think as it's written it is specific to npm?
Actually, I would have not fully understood the term "package manager" here if I hadn't known the plan beforehand, so I suppose the reviewer of the application may feel the same. So maybe it's better to illustrate a little more?
So maybe it's better to illustrate a little more?
I'm getting some private rumblings from a lurker that more specificity is indeed called for. Hopefully detail is forthcoming ... ? ;-)
As @whit537 requested it here, I noted that for another applicants MOSS approval that I worked with, when they requested money to implement a feature, MOSS wanted a fairly detailed set of answers to questions like:
(Note: They weren't looking for super detailed responses, but just a general overview to get a feel for how the money was going to be allocated)
If 'package managers' is not a very well defined thing, with a time-line, they'd likely either reject it or come back to you requiring more details. This is part of why I'm asking so many questions about the package manager thing, because the scope of work changes radically depending on the answers, and they've asked in the past for a defined feature set to justify how much money is needed to implement it.
That was for a Foundational Technology MOSS grant though, not a Mission Partners one. Though I would still expect them to want a broad overview along those lines to gauge whether the grant was delivered on or not. It's entirely possible that a similar breakdown will be desired regarding the website redesign, or at least whether this quote is just made-up or was actually quoted by a design firm for a specified scope of work.
Thanks, @bbangert. :-)
So we just need a plan. It will be a roadmap for Gratipay and information for potential funding sources.
Right?
So we just need a plan.
Alright, so let's delegate. Who is going to work on which part of the plan? Are we agreed on the overall structure of the grant? Namely ...
"Grant folks will tell you what details they want. And if they don't ask for them, that means they don't have the time to read about them and they don't think they're that important." —@timothyfcook
I'm going to compare the Mission Partners and Foundational Tech applications ...
Same:
FT:
What are the concrete, specific outputs and outcomes this grant would produce? * Please describe what you would use the funds for - what you are going to build, hack or fix, and how that would be of benefit to the world. (Max 8k chars)
MP:
What are the concrete, specific outputs and outcomes this grant would produce, and how do those activities further the Mozilla Mission? * Please describe what you would use the funds for - what you are going to build, hack or fix. Also, explains how it furthers our mission, perhaps tying your activities to items in the Manifesto - https://www.mozilla.org/about/manifesto/. (Max 8k chars)
Alright, so I take it that @bbangert is a "grant folk" for our purposes here, and he has told us what "they" want. :-)
Questions therefore stand:
@whit537 I think there may be some conflict of interest with me endorsing the grant was well as providing part of the tooling to support the "package manager" feature, as we're also planning on applying for MOSS funding at some point I wouldn't want to jeopardize that
there may be some conflict of interest with me endorsing the grant was well as providing part of the tooling to support the "package manager" feature
Ah, well. I wondered about that. Okay! Thanks anyway, @andrew. :-) Feel free to unsubscribe to avoid further notifications from this ticket, I imagine we're going to be generating quite a few over the coming days. See you around! :-)
... aaaaaaaaaaaaaaand we're back to no endorser. :o)
@bbangert Think there's a chance we can converge on a scope of work for the package manager integration that you'd feel good about endorsing? :)
Let's dig into that for a minute ...
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:
/on/github/bbangert/
, /on/twitter/oprah/
, etc.Basically I think we need to reimplement that, but for projects instead of individuals.
/on/npm/express/
, /on/pypi/requests/
, etc. (https://github.com/gratipay/gratipay.com/issues/4148)I do think there's a role for package manager integration (more on that at https://github.com/gratipay/gratipay.com/pull/4135#issuecomment-263393515), but the bigger picture is bigger. How do we break that down into a grant application?
@whit537 I'm a bit skeptical in general about funding a platform for funding OSS developers vs. funding OSS dev's for work directly on a specific project, mainly for the reasons that follow.
I read articles like this (http://www.infoworld.com/article/3144546/security/time-is-running-out-for-ntp.html) and I'll admit they reinforce my thinking that the entire concept of funding OSS via donations is totally broken. Maybe companies will donate to trendy tech they use, but then they skimp on core tech that everyone requires (in this case NTP, but see-also OpenSSL)? How is this good for the Internet or OSS as a whole?
Perhaps its the car broken on the side of the freeway problem. The one where a car broken down on the side of a heavily-trafficked freeway can have a greater delay in having a motorist stop to help than on a very rarely-traveled road.... because on the heavy-traffic route everyone assumes someone else will stop to help out while on the rarely-traveled road the passing motorists believes (rightfully so) that it's critical they stop.
Are the OpenSSL and NTP projects on Gratipay? Does it seem likely that if a company submits their package manifesto it will include such core, critical, and under-funded things such as these? Or will they just assume someone else is dealing with that and throw money at the latest fad OSS library instead of the old, boring, and legacy thing everyone actually is using?
How does Gratipay help provide feedback to companies about what projects are over or under-funded, and whether the resources are actually urgently needed? Could Gratiay provide a way for a project to indicate whether developers are willing or not to work full-time on security or bug fixes such that funding it would result in substantially better results than a OSS lib where the dev is going to treat it as merely some extra dough?
I mean, I think it's very useful to be honest in this discussion. In that, I am grateful that @whit537 has been exceptionally transparent in his handling of all of this. I'd love to see such honesty from projects requesting money on whether any of them would actually quit a day-job to survive purely on donations (I can imagine how tough such a choice would be).
So.... to stop my rant here.. what would I feel good about endorsing? I think the package manager concept has some good foundational underpinnings, but if someone is ready to commit money to OSS, is there an opportunity to do better? Do they use NTP/OpenSSL or some other severely under-funded OSS project that is critical to the Internet that they just didn't know needed a bit more money? Maybe right then might be a good time to mention how important it is that some of their donation be directed there?
If this feature was about surfacing OSS projects that are critical to wide swaths of the Internet that apparently go under-funded until an article like that appears (I sincerely hope an article like that results in some funding, but maybe heavy-freeway syndrome will hit again)... I'd be behind it in a second. :)
Let's take the NTP example. How could such a gratipay page for this project be setup? I would expect to see whether or not the funds go to developers attempting to make this a full-time job vs. those just appreciating some extra money. It'd be even better for a project like this to see how they figure more funds might increase response-time to handle critical security bugs. Maybe the project could indicate if its a core-req for the majority of linux distros (how many other core libs/daemons need funding besides NTP/OpenSSL?).
Can projects set a spending-goal such that companies/people donating know they can stop when its been accomplished? Or maybe they can see that they've ensured the project is financially sound for the next N years with M developers fully funded? I have yet to see any way to do such a thing.
Handling any/most of these concerns of mine would make me feel quite good about endorsing this.
If this feature was about surfacing OSS projects that are critical to wide swaths of the Internet that apparently go under-funded until an article like that appears (I sincerely hope an article like that results in some funding, but maybe heavy-freeway syndrome will hit again)... I'd be behind it in a second. :)
@bbangert we'll have to get you to endorse the https://libraries.io grant next year 😉
Maybe the project could indicate if its a core-req for the majority of linux distros (how many other core libs/daemons need funding besides NTP/OpenSSL?).
@bbangert Great point. This may need a huge dependency graph of all the projects/libraries, with the information about the organizations owning those. I imagine that will require big effort, like @whit537 mentioned above ("the bigger picture is bigger"), and can only be achieved incrementally. Current effort of integrating npm package manager could be the first step.
Can projects set a spending-goal such that companies/people donating know they can stop when its been accomplished?
Sounds like kickstarter. Not sure if it can be accomplished with the grant, along with other critical features.
Hey
I’ve been lurking too.
I would just like to say that I agree with much of what Ben says here. When posed with the hypothetical question ‘how much of my money do you want in order to “save” FOSS?’ the answer is pretty much always ‘all of it’ which is why we (by which I mean Libraries.io http://libraries.io/, the Core Infrastructure team, the Linux Foundation etc) are trying to tackle this problem by prioritising.
But I do think that there is a way to harness the ‘next fad’ syndrome in OSS: by funding the complete ‘toolchain’ for that new thing roughly inversely proportionate to the value it inherits from its stack. This will over time result in well funded core FOSS and yet sustain that new thing at a rate that enables it to flourish.
rant/
I think the core principle of funding the total ecosystem for a given application, framework or library is sound and that these kinds of initiatives will help provide a more sustainable ecosystem for FOSS in general. At the same time I think that it’s necessary for everyone to work together in this space, regardless of financial, organisational or legal structure.
Divisive politics is getting us nowhere at the moment… how about we don’t replicate that here?
/rant
@bbangert et al.—Awesome discussion. 👍
What about a 5% "tax" that goes to core tech? Currently the full face value of a payment goes to the recipient. So if I give $100 to Hip Project, they get all $100. If we implement a tax, Hip would get $95, and $5 would go to core tech.
We'd have a board to decide what receivers qualify as "core tech" (Core Infrastructure Initiative, Internet Bug Bounty, etc.) and how that budget gets split. P.S. I think Gratipay should qualify, since we don't have a hard fee for ourselves otherwise.
To avoid some of the loss of agency involved in a tax, we could grant givers control over their allocation if they want it. In other words, payments directly to qualifying core tech projects would offset one's tax burden.
P.S. I would also want a 5% tax for demographic diversity programs with a board of its own.
Perhaps its the car broken on the side of the freeway problem. The one where a car broken down on the side of a heavily-trafficked freeway can have a greater delay in having a motorist stop to help than on a very rarely-traveled road.... because on the heavy-traffic route everyone assumes someone else will stop to help out while on the rarely-traveled road the passing motorists believes (rightfully so) that it's critical they stop.
The technical term for this is the bystander effect (sorry, married to a psychology professor).
The technical term for this is the bystander effect
Let's try to be aware of and work to resist it! ;-)
Can projects set a spending-goal such that companies/people donating know they can stop when its been accomplished?
Before Gratipocalypse, there was a "goal" feature that would show how close a ~user was to reaching a defined weekly income. I think this would be worth resurrecting, if only to focus on the "sustainability" part--regardless of anything else, I think the goal of Gratipay is for funding to remain constant, rather than require repeated push for funds, grants, or Kickstarter-like campaigns. People (givers) like to see that they're moving the needle. Yes, they'll be giving that amount every week, but it drives home the message that the work doesn't stop just because the Indiegogo campaign is over.
Deadline is past.
Reopening for next deadline.
(per slack)
In conversation at #314, Louis-David Benyayer suggested that we seek funding from Mozilla and other large open-source foundations.
https://twitter.com/LDBenyayer/status/735556364269916162
We're writing our proposal at https://public.etherpad-mozilla.org/p/gratipay-moss-track-2-2016.
The application form is at https://docs.google.com/forms/d/1rwYQTT-9-eldS-kElY646bMwMzJpxfL8lDskX86xgCQ/viewform.