HN user

qwerki

193 karma

Open source maintainers should be able to focus on writing great code full-time and not have to chase sponsorships.

ali.nehzat [at] gmail ali [at] thanks.dev

Posts1
Comments30
View on HN

With every haphazard decision we're getting a very public experiment demonstrating the value of "giving people what they want" vs "everything else". It's astonishing how resilient the network effects behind the product in this case are against sabotage. Good lesson in startups there. You just need to laser focus on creating value for the customer – everything else doesn't matter as much as you think it does? Maybe even by power of 10 factors?

Hi! Thanks for trying it out. I have reached out via email but just in case, looks like your account is configured for only first level dependencies. If you increase it to 3 levels it'll show much better results. You're also able to adjust the distribution of funds via boosting in the dependencies page.

Please note the donation will be kept in PENDING state for 5 days to allow time for full dependency analysis, adjustments via boost and/or exclusions. In this time we'll be reaching out to the other projects in your dependency tree to onboard them.

Please ping me if you need anything. Many thanks again!

Thanks quickthrower2!

Re gaming the system you're totally right. Although slightly unintuitive, we've also heard the opposite from maintainers. That they'll be motivated to remove the silly one line packages from their dependency trees due to the imbalance of value they provide vs extract.

We also prune self dependencies, circular dependencies and a few other cases to keep things level. Hopefully we'll be at a stage to open source our codebase soon and can better leverage community feedback in this space :)

Hi Animesh! The biggest difference would be that TD answers both "who should I sponsor AND how much?". It continually calculates the weight of each dependency in your codebase and distributes your monthly budget accordingly.

The next biggest difference is that it distributes micro-payments up to 3 levels deep into the dependency tree. We've noticed majority of people sponsor the top of mind projects, but the deep nested dependencies don't get any love. This automated approach should fix that.

Don't hesitate to ping me if you have any other questions please (email in profile).

Hi Koito17 Thanks for trying it out! Are you able to ping me your github handle so I can get to the bottom of it (email in profile).

Alternatively, for multi-project repos you can add a thanks.yaml file to the root of the repo with a `maxDepth: 2` value inside it. Unfortunately, deep scanning the entire repo looking for files would be prohibitive due to GH rate limiting hence this approach.

Please keep me posted. I'm also available on Discord if you need anything.

Donations are only allocated to the projects in the dependency tree that have signed up with thanks.dev. In the Sentry list for example if you click the more link at the bottom you'll see all the projects that hadn't signed in. The ones showing verified next to their name signed in after the funds for this month were processed. I see how this is causing a bit of confusion and will work on improving this aspect asap.

https://thanks.dev/p/gh/getsentry

Not sure I understand the question correctly, but the way it's working is that Sentry have allocated a monthly budget to be distributed to their dependency tree. That budget gets trickled down to the projects that have signed in. The list and breakdowns are visible here https://thanks.dev/p/gh/getsentry.

Donors decide how much to tip thanks.dev at time of donation.

Please let me know if I missed the question or if I can improve thanks.dev in any way. I'm very keen to learn. :)

Only projects that sign in are receiving funds. thanks.dev only makes money from tips at time of donation. The minimum withdrawal amount is $1 and that's a UI limitation mostly. Good idea re the global blacklist being overridable by the end user!

Hope that clarifies things. Let me know if you have any other concerns. :)

Hi HN,

This is a great initiative in supporting open source. I’m the founder of https://thanks.dev mentioned in the article and I’ve been speaking to a lot of community members over the last year.

There’s a lot of great work being done in the background that we don’t hear about and there’s an opportunity to do a lot more. I’ve learnt an immense amount since I’ve been working on this project and the diversity in thought & perspective I’ve encountered has been amazing!

Happy to chat if anyone is interested.

Big kudos to Chad & Sentry!

Ali,

Disappointing to see the top comments are not encouraging of your efforts. This is not an easy undertaking and it's clear you've put a lot of time into it – you should be commended. I wish you the best of luck and look forward to seeing more of your work!

It's great to see more discussion in this space. The way I see it:

1) It's really difficult to donate to Open Source; 2) Companies don't get enough value in exchange for donating – They are businesses and think in dollars & cents; 3) and, Devs much prefer to write code rather than chasing companies for donations & sponsorships.

As a result of these dynamics, OSS is very mispriced at the moment. Unfortunately that is going to impact quality and we shouldn't be surprised by the Log4j bug.

Open market dynamics should in theory change this one way or another. Long term you can't have some code cost $0 while an SVE's code costs $300k+ per year... Reality is open source code is badly mispriced right now.

Animations and factoids like this are somewhat deceiving. They imply a message that human runners have improved constantly since 1896 without taking into account the fact that in this period the running surface has continually improved, running shoes have gone through significant incremental improvements, starting blocks have been added and timing equipment have become more accurate.

As an example, everyone heralds Jim Hines for breaking 10 seconds in 1968 but not many acknowledge the fact that the Mexico 1968 was the first Olympic Games to use the Tartan track surface in athletics instead of what was essentially hardened sand.

Yahoo Axis 14 years ago

"a new way to access/axis the web".. they keep mentioning it in the demo video.

not being an expert in this field, one hazard that comes to mind is that a key look up could turn into a tree traversal problem, which defeats the purpose of having a cache in the first place..