Sponsorship platforms

[blakeembrey]

Hi all! With the number of available sponsorship platforms available lately, I'd like to let you know that if you are a maintainer - feel free to attach your name to a package! The main platforms I'd recommend from my experience are:

1. GitHub sponsors - you can add a "sponsor" badge directly to the project by altering .github/FUNDING.md (example in ts-node).
2. Tidelift - you can "lift" a package and route security reports through them. Most of the packages are this organization are available for a $25/month lifter payment.
3. Thanks.dev - I'm having more trouble splitting up the organization into multiple "owners" with this platform, but if/when that gets sorted out it could be worth considering. You should at least consider it if you maintain packages outside of this organization.

This is not a requirement, just giving a heads up and permission, in case you were unsure. I haven't been active in OSS for years now and want to ensure that if you've been maintaining something here that you have the option to be paid for your work. It's often very small, and I know from experience that getting a monetary "reward" for OSS can affect motivation, but it's worth considering and keeping in mind these are optional for both maintainers and sponsors. I wouldn't want getting paid on any of these platform as a way to increase your maintenance load. Only Tidelift comes with any obligation, and that's to triage security issues in a timely manner and back a number of major releases you are allowed to specify.

[blakeembrey]

I'm currently registered as the Tidelift POC for Typedoc. @Gerrit0 you'd be eligible for $25/month on Tidelift if you want me to ask them to switch it over to you. We'd also need to update SECURITY.md with a link to the Tidelift security contact page so they can triage the security reports.

[Gerrit0]

It's often very small, and I know from experience that getting a monetary "reward" for OSS can affect motivation

This is the main reason I've avoided sponsorships -- the reward is small enough that it's bare ly worth it, and I like having the flexibility to just take a month off without worrying about disappointing anyone who's paying, I do consider it every few months though... 🤷

[johnnyreilly]

Thanks for putting this discussion up @blakeembrey!

I've been directed to this discussion from an email between myself, @piotr-oles and @blakeembrey. Alas I receive so many emails from GitHub I frequently miss relevant information. Effective GitHub notifications remains an unsolved problem for the world 😅

---

I'm commenting as @piotr-oles, myself and @blakeembrey are all on thanks.dev, on behalf of TypeStrong.

However, given that we had nothing in place to determine a splitting mechanism, whoever logged in first after a donation could take all the sponsorship money. As a consequence, the sharing has been very unequal up until now.

I started an email thread to discuss this, with a desire to make the splitting more intentional. Both Piotr and Blake responded, and Blake drew my attention to this discussion he'd started, so I thought I'd make use of it. Looking at the current splitting ratios, and for want of a better idea, I suggested this mechanism:

If you've signed up with thanks.dev and you're a maintainer on TypeStrong that you should get an equal split of monies for TypeStrong from thanks.dev.

Piotr was happy but said:

That would work for me for sure, but I think that most donations go to either ts-loader or ts-node. I’m ok with lower percentage (like 10%) or somehow routing only donations for fork-ts-checker-webpack-plugin to me (not sure if that’s supported).

Blake made the valid points:

From looking into the sponsors, more than 50% of the sponsors are for ts-node too, so sources of funds is surely relevant.

I think the fairest approach would be to reward the maintainers of the respective projects getting sponsored

From looking at the relevant section here: https://thanks.dev/dependents this bears out what Blake is saying. Most sponsorship is for ts-node and ts-loader.

There's are other factors that play into this which may be worth considering:

1. Amount of sponsorship - if you have a large supporter donating for a specific project but only smaller ones for other projects, should the split be affected?
2. Who is the/are the present maintainers? Blake is the most recent maintainer for ts-node, I am for ts-loader and Piotr is for fork-ts-checker-webpack-plugin
3. How much work maintainers are doing on a project. It's somewhat hypothetical, since ts-node, ts-loader and fork-ts-checker-webpack-plugin seem to be in maintenance rather than active development, but the demands on a maintainer seem like they maybe should have a bearing (although it might be hard to come up with a nice mechanism to determine this)
4. The dynamics of sponsorship. If say 50% of the sponsors drop off in a month, that should probably have an effect upon the splitting.

As I understand it, the only configuration possible at present is somewhat static. We don't have a maintainer in place for all sponsored projects, eg tsconfig. I can see that there are no registered sponsors for fork-ts-checker-webpack-plugin. However, given that fork-ts-checker-webpack-plugin is commonly used with ts-loader, I would happily give a percentage of ts-loader sponsorship to fork-ts-checker-webpack-plugin on an ongoing basis.

I'd like to propose the following split mechanism initially on that basis:

• 65% of sponsorship to ts-node maintainers; presently @blakeembrey
• 25% of sponsorship to ts-loader maintainers - presently @johnnyreilly
• 10% of sponsorship to fork-ts-checker-webpack-plugin maintainers - presently @piotr-oles

How does that sound? It should be adjusted over time as sponsorships change. Likewise if people come forward as maintainers for sponsored projects like tsconfig and sign up with thanks.dev we should adjust also.

Question for thanks.dev

Given that we're actively discussing the mechanism, I wanted to ask @nehzatali and @nehzata of thanks.dev if the platform might be open to implementing a dynamic split mechanism of some kind?

Consider:

Imagine we have a config file that lists the maintainers of the different projects in the organisation, who are registered with thanks dev.

Could that be used to dynamically assign funds to maintainers based upon the specific projects that are being sponsored? So if sponsor X sponsors 2 projects, assign those funds to the maintainers of those two projects. Meanwhile if sponsor Y sponsors only a single project, assign funds to just the maintainers of that project.

I realise this would break my sharing with fork-ts-checker-webpack-plugin mechanism if implemented, but I'd be happy to directly sponsor the project on thanks.dev to resolve that, if that works.

Interested in your thoughts.

[nehzata]

Hi @johnnyreilly & co,

Unfortunately, we only track funds at the entity level (GitHub user or org). The reason for that is to avoid the challenges associated with self dependencies, eg gh/eslint/eslint depending on gh/eslint/some-other-project. In this example, under our approach, all of some-other-project's dependencies are hoisted up as eslint's.

Related to what you're trying to achieve, we do have an action item in our backlog to support a redirect directive in the orgs THANKS.yaml file. The intention of the feature would be to redirect x% of funds received by the org to user A, and y% of funds to user B, etc. Thinking being org admins would update this file as required and as collectively agreed.

Please note, we're currently overloaded with work related to Ubuntu & Launchpad integration. It'll be a little difficult for us to commit to implementing this feature at present.

Hope this helps!
Ali,

[johnnyreilly]

Thanks for responding @nehzata - no worries; good to hear you're busy with important things!

[piotr-oles]

65/25/10 split sounds good to me. Should we move forward with it until we have support for redirect policy from thanks.dev? :)

[johnnyreilly]

I would be happy to proceed @piotr-oles (but then it's my suggestion; but not surprising). I'd love to hear from @blakeembrey as well if possible. Blake do you have a view?

[blakeembrey]

@johnnyreilly That seems generous. My ideal would be package sponsorships go directly to their maintainers though, but it doesn't sound possible right now so your proposal sounds reasonable.

Do you know the mechanics of how to achieve this for now? Ideally I'm not adding another thing to anyone's (including my own) plate to manage.

I'd also love to be able to quickly swap myself out for another maintainer if someone else steps up for ts-node or tsconfig. I don't have the bandwidth for those projects so if someone asked I'd like to be able to hand it over seamlessly. There's no rush on this since I'd hope anyone taking over isn't in it for the funding, but it's a good to know for myself or others. Currently I sponsor the previous maintainer of ts-node but it's not simple to do that manually, so I just made it a static recurring sponsorship.

[blakeembrey]

How much work maintainers are doing on a project. It's somewhat hypothetical, since ts-node, ts-loader and fork-ts-checker-webpack-plugin seem to be in maintenance rather than active development, but the demands on a maintainer seem like they maybe should have a bearing

This one is tricky. ts-node is maintenance because the demands were too high. I'd love to restart development when I finally have the capacity, but having sponsorship change on level of input feels like the wrong metric (even if I were to start doing more). It rewards the wrong thing, and may be subjective.

And tbh knowing that people are sponsoring X or Y might help decide where to focus efforts. Right now I just don't have a sense how many people are willing to pay to make ts-node work properly 🤷

[johnnyreilly]

Thanks Blake, that's super helpful!

Do you know the mechanics of how to achieve this for now? Ideally I'm not adding another thing to anyone's (including my own) plate to manage.

As I understand it, the mechanism is configured in code. If we have a repo in a particular place with split information in there then that drives the mechanism. If it is that way then you'll be free to change the split / maintainer at any point.

@nehzatali and @nehzata could you advise on how we implement this please?

Once we have the information I can get it implemented for us. And once it's in we can amend it as necessary easily.

[nehzata]

Thanks for the update @johnnyreilly. We've increased to priority on the THANKS.yaml updates required in our backlog and will update here as soon as it's deployed.

Thanks for being patient with us while we work through it.

[johnnyreilly]

Thanks @nehzata!

[piotr-oles]

Hi @nehzata! Do you have any updates on this or is there a place where we could follow the progress, like a public board? :)

[nehzata]

Hi @piotr-oles not yet. Still occupied with Launchpad integration for canonical. Will ping as soon as we get started on this.