Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: StackAid – Fund all your open-source dependencies (stackaid.us)
226 points by nevernude on Sept 14, 2022 | hide | past | favorite | 129 comments
We strongly believe working on open source software should be a viable source of income for many more developers. Unfortunately, the following barriers limit the extent of open source funding:

- Only a small fraction of open source projects are funded, and most money goes to a few notable projects.

- Each project has to market is self to get significant funding.

- Large corporate donations provide the bulk of the funding, making it unreliable and unattainable for many.

- Finding and supporting each of your dependencies is a cumbersome task. Which ones, how much, and on which platforms?

So we built StackAid, a service that automatically discovers and funds your direct and indirect (second order) open source dependencies with a monthly subscription. StackAid is early and has a unique allocation model, so we're working with supporters and open source projects to validate the experience further. We're matching subscriptions up to $100/month during the beta.




Interesting idea, but I'm not sure that the automatic allocation model would make logical sense for many of my projects.

Some of my dependencies are complicated, critical, high-maintenance parts of my application, some are convenience wrappers for other more important sub-dependencies, and some are basic helper dependencies. Some are independent volunteer projects, and some are maintained by commercial companies by developers on salary. And some of them are libraries for services that I already pay for, like aws-sdk.

I don't think I could use something like this unless I can tweak the allocations.


Valid point about tweaking allocation, I don’t think React/Facebook needs more money compared to some other projects.

Check out https://thanks.dev/ they have a similar solution but allow allocation control.


https://news.ycombinator.com/item?id=32841229 touched on this also, auto allocation would lead to disproportionate allocation for basic helper deps


I could see current higher-level projects taking advantage of their "first in line" access to the subscriptions.

I could also see people writing "wrappers," and intercepting the top-level contribution, then skimming a bit off the top, before sending them on.

Face it. There's money to be made, and a lot of really smart folks, with no ethics whatsoever, are more than willing to go for it. They'll figure out how to game it.

The bottle has been uncorked, and the genie has escaped. There's no putting the candy back in that piñata.


We thought long and hard about how people could game the system but ultimately it will be quite difficult because you still have to convince a large number of developers to actually use and depend on your project. And since the flow of donations and dependencies is public, the community will not look kindly one individuals trying such tactics.


Fair 'nuff.

I sincerely hope it works out. I have become somewhat cynical, and maybe that colors things.


I'm not sure if you caught it but stackaid contributions trickle down. So, while `aws-sdk` gets a top-level cut of your donation, all of its dependencies, and so on, get cuts too.

Also, flip the consideration, why is it fair that you only support a hand-curated list of projects and ignore the thankless dev writing all the little helpers and utilities that save you time over and over again?

The blog post on their monte carlo simulations are pretty interesting. You can see how the funding ends up getting distributed, which is much like funding is today where people pick and choose, but with a healthy long tail that supports all the overlooked dependencies.

What I really like about this approach is how egalitarian it is. If this catches on (and I believe it will) it's a self-contained ecosystem with its own incentives and emergent behavior. It even creates a healthy incentive for projects to minimize dependencies. And a high profile commercial project might want to signal virtue by passing on its pool entirely to its dependencies. Or maybe it claims its pool and pays it out as a bonus to the team that maintains the project? Or maybe it claims the pool and uses it to fund the infrastructure and operating costs and the price of the product you already pay for goes down. The possibilities are pretty fascinating.

What stackaid presents is a solution for devs and organizations who recognize how much value their dependencies provide and want to spend more than $0/mo to support them but don't want to think too hard about it beyond that. I've been waiting for a solution like this for a long time, and I'm keen to participate!


> Also, flip the consideration, why is it fair that you only support a hand-curated list of projects and ignore the thankless dev writing all the little helpers and utilities that save you time over and over again?

There are lots of reasons. Maybe the project in question has a low impact to you, such that not having it wouldn't affect you very much. Or maybe it's something that's easy enough to write yourself and you just haven't done it because you haven't needed to. Or maybe there's a commercial alternative that's better but you just haven't needed to pay for it. You can't pretend that all of your dependencies have the same impact on your product.

With that said, I think this is a great experiment, and I'm all for incentivizing devs to use fewer dependencies!


I guess my impression is: why does it matter which ones are more and less impactful? If dependency X is a pithy trivial thing that doesn't deserve your funds, and you care so much, then write your own into a utils file. The reality is, you didn't and you're using someone else's work. I think there is a lot of weird power juju being projected here while people conveniently ignore reality. The reality is your project is supported by all these things, but the ideal in some peoples' head is that only some of them matter? I think we need a reality check. Either change your expectations to match reality, or change reality to match your ideals.

I like the idea that I don't have to go in an micromanage my dependencies and figure out which ones get what percentage of funding and this and that. I find this product compelling because of the egalitarian simplicity.


That sounds nice in theory, but if I'm running a business, unless I have more money than I know what to do with, I can only donate so much to open source development. Let's say my entire application is written using Vue.js. In that case, regardless of how many little utility libraries I use, I want to make sure that the vast majority of my contribution goes to the Vue.js contributors because Vue has, by far, the most significant impact on my business, and I'd like to make sure I can continue to depend on it in the foreseeable future. In contrast, that utility that title-cases strings that I use all over the place is great, but I wouldn't be heartbroken if it didn't exist anymore.

> If dependency X is a pithy trivial thing that doesn't deserve your funds, and you care so much, then write your own into a utils file. The reality is, you didn't and you're using someone else's work.

If the author of the utility felt that way, they could have given it a commercial license and sold it to me. I know this makes me sound cold, but open source authors know the deal they're getting, and nobody should expect to get paid any significant amount for their contributions. From a business perspective, it makes sense to fund anything you would be in real trouble without, because your money increases the odds that those projects continue to grow and be improved/maintained.

Having said all of that, I still find StackAid to be a great idea, and if I owned a (profitable) business, I could see myself using it in addition to larger donations to specific projects that my business depends on. That would be a great way to distribute the funds to all of the projects I use while still focusing on a small handful of key pieces of software.


In classical-econ I think they call it the water vs diamonds problem. People just have an intuitive sense that some abstract absolute-value matters more than subjective-value, or additional effort should be rewarded more than less-effort. These are wrong, because the real price is about the tradeoff one must make on the margin. The value something has is always about the alternatives I can take - to go to another supplier, to implement something myself, to forgo, etc ...


>If dependency X is a pithy trivial thing that doesn't deserve your funds, and you care so much, then write your own into a utils file.

I don’t have a choice with sub-dependencies of packages I do care about.


I think that's kinda the point: you don't get to control every little detail. Your funds get spread across the dependencies you use. Those funds then get spread across the transitive dependencies, recursively. Maybe what's trivial to you saves the maintainer of one of your dependencies a bunch of time, and warrants some contribution. That's up to them, not you. And in this scenario, if you remove that dependency top level, while it still might get some cut transitively, it gets far less, so you've still made a statement.


> why is it fair that you only support a hand-curated list of projects and ignore the thankless dev writing all the little helpers and utilities that save you time over and over again?

The little guy is exactly who I’m worried about.

Projects vary in number of developers, their financial arrangement, and the time that it takes to maintain a package.

I use an authentication package that is painstakingly maintained by one independent dev who kicks ass. He deserves more than a package like leftpad. Or a package that is developed by salaried engineers as an API for a product I already pay for.


On an individual level allocation may seem a bit lopsided but, in aggregate, useful and popular projects will receive more funding.

Commercial projects can either not claim their funds (which will be reallocated), or elect to pass their funds through to their dependencies.

You also always have the option to explicitly list your dependencies.


In aggregate the stripe and react dependencies in the example on the page might receive a pretty huge chunk and I'm not sure the stripe api should be funded by donations.


Honestly, it doesn't seem that hard to add blacklists, even category based ones.


If stripe doesn’t want to participate (likely) their funds are reallocated. They also have the option to pass on funds to their dependencies


So users of Stripe SDK ends up donating to Stripe SDK that reallocates those funds to the dependencies that makes the Stripe SDK possible to build, rather than Stripe donating money directly to those dependencies that makes it possible for them to build their SDK?

I'd rather fund libraries that don't have huge companies behind them, and those companies should donate themselves to the dependencies they use, so I can spend my money on donating to libraries I depend on directly.


Lovely username


StackAid founder here. There are a couple of questions that keep coming up that I thought I would address in one place.

- People don't want to give money to Stripe, Meta, etc since their projects are already well funded by corporations. We agree! Right now, those projects can just not claim their funds which would then be reallocated, or they can pass their funds on to their dependencies instead. We are exploring other ways to allow you to exempt certain organizations/repositories from being funded.

- People will try and game the system. They can try but they largely will not succeed because ultimately many developers will still need to be convinced to use and depend on their projects. How funds are allocated and what dependencies an open source project has is public knowledge and the community will rightly punish bad actors.

Thanks for all the responses and feedback.


Hey, I think this is amazing! I think this has the power to transform open source development/funding in a good way.

I have one question from the main page - it says you sign up for a subscription and list _your_ dependencies. Does that mean for an individual (non open source maintainer) you pose as a project and donate to your own project? It's not clear how this works as a contributor. Do I subscribe to projects, at a mininum of $15 per project? (Also does the project you're donating to itself get any money? Or is it 100% split among dependencies?)

I echo the sentiment about manual allocation though. There are critical project dependencies, and there are things employed in an edge feature that devs might and could be replaced at any time, and all the way between.

Right now people already have the ability to control funding - just don't use StackAid and only donate projects you feel are critical. Or they may decide to explicitly remove dependencies below some threshold. Both of these hurt the long tail. And it feels manipulative - people should have the end say in how their money is donated.

Not all projects need money too. For instance, maybe project X requires a lot of manual work (curation of country/timezone datasets) and its developers no longer have time to do it on top of their day job, vs a library that's just an interface for a standard. Or maybe the devs of project Y are in an area hit by disaster and you want to increase funding to them for a while.

Also, aren't bad actors _because_ of the automatic allocation? The current entirely manual allocation system doesn't really have issues of this sort.

That said, I'll probably sign up for this, but if you added some options for finer control I'd be singing praises high and low.


Okay, thinking about this more I think the automatic allocation might be a reasonable.

I think there's the risk of allocation getting out of drift with a project as the project evolves. Both from a sign up perspective and "if this requires hand tweaking, people will forget to do it" perspective having this low touch is probably important.

If there's manual allocations any automatic adjustments will affect existing allocations


To answer your first question, you give StackAid access to repositories that you own (private or public) and we discover the dependencies you use automatically. Those dependencies are what is funded by your monthly subscription. Let's say you give us access to 4 different repositories with a total of 50 dependencies, then your subscription is divided equally among them. Hope that's helpful.


So is this _only_ for developers, paying other developers? Can users donate to projects? What if you don't have any projects?


I just want to offer a word of support: I really like your solution! Don't get too hung up on HN curmudgeons "unable to use this product" because it does not work exactly the way they want to every last detail. There's more to this than making darn sure `aws-sdk` doesn't see a cent of your money...

You've found a need and you are addressing it. You've been thinking about this problem far longer than the drive by dissenters. You've run simulations and built the solution. Of course listen to the feedback, but don't let impact your trajectory unduly.

Personally, I find the emergent ecosystem of an egalitarian solution like this pretty fascinating. I'm totally on board. You've sold me and all you have is a waitlist. Take my card. I want to stop being the problem and actually participate in the solution (:


Also, I can't find any information about StackAid itself on the site. What country is it in (physical address or physical contact information?) What's the legal status? Right now it's totally anonymous which seems sketchy since its dealing with money.

How are taxes handled? How is money stored and transferred? What risks are there here?


Hey, we are located in the US based in Seattle and San Francisco and incorporated as an LLC. Our other founder has more of a social media[1] presence if that's helpful.

We use Stripe to process credit card payments as well as to pay out funds to projects that claim their funds. US based recipients who receive above a certain amount of money will be required to give the required information for 1099 income.

1. https://twitter.com/dudley, https://www.linkedin.com/in/dudleycarr, https://www.linkedin.com/in/wescarr


> They can try but they largely will not succeed

Whether they succeed or not, it this takes off it creates a big incentive towards adding your own crap dependency to successful projects, that is to say, more garbage PRs (some better disguised than others). It’s like the Hacktoberfest disaster. The only difference is this has a tangible upside, the question is whether is outweighs the downside (quite likely in the taking off scenario), whereas Hacktoberfest is strictly negative value-add in my experience.


There is another, opposite incentive at play which is to reduce the number of dependencies you have so that you receive more funding.


I’ve always felt that the this concept, applied to charitable donations, would be killer.

In particular, I want:

- an app like m1 finance where I can build a “pie” of charities to donate to on a recurring basis, selected from a vetted list of upstanding charities

- to clearly see how the charities use the funds, and how the app covers its own costs

- for any contribution I make, I can see the tax benefits I’ll receive for making it (I know that’s probably super hard, but if someone can figure that out, I guarantee you’ll see a spike in charitable giving)

I (probably naively) think that a product like this could help eliminate a ton of social issues by better funding charities than the current system


Apart from that last point I think that's pretty much https://www.givingwhatwecan.org


Step 2 is the hard part. How do you break down a "marketing and advertising" budget consistently? You'll find most charities purposefully do not have detailed insight into these accounts.


> to clearly see how the charities use the funds

https://www.charitynavigator.org/ is a start


This is pretty darn close to the idea I'll admit. I still think the tax benefits breakdown is a killer feature everyone is missing, and it could be even simpler to pick charities and contribute (like M1, or even all the way like Betterment)


Sounds a bit like https://kiva.org


You just described a Donar Advised Fund.


Super interesting, however you need an option for "this company commercially backs this repo so there is no need to donate".

Let's be honest, it's hard for me to justify giving a developer at Facebook who makes $500k/year an extra $5/year because Facebook is footing the bill for their salary to maintain ReactJS.


No money goes to a repository that doesn't participate in StackAid. Whatever is allocated to them from a subscription, gets reallocated after a certain period of time.

We are busy thinking through the best way to provide controls around allocation including specifying repositories/organizations you don't want to fund. This feedback is what we wanted to hear before we embarked on an approach.

Some organizations might also specify that they don't ever want to receive money, and allowing us to avoid waiting to reallocate the money intended for their repositories. This is another option we're planning on exposing.


Essentially, developers/project have to opt-out from participating on your site.

This is the problem that these "fund open source" projects run in to time and time again. Gittip (if I remember correctly) had the same issue. You're accepting funds under the name of various open source projects but not necessarily funding them. Often developers aren't even aware of the parallel funding channel and are rightfully upset about it.

I'm not saying your intentions are bad, and as an open source developer I'd love for a funding model that worked. I've just seen tens of different iterations on this same idea and none have stuck.


I don't think it's analogous to gittip where someone is attempting to send funds to a particular repository or organization, and, I assume, you don't know the status of your funds.

When subscribing to StackAid, you indicate that you'd like to support your dependencies. It's hopefully clear that their dependencies have to participate to receive their allocation. We're also upfront that not all OSS projects are interested or currently have a relationship with StackAid. As a result, allocation amongst dependencies will shift depending on the OSS project interested in participating, and that's an important feature that sets it apart from other funding models.

All of that said, we've tried to be clear in the messaging and setting expectations. We're very much open to feedback to improve what we communicate.


I think the issue is you're accepting the funds for a project without their approval and doing with it as you please.

As a product developer wanting to support I would have to make sure all my dependencies accept StackAid before I'd even use it.

As an open source developer I'd be pissed to find out that my project had $1k in funds held by some rando company in my name.


> As a product developer wanting to support I would have to make sure all my dependencies accept StackAid before I'd even use it.

Why?


Let's say I have dependencies A, B, C, D, and E.

I absolutely love A, B, C; they're critical to my project, the maintainers put pour their own time and effort in, and I want to make sure they get my support. Dep D is pretty good and I wouldn't mind throwing a bit their way too. E is some wrapper lib (or maybe a company-backed package) that I don't care to support monetarily.

Since I want to support 60-80% of my deps, something like StackAid sounds attractive; I don't have to set up and maintain individual (potentially recurring) donations to each. I set up $100/mo to be distributed, feel good about doing my part, and go back to work.

Turns out, only E is collecting their StackAid, for whatever reason. My $100/mo is all going to them. Nothing is going to any of the others, let alone the packages I definitely wanted to support in the first place. I think I've donated, so I don't think to seek projects' alternative donation channels to get the money into their pockets, so they don't see a dime.

The only solution is to go through all of my dependencies to see which ones are actively using StackAid and decide if it's a sufficient set before donating through them.


It seems very unlikely, in the long run, that people/projects that need it would leave reliable income on the table. Maybe this problem exists until people know what stackaid is, but I have a hard time believing this is an issue with the model, generally.


For reason I stated after that, but not in my own context but their context.


Doesn’t it make more sense to only send money to repositories that signed up in the first place?

That might mean the first people to register get a whole bunch of money at the start, but that just seems like an incentive to sign up.


That is effectively what happens. Unclaimed funds are reallocated after a few months to projects that have been claimed. Like you said, that's a good incentive to sign up sooner rather than later.


It's possible if there's significant funding through this, ReactJS devs may decide to quit facebook and work independently on ReactJS.


The idea is nice, but it seems heavily reliant on GitHub:

> Owners of open source projects can claim their repositories by installing the StackAid GitHub app. As part of the claiming process, owners can associate one or more Stripe accounts with each repository they own to receive payments.

While I'll admit that most of the modern ecosystem thrives on this site, especially when looking at the javascript ecosystem, there's a fair amount of projects that do not use this site at all. Are there any plans to tackle those?

Also, the simulation[1] shows projects by meta and microsoft near the top. Since these are well-funded projects ran by huge companies, I'd be interested in excluding them from a donation graph, no matter what point in the tree they appear in. Is there any possibility of doing this?

[1]: https://simulation.stackaid.us/projects


Absolutely. We'd like to support GitLab and Bitbucket next but had to pick a starting point and GitHub was an obvious choice. If there are other providers you think we should pursue, let me know.


What about sr.ht, savannah.nongnu.org or self-hosted projects using cgit or gitea frontends, most of which lacking such integrations the likes of gitlab and bitbucket provide? I'm sure it's more difficult to support things like these, but I'm wondering how flexible the system is with regards to this.


For those wondering:

> How do you make money?

> When you add your project dependencies, StackAid is treated as an implicit direct dependency. StackAid is on equal footing, but unlike those dependencies, StackAid's allocation is capped at 7.5%. In the example above, StackAid would receive $1.50/mo.


I must be missing something here.

On a donation of $10, their cut should be $0.75, given that's 7.5%.


For a $10/month donation yes our max take would be $0.75. The example on the homepage is for a $20/month subscription.


The example in the middle uses $20 as a donation, not $10. Thus, $1.5.


This is really cool. Is there a way to use this with Rust, yet?

I'd be interested to donate say $15/m and then specify repos of mine, maybe mixed with some manually specified projects (ie for things i use in private, but i don't want to give access to my private repos), and have it split among them.

but all of this is Rust-centric. Does that work yet? I'm super interested, this is a problem i've had with Github's Sponsor Program. Feels like a small amount of money doesn't go far with Github, this splitting solves it hypothetically!


Yes, we have a GitHub action[1] that uses the dependency graph API to generate a stackaid.json file which will list your direct and indirect dependencies.

1. https://github.com/marketplace/actions/stackaid-dependency-g...


Awesome, signed up!

Can i submit a stackaid.json manually? Ie for private repositories that i want to be counted towards my funding-split?


Yes you can create one manually. If I'm understanding you correctly, private organizations you add to a stackaid.json file will be ignored. Our focus is on funding open source.

But if you mean, can you commit a stackaid.json file in a private repository, yes absolutely. As long as the GitHub app is given access to that repo, we will discover it and fund dependencies specified in the stackaid.json file.


Another question if i may, do we have visibility over how funds have been accepted/moved/etc?

it would be nice to know when library authors have actually received my funds, vs them not taking them for a few months and the funds moving to another library. This would let me as a user pester the author about funds they're missing, since i'm invested in them getting support i'm trying to give.


Yes, projects with unclaimed funds have a notice at the top of their page. I think there is also an opportunity for us to show you which of your dependencies have been claimed in your dashboard.


Seems interesting... But I wouldn't want to waste my donation to a multi-billion dollar company like stripe who should be paying for their own client library development, which is part of the value-proposition of their service.


A lot of people point out "I don't want to fund a commercial organization" as a non-starter. I have a few thoughts.

1. For this to be a non-starter, it really really seems like you're either overthinking the problem/not understanding the solution, or just thinking up excuses for why you won't give back. While I think the discussion is fair, for this to be a non-starter is rather absurd in my book. That said, the ability to say "I want to use stackaid but only for non-commercial dependencies" might be an interesting option.

(Plus, can't you just make your own json file for stackaid to use and exclude the dependencies you don't want to fund? I thought the feature where the GH app reads your dependency files was just kinda helper logic to get you setup with, and automatically update, a combined dependency list. They have an example on the website for how you'd fund the linux kernel even though it wouldn't show up as a dependency anywhere.)

2. I think people are perhaps overlooking the bigger ecosystem play here. If we can, collectively, create an ecosystem where important dependencies, regardless of their commercial status, ability to market, or position in the chain, etc., get funded then I can seem some interesting behaviors emerging.

For one, the price of your commercial product might decrease if part of its development is supported by the community.

Two, there's now possibly an incentive for project authors to minimize their own usage of dependencies. This could be good or bad, but I generally think people prefer fewer dependencies for many various reasons. If it costs you money to pull in leftpad... (although given a percentage is allocated on this might not matter).

Overall, I think a product like this will result in more funds being allocated to developers who deserve them. So I want to see this effort succeed. Who know what the future holds, but if we want to start moving the needle, we have to start somewhere.


This is a well executed idea, the minus is that it is going to incentivize npm managers to create more and more spammy packages.

Isn't there a risk that the creators of is-odd, is-even, upper-case are going to get quite a lot based on their millions of downloads (and indirect popularity) no ? Especially since they are interdependent


I don't think it will be a major concern. A couple of thoughts:

- We built a simulation[1] of the NPM ecosystem to see how funds would be allocated. Frivolous projects did not see any significant funding.

- As I mentioned in other comments, you would still need to get many developer to actually use your new packages as either direct or second-order dependencies. Note that 2nd order dependencies receive quite a bit less allocation than direct ones.

- You can always manually manage your dependencies if you see a project engaging in this behavior.

1. https://simulation.stackaid.us/projects


In the simulation you can see very common helper deps do receive quite a disproportionate amount of funding relative to the effort to maintain though. For example, `rimraf` (~400 LOC), `del` (~100 LOC), `cross-env` (this one is archived) all receive a ton of funding, whereas major projects like `electron` get a small amount since it's not used as often even though it would be much more impactful if it were to fall into disrepair.


We thought a lot about the fairness of allocation. Large funding for tiny packages is a clear edge case of the StackAid model.

We are thinking through how to give subscriptions control over projects and organizations to exclude, so you could choose to exclude tiny dependencies in your subscription.

That said, defaults matter, and so it's still worth considering the implications of small projects getting a large amount of funding:

1. Subscriptions/open source repositories might be ok with a rimraf getting a lot of money, especially if it funds those developers to build other things that are high impact.

2. It might also inspire other open source projects to potentially compete for those funds in terms of offering something more or encouraging tooling that incorporates that functionality, thus creating a smaller set of dependencies.

Re: Electron getting much less than these smaller projects in the simulation. Electron getting less money is a function of the NPM packages we discovered and sampled. That could or could not be a representative set. You could argue that Electron shows up more in non-public repositories. It doesn't mean that Electron would get more money than rimraf, but the gap could be significantly less.


And pay 7.5%(!) of it to a company based in the US.

When reallocating funds back after numerous project won't install some github app to claim the money collected on their behalf, are the 7.5% kept?

What is your estimate on the fraction of projects that will actually take part?

What about the huge amount of highly used projects that are not on GitHub?


It is my understanding that 7.5% is the cap, which should only be reached when you have very little dependencies. If you have 20 direct dependencies, each one will get 5% only, including StackAid.

> When reallocating funds back after numerous project won't install some github app to claim the money collected on their behalf, are the 7.5% kept? The answer is on the site: The funds are held for 2 months, then reallocated: > A project's allocations accumulate for 2 months. If the project is not claimed by then, an automatic reallocation happens and the amount is redistributed to the other dependencies that are claimed. Reallocation occurs on a per subscription basis.


It's important to note that 7.5% is the max we would make. The more direct dependencies you fund, the less we make. When we reallocate funds, the same rule applies.

Our goal is to support projects outside of GitHub but we had to start somewhere and GitHub seemed like a pretty logical choice.


Is this in addition to a credit card processing fee? I can't find detailed ToS on your site but surely you don't eat those fees in exchange for a variable allocation?


Is 7.5% still the maximum after reallocation?


Yes it is. If there are no additional projects to fund after reallocation we will donate the remaining funds to other organizations/charities.


Could you just send a refund to the person donating? Or at least roll forward whatever wasn't donated into the next month.


Which organizations & charities specifically?


We haven't chosen them yet but they will be rotated every so often. If you have suggestions we'd be happy to hear them.


I would like to suggest Software Freedom Conservancy:

https://sfconservancy.org/


I love this idea.

I just tried with a package.json of mine and 33% of the money seems to go to Microsoft/TypeScript, which seems odd for a bunch of reasons: they don't seem to have Github Sponsors setup, they don't seem to have an Open Collective either, and TS is owned by one of the wealthiest companies on the planet, so for it to suck up any meaningful percentage of all donations seems wrong.

Edit: ah, sorry, per year figures are displayed in the breakdown table. So I guess TS would get more like 3%, which sounds way more reasonable.


Projects like TS, React, etc that are already well unfunded most likely won't claim their funds which means they will be reallocated to your other dependencies after a few months.

They will also have the option to be pass-through organizations which means that funds allocated to them will instead go to their dependencies.

We are also exploring the idea of being able to declare a list of repos/organizations to exclude from being funded.


This kind of looks like https://flattr.com/ but specifically for dev/dependencies.

Not sure I like that there's "only" a two-month limit in which funds can be claimed, though. Some developers could be very busy or get caught up with other stuff and not hear about their accumulated funds before the "expire". Some might also think it's a phishing scam if they haven't heard of StackAid before.


Fair point. There will be a longer grace period initially while we work on the awareness of StackAid.


I was sure there was a similar service that folded recently-ish? I can't for the life of me remember its name :(

My only hesitancy is how your company is structured. A charity/b-corp or similar would seem to align more with your domain, but I see no mention of anything like that on your site.

Good luck though - this is a problem that definitely needs solving.


Are you thinking of Flossbank[1]? We are currently structured as an LLC. Are there specific concerns you have that would prevent you from using StackAid because of that choice? Our hope is that our actions and being good stewards of funding open source will help earn and keep your trust long term.

1. https://news.ycombinator.com/item?id=31629261


Ah, yes, I think you're right. It was Flossbank. Thanks!

No, I'm not sure an LLC would prevent me from using it, but I'd probably choose to go with a competing org given the choice. Siphoning off profit over and above operating expenses from a sector that's already woefully underfunded is not a great look.

I'll be watching with interest though, and will take a closer look when you support Scala+sbt dependencies, repos outside GitHub, and drop the need to grant your bot access to my private repos.


Appreciate the feedback. In case you didn't see it already, we take a different approach to getting paid[1] that we think is more equitable.

You can also use our GitHub action to publish a stackaid.json file with your dependencies to a new repo just for the purpose of giving us access. This was your repos/source say private to us, but your dependencies can still be funded. It's a bit more effort on your part but hopefully addresses the concern.

1.https://www.stackaid.us/#how-do-you-make-money


If a library author or maintainer isn't a Stackaid user, what happens to their allocated funds?


After a few months if the funds aren't claimed we will reallocate them to a subscriber's other direct dependencies. For the time being, if you accepting funds via GitHub Sponsors, Open Collective, etc. we will do our best to get money to you.


> So we built StackAid, a service that automatically discovers and funds your direct and indirect (second order) open source dependencies with a monthly subscription.

Just to play.. I don't know, devil's take-advantager or whatever, if this gets popular isn't the 'smart' move to package your project as numerous components bundled up into one outer wrapper, with all other 'real' dependencies only dependencies of the component packages?

That can be a legitimate packaging strategy of course, that's what made me think of it: 'it doesn't work for ...'; then 'oh wait it works really well for that package(s)'.


Yeah that's a good question. If I depend on react, react-dom, and react-router... do they get three times the allocation?

This seems like a good way to exacerbate the npm problems.


How do you deal with the issue that a project might split itself in multiple modular parts to maximize the income from this scheme?

If StackAid becomes popular, I could see developers going that route to maximize their income.


A more likely optimization would be to remove dependencies by copying their code into your repository if it has a permissive license.


Good question. There are a few factors that I think will mitigate this concern.

- You still have to get developers to use and depend on these new projects.

- Allocation happens on a per subscription basis, so to realistically take advantage of this scheme, you will need many developers to adopt your new projects.

- Subscribers who notice maintainers doing this will be incentivized to vote with their dollars and change their dependencies to projects that aren't engaging in this behavior.


i can manage my dependency list just fine and don't need an org to help me do that.

i'd like a service that allows me to send payment to a dependency, i'll take it from there.


We tried something similar in the past: https://github.com/protontypes/LibreSelery

Donation were distributed entirely through the CoinBase api by sending emails to each developer in the Git history.

I wonder how you will divide the money among the developers. Giving money just to the project maintainers will not strengthen the community. Unfortunately, this is often exactly the area where support is needed to create sustainable open source in addition to fiscal support.


Step in the right direction. Thank you for sticking your necks out.


Could be that the model is more sophisticated that the quoted text below suggests, but if it isn't ... Well, let's say I maintain a popular package SexyAndUseful, I sign up with StackAid, and see significant cash flow; great! I also already have lots of dependencies, so many in fact that 50% of donations flowing to me go to my dependencies. But that's fine, it takes a village.

Then some Joe or Jane comes to me and says, "hey, I'll give you $$$ if you add my bogus (but harmless) package as a dependency to your project". Well, since the amount I have to pass on my dependencies is already capped at 50%, I say, hells yeah, sure, definitely. In fact, I like the idea so much I start soliciting projects to pay for the opportunity.

> Because sass has 3 dependencies, each of those get 5% of the amount given to sass. So each sass dependency gets $0.50/mo ($6/yr) and sass is left with $8.50/mo ($102/yr).

> Because bootstrap has over 20 dependencies, giving them each 5% wouldn't be fair to bootstrap, so just 50% of the bootstrap allocation is divided equally among its dependencies and bootstrap keeps $5/mo ($60/yr).


Joke's on the people who paid you. The more people who do this, the smaller amount of money they all get. It might work for the first person, but once people catch on the payout goes towards zero.


Sure, but that's about setting the right price (since in real world, its not going to approach zero all that fast)


Have you already considered working with/integrating with SPI [0] (Software In The Public Interest) that acts as legal and financial steward for many projects from large to small (e.g. Debian, NTPsec) ?

[0] https://www.spi-inc.org/projects/


I wasn't aware of SPI. I'd be happy to look into it and reach out to them.

To give some context, if SPI were interested in receiving money for repositories associated with SPI, they would work with the developers to claim those projects on StackAid and associate their Stripe account. SPI's governance model can then decide how to allocate those funds.


There are a lot of fiscal sponsors in the open source space, Software Freedom Conservancy is another one:

https://sfconservancy.org/


Congrats guys and I wish you succeed with this project!

This is the fist time I see a pyramid scheme that's actually a good thing :D


Maybe we need a meta-donor service that can support the common funding channels: GitTip, Flattr, StackAid, Thanks.dev, Patreon, etc. And do it based on the receiving dependencies preferences. Otherwise the fragmentation means no one of these will be of much use to truly reach the devs most in need.

Ideally however it's done would also minimize transaction fees and perhaps provide some sensible default along with tuning of rules. For example by default no money goes to megacorps and less goes to devs known to be rolling in funds.

It could also default to emailing a monthly breakdown, so one cannot forget. Maybe even gamify things a bit with donor leaderboards and notices when more of your deps start accepting funds.


This appears to allocate funding on a per-project basis. I wonder how projects will then reallocate that funding. My intuition says most funding will probably go to maintainers while contributors will likely miss out.


This sounds a lot like Tidelift, without their enterprise supply chain features?


We are similar in that we use a monthly subscription that ultimately pays open source developers but I'd say that's where the similarities end. Tidelift is focused on security and vetting dependencies which is a noble effort! StackAid is focused on eliminating any friction and allowing many many more developers to be financially supported and make a living developing open source.


Glad to see you doing this!

I like the value add that TideLift does, but the minimum buy-in for TideLift was more than we were willing to spend as a small startup. I felt bummed that we weren't able to help.

No such problem here, though - expect me to signup very shortly :)


Having security and vetting make it much easier to get corporations to pay for a Tidelift subscription - it means that you get something tangible to point to, justifying the purchase.

CFOs are more reluctant to pay for just straight up donations, which is why some projects sell "support", etc...

Your service is a great idea and I would love to see it take off - and I think you'd make it much easier for developers to get work to pay for a subscription if you provided some tangible feature in return.

Just start with something simple and completely automated - like license checking. Startup's don't generally do this initially, until at some point some compliance person makes them - and then the CTO needs to get someone to setup a bunch of tedious license grovelling stuff. No one wants to do it and it's annoying - people will pay for it.


[Edit: Wrong, see replies] I love the idea, but the math doesn't seem to check out on the simulation: The sum of the donation greatly exceeds the donated sum, even on the example page.

Is it also possible to tweak / cap the weight of the donations? While I might have 20 dependencies for types à la '@types/node', I don't want DefinitelyTyped to account for 50% of my donation.


Which example are you looking at? Perhaps you included the "Shared with" amounts to the total, which is actually what a project pays it's dependencies.

Currently there isn't a way to change the weights. For projects like DefinitelyTyped, react, etc, they will have the option to either not claim funds and their allocations will redistributed, or they can elect to have their allocations pass through straight to their dependencies instead.

Lastly there is always the option to create your own explicit set of dependencies you want to fund with a stackaid.json file in your repo


While taking a screenshot, I noticed my error: The donation input is monthly, but the donated amount is per year, so it should sum to 12x the monthly amount.

Thanks for the answer!


what's the thinking around supporting projects that aren't node based?

I've got tons of dependencies but none of them involve JS.

Also, what many node devs have multiple projects they rely on. what about a tool for auto-merging package.json files to make one to submit to you? Seems like right now a dev would have to go through a lot of manual work.


We do support a number of other languages/ecosystem via a GitHub action[1] which generates a stackaid.json file we use to fund projects.

All the package.json file we discover in your repos are actually automatically merged together, de-duped, etc before funds are allocated. In the app you can manage which set of repos/files you want to be included.

1. https://github.com/marketplace/actions/stackaid-dependency-g...


The FOSSjobs wiki page tracks other types of open source funding, including the patronage model like StackAid:

https://github.com/fossjobs/fossjobs/wiki/resources#patronag...


How are you dealing with tax implications?


I think this is an awesome idea, do you have a newsletter or twitter that I can follow for updates?


Thanks! You can follow our other founder on twitter @dudley or our official account @stackaid. If you sign up for an invite we'll keep you posted on new developments as well.


Am I right in understanding that projects which use stackaid install a stackaid dependency, as a result giving stackaid a portion of their subscription?

Also, how does payment to the dependency authors work? What if there are a lot of contributors?


There is no Stackaid dependency to install. We are treated as an implicit direct dependency for the purpose of calculating the fee we collect. If you have 19 direct dependencies, StackAid will be the 20th, and get 5% of your total subscription.

Anyone with admin access to a repository can register to be paid by StackAid and the total allocation for a project will be split amongst them equally. We plan to allow adjusting the percentages each maintainer receives in the near future.


What a fantastic idea. Is there an email address to contact you?


Yes! You can reach out to me at wes@stackaid.us

We also have a signup page https://www.stackaid.us/invite


Just sent you a note.


Super fantastic idea. Signed up. Thanks for sharing!


I think the automated allocation is the major concern here. Otherwise, a good model.


Really nice idea, great job :)


https://www.stackaid.us/github/Microsoft/dtslint

who, how, why?


something similar for java dependencies?


We support Java through a GitHub Action that generates a stackaid.json file that we consume with your first and second order dependencies. More details here: https://www.stackaid.us/#stackaid-json




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: