3 ms·
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 s
by dcow 4y ago
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!
- RussianCow 4y ago> 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!
- dcow 4y agoI 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.
- kube-system 4y ago>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.
- dcow 4y agoI 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.
- RussianCow 4y agoThat 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.
- kube-system 4y ago> 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.