Skip to content
This repository has been archived by the owner on Nov 16, 2022. It is now read-only.

Email maintainers about available money #969

Closed
nobodxbodon opened this issue Jan 7, 2017 · 33 comments
Closed

Email maintainers about available money #969

nobodxbodon opened this issue Jan 7, 2017 · 33 comments

Comments

@nobodxbodon
Copy link

Reticketing from #964 (comment)

Original suggestion from a potential company giver:

I'd gladly contribute to a project on Gratipay, but I'd like to contribute to a project that we actually use and benefit from at Loopify.

Specifically, here's a list of npm modules I'm grateful for:

  • async
  • babel-* (also css-loader, file-loader, saas-loader, style-loader, url-loader, etc)
  • iframe-resizer
  • mongoose
  • nodemon
  • react
  • react-helmet
  • react-modal
  • react-redux
  • react-router
  • react-router-redux
  • redux
  • redux-thunk
  • webpack

I'd suggest you hit up all these project maintainers and say "I've got a startup founder who wants to pay for your project if you sign up for Gratipay". Then let me know! :)

The channels of contacting may include email or other social accounts. The process will get direct feedback for npm integration project, and also find the proper means and words to contact project maintainers, which can be reused in future auto-notifying.

@nobodxbodon nobodxbodon changed the title reach out to the maintainers of the projects having potential sponsor reach out to the maintainers of the projects having potential giver Jan 7, 2017
@nobodxbodon
Copy link
Author

nobodxbodon commented Jan 7, 2017

Started to get contacts. Some findings:

  • webpack

They are on OC

  • async

There are 4 admin listed on npm
And of course much more contributors
I suppose we'll use the admin list, and add all their email addresses as receiver in one email?

  • babel-* (also css-loader, file-loader, saas-loader, style-loader, url-loader, etc)

Not sure if all packages with prefix babel- are included, as there are too many.

  • react

It seems a facebook project. I suppose the wording should be different from that used for individual project maintainers? It's still an issue how to automatically check whether a project is maintained by a company or individual.

  • react-redux
  • react-router

There's one admin shown in both projects. In this case he should only get one email about all the projects listed by giver that he acts as admin?

@chadwhitacre
Copy link
Contributor

Add to "Integrate npm" project?

@chadwhitacre
Copy link
Contributor

slack

@nobodxbodon
Copy link
Author

Though I get the responses from @whit537 that's referenced in above slack archive already, please allow me to make another (hopefully the last, either way :)) try to highlight the necessity in my view to reach out to the project owners.

As @arasmussen said "let me know", I believe the result (how many of the project owners are willing to accept giving from another company) would actually in turn impact how his company participates in the project. Besides, I wonder if he's aware that some projects are company project already (react by facebook, for example), which I also think would influence his decision.

Maybe I'm wrong about this, or are there some obvious answers that I don't realize?

@arasmussen
Copy link

Happy to add some context here. I've got plenty of thoughts.

  1. I don't want to pay Facebook. They've got plenty of money and open source is very well funded there. Any money I could contribute would be a rounding error. Nothing against FB, I used to work there, just don't want to give them money.

  2. We're bootstrapped and currently losing money, so it's hard for me to justify paying money to anyone right now. When/if that situation changes, I'd definitely love to contribute to any projects that helped us succeed.

  3. I don't want to distribute to all of my npm modules evenly. Some of them I don't use, some of them are built by FB, some of them are wayyyyy more useful than others, some aren't actively maintained. I want to fund the people who are doing open source work for the greater good of software and open source, who work on great projects used by influential companies, who we might lose because they need to make a living...

Some npm modules I love and would consider funding, assuming the above conditions are met (we're profitable, the project isn't already well funded): async, babel, linkifyjs, mocha, moment, nodemon, react, react-helmet, react-redux, react-router, react-router-redux, redux, redux-connect, redux-thunk, webpack.

Hope that's helpful, cheers!

@mattbk
Copy link
Contributor

mattbk commented Jan 12, 2017

So you'd rather choose a la carte rather than get a bundle based on dependencies? That seems easier to implement.

Another idea that comes from "isn't already well funded": what if you could put a ceiling on contributions? E.g., if project x already receives $1000 a week, put my money elsewhere.

@arasmussen
Copy link

So you'd rather choose a la carte rather than get a bundle based on dependencies? That seems easier to implement.

Yeah or maybe a page where I can copy + paste my package.json in and then check the boxes for the projects I'd like to contribute to.

Another idea that comes from "isn't already well funded": what if you could put a ceiling on contributions? E.g., if project x already receives $1000 a week, put my money elsewhere.

Yeah $1000 a week is solid for one person, not for a team of people. Really depends on the project. I'm less worried about this, more worried about not giving my money to Facebook or Facebook engineers who are already making six figures doing what they love. It's more about "don't fund projects well-funded by big companies".

@mattbk
Copy link
Contributor

mattbk commented Jan 12, 2017

$1000 was a random number. That's fine. I like the box-checking, but would a "fill in an amount" list work better for what you're describing? This is one of those choices we could build; divide money equally among X projects, or divide it up manually.

@nobodxbodon
Copy link
Author

I'm less worried about this, more worried about not giving my money to Facebook or Facebook engineers who are already making six figures doing what they love.

As it's critical, we'd better try to make sure of that. I don't see other ways better than reaching out to the project maintainers to check if they'd like to receive it. I suppose the professionals like full-time engineers would either reject or make that clear in response?

@nobodxbodon
Copy link
Author

And thanks @arasmussen a lot for your precious feedback!

@mattbk
Copy link
Contributor

mattbk commented Jan 13, 2017

I don't see other ways better than reaching out to the project maintainers to check if they'd like to receive it.

A key part of this infrastructure is that we're not collecting money on behalf of those projects until they sign up to receive it, only pledges. I think this is reasonable if we make it very clear which projects aren't signed up yet and give those maintainers a simple way to opt-out and be removed entirely.

@nobodxbodon
Copy link
Author

@mattbk I'm not sure I get how it's going to work:

  1. a company signs up, ready to pay for certain projects (do we ask how much in their mind, either total or for each project?)
  2. we wait(?) for the project owners to sign up, without reaching out to them proactively? <-- the problematic one
  3. after the project owner signs up, the company can give (not necessarily the amount in the beginning, as their budget can change, fewer projects to pay, etc)

@mattbk
Copy link
Contributor

mattbk commented Jan 13, 2017

I see what you're saying. 👍 I thought this was in conjunction with things like gratipay/gratipay.com#4148 and gratipay/gratipay.com#4135. That's where I was coming from pledging.

I completely agree with reaching out to potential project owners once we have an idea of who wants to give to them. Ideally, the first few companies will be a little more patient and we can run through this manually, and then more projects will join as they realize there is potential funding involved.

@chadwhitacre
Copy link
Contributor

I'm removing this from the Integrate npm project after all, after working on #987. Let's discuss where this issue fits under there.

@chadwhitacre
Copy link
Contributor

Added to a new project board for the epic.

@chadwhitacre
Copy link
Contributor

I've privately emailed someone who maintains lots of npm projects to ask for a conversation. Will report back ...

@chadwhitacre
Copy link
Contributor

I thought I dug up at some point a list of the top 10 npm maintainers by number of packages. We could reach out to more folks based on that list but I didn't want to wait for that before reaching out to this one person I know is on the list and who came to mind and seemed like a good person to reach out to based on past history.

@chadwhitacre
Copy link
Contributor

No word back yet. Moving back to take-off in light of #987 (comment).

@chadwhitacre
Copy link
Contributor

Heard back! Scheduling a call ...

@nobodxbodon
Copy link
Author

@whit537 how's the call going? Guess not done yet?

@chadwhitacre
Copy link
Contributor

Done: https://www.youtube.com/watch?v=B-kC1SEx31g.

Needs to be summarized. Up for that?

@chadwhitacre
Copy link
Contributor

On Doug's recommendation, I've emailed Jonathan Ong.

@chadwhitacre
Copy link
Contributor

The tl;dr of my call with Doug is that he thought the integration w/ npm is interesting enough that he would be willing to sign up some of his projects (express, mysql) once we are ready to go. 💃

One key insight is that on the fairness question (cf.), it might actually be better not to distribute to the full transitive dependency graph, but just to the top level. That way, that first tier holds the reigns in distributing to the next level down.

@chadwhitacre
Copy link
Contributor

Jonathan isn't interested in talking, as he's not doing as much with open source these days.

@mattbk
Copy link
Contributor

mattbk commented Feb 6, 2017

That way, that first tier holds the reigns in distributing to the next level down.

I can see that, as each successive level probably(?) knows more about its direct dependencies than the ones further down.

@nobodxbodon
Copy link
Author

That way, that first tier holds the reigns in distributing to the next level down.

I can see that, as each successive level probably(?) knows more about its direct dependencies than the ones further down.

+1 to the distribution of responsibilities. Though it reminds me of trickle-down effects, IMO it's still a proper mechanism for at least the early stage.

BTW trickle-down here may not be as serious as in the real world, as there can be lots of 'leaf' projects giving to one single 'root' project.

@chadwhitacre
Copy link
Contributor

@chadwhitacre
Copy link
Contributor

Relevant from sustainers/sustainers.github.io#56 (comment):

Not so secret list of the 1,000 most depended upon projects tracked by Libraries.io:

https://gist.github.com/andrew/872df3b78b9ec3e7dbe597fb5a202121

@chadwhitacre
Copy link
Contributor

chadwhitacre commented May 2, 2017

Dropped this down a notch in scope (~= bumped this up a notch in priority) from Epic to Project.

@chadwhitacre
Copy link
Contributor

Let's repurpose this to be about emailing maintainers when someone pledges to them.

@chadwhitacre
Copy link
Contributor

I.e., automated outreach.

@chadwhitacre chadwhitacre changed the title reach out to the maintainers of the projects having potential giver Email maintainers about pledges May 17, 2017
@mattbk mattbk mentioned this issue May 25, 2017
2 tasks
@chadwhitacre
Copy link
Contributor

chadwhitacre commented May 25, 2017

@oakes in slack:

you could do what Brave does, and send an email to project maintainers when their donations have reached a certain amount (i think Brave does it at $100)

No. 9 on https://www.brave.com/Payments_FAQ.html

@chadwhitacre chadwhitacre changed the title Email maintainers about pledges Email maintainers about available money Sep 27, 2017
@chadwhitacre
Copy link
Contributor

Repurposing slightly in light of #1160. Now this is about emailing maintainers once we decide how we're going to distribute funds raised through #BackTheStack.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants