Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Same here, that list from github is close to useless.

In some cases we depend on a library indirectly, because we use a wrapper to match it to our stack. An old school example is we use bower, and want to use the uglify library. Someone has made an uglify-for-bower wrapper, that's like 20 lines of code, so we depend on that. But all the meat, and where I would like the money to go, is the uglify maintainers, one level down.

I'm not saying those people making the wrappers haven't brought us some value. But it's less than the underlying library.

Github falls prey to this. My guess is thanks.dev also would? But at least it has a "boosting" option, I just don't want sindresorhus to scoop up all the money...



I would guess so as well, yes.

That doesn't stop us from sponsoring some projects, it's just a manual process and having this automated would be great. Not sure if thanks.dev can do it but at the moment I'd probably like to exclude the whole JavaScript ecosystem and just include one or two libraries that I _know_ we're using.

And I'd like a similar thing as thanks.dev but for non-code-dependencies. Let's say our devs are using Kubernetes, Kind, Visual Studio Code, VLC etc. - they are not dependencies of our code but it'd be good to have those sponsorships also managed in a single place.

There may even be some use in having a standard format to define those kind of things so they can be machine readable. i.e. I'd like a repo that contains a file with the tools we rely on that can then be used for sponsorship purposes. Like a SBOM for internal tooling.


Yeah, good point on the non-code-dependencies. While most of them I use have some big corporate backing, there's lots of small invisible things running everything getting little attention (like the old openssh story)




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

Search: