Show HN: StackAid – Fund all your open-source dependencies (stackaid.us)
- 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.
129 comments
[ 2.5 ms ] story [ 252 ms ] thread> 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.
On a donation of $10, their cut should be $0.75, given that's 7.5%.
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?
> 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.
Our goal is to support projects outside of GitHub but we had to start somewhere and GitHub seemed like a pretty logical choice.
https://sfconservancy.org/
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.
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
Thanks for the answer!
We also have a signup page https://www.stackaid.us/invite
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 :)
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.
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
https://www.charitynavigator.org/ is a start
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.
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.
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!
1. https://github.com/marketplace/actions/stackaid-dependency-g...
Can i submit a stackaid.json manually? Ie for private repositories that i want to be counted towards my funding-split?
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.
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.
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.
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...
If StackAid becomes popular, I could see developers going that route to maximize their income.
- 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'd like a service that allows me to send payment to a dependency, i'll take it from there.
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.
1. https://news.ycombinator.com/item?id=31629261
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.
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
> 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
[0] https://www.spi-inc.org/projects/
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.
https://sfconservancy.org/
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
- 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
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.
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.
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.
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.
Check out https://thanks.dev/ they have a similar solution but allow allocation control.
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.
I sincerely hope it works out. I have become somewhat cynical, and maybe that colors things.
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!
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 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.
I don’t have a choice with sub-dependencies of packages I do care about.
> 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.
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.
who, how, why?
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.
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.
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.
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.
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.
Why?
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.
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.
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)'.
This seems like a good way to exacerbate the npm problems.
This is the fist time I see a pyramid scheme that's actually a good thing :D