Comment by robocat | Hacker News Reader

Comment by robocat | Hacker News Reader

Parent Full thread

From the link:

  But it is MIT, can't I use it for free?

  Yes all projects are under MIT so the community backing honesty system can be ignored and Fody used for free.

  Do I need to be a Patron to contribute a Pull Request?

  Yes. Users must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging.

  Do I need to be a Patron to raise an issue?

  Yes. Users must be a Patron to be a user of Fody. As such when raising an issue (question, bug or feature request) and not a Patron, the issue may not be actively triaged, and eventually closed as stale. Issues from non-Patrons, that are bugs and are highly likely to affect the larger Fody user base, may justify the effort and be handled.

Also, the minimum amount is $3/Month: which surely isn’t near enough to pay for their time! Many developers can afford $36 a year, and if not, a developer can still use it for free (BSD licence) and maintain their own branch. https://opencollective.com/fody/contribute/patron-3059/check...

> Many developers can afford $36 a year

You realize that my dependency stack contains about 2500 dependencies right? If they all follow this model I’m looking at $90k/year just to contribute to a project.

? What contribution are you imagining that involves a PR to all 2500 projects?

Applying this business model to every project they use.

Do you PR or raise an issue to every package you use? You can still use 2500 different packages for free. This seems like a good example how it would work well.

My point is that you are taking their point too literally.

Also, the business model is paying a subscription for the right to submit a pull request. Sure, you could wait until you are about to make the PR to buy the subscription, but that's a pain of its own.

Their point here is that this isn't a scalable business model. That's the assertion that started this whole comment thread.

Let’s imagine you can, for example fix an issue with NextJS API system without needing to touch, say React or Express or a whole load of other deps.

You're not going to contribute to all 2500 them though. Definitely not in the same year for the duration of the whole year.

If we got subscription to dependencies, we would get only 3 or 5 deps, only required app to run. No more `is-array` like deps. Adding a new one would be deeply thought and reviewed.

To contribute to 2500 projects yes it would cost that. Otherwise your current rights or license that lets you use those dependencies already should be fine.

Maybe that would put a stop at importing stuff like left pad.

Dependency management has gotten off the rails.

So having 2500 deps would still cost a salary of one developer for a year.

I think most businesses could afford it

> You realize that my dependency stack contains about 2500 dependencies

That is amazing: when I was younger, sharing code was a goal, but absolutely nothing could prepare me for your world. Previously I have had the luck to be able to rewrite a lot from scratch, removing most runtime dependencies, although definitely not replacing build dependencies.

I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?

I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?

Modern devs don't care. They just install whatever, let it pull in 1000s of other packages, and continue on their merry way.

Meanwhile, a package you use today, can root your stuff tomorrow. That is, next update and bam! Package was sold to Evil Entity, or just the dev decides to rm your drive based upon geo location.

I get paid a lot to cleanup much of this mess, and while tools such as composer and node.js are useful, they are a horrible, horrible security risks.

If you use node or composer, be prepared for dozens of updates weekly. Each update risk laden, and feature and security fixes all mashed into one.

On a large project, you'd need multiple devs, just to audit all the change.

But as you will soon see, there will be all sorts of $reasons given, which all lack understanding of how traditional Linux distros handle updates, and boil down to "not my problem" or "someome else magically makes it safe!"

Any copyright time bombs in front-end code?

Have an unobvious copyright condition, get your code in thousands of projects, then spider the internet looking for companies that use your code, and charge them a $1000 “licensing fee”.

Or change the copyright in v1.1.2.2 and wait until everyone updates, and do the same thing.

> Modern devs don't care

I think the “modern” is superfluous and vaguely insulting: security isn’t/wasn’t cared about by most old-skool developers either!

If a package I personally used was developed like this, I'd fork it and ask my distro maintainers to point their repo at my fork with less bugs.

Will you port all subsequent patches to the parent repo to your fork? And test them?

For simple patches on my end, I'd port them forwards. For complex patches, I might hard-fork development and find like-minded people to send patches to me instead of the original upstream. Or if the codebase or changes are too complex to work effectively with, I'd abandon the project and treat it as radioactive and failing to satisfy my requirements (or even be correct).

Reply on news.ycombinator.com