Hacker News Reader

Comment by jcparkyn | Hacker News Reader

I'm not sure how I feel about this one. Sure, the maintainers have no obligation to review and merge other people's PRs. But when this also applies to genuine high-quality community contributions, I feel like there must be some negative side effects.

I'm sure this model works well for an established project like Fody that's already quite highly polished, but I'd be pretty sad if all (or even a significant subset) of open source adopted this model.

I'd definitely be interested to hear any counter-arguments to this though. Are there any avenues for individuals to contribute for free, if they aren't using it for profit?

View on HN

>> I'm not sure how I feel about this one.

I think this may be a case where because you have a bunch of freedoms, you feel like you should have more.

I say this to re-assure you, not critisize you.

Open Source, and Free Software, are very clear on the 4 freedoms you enjoy. You can use, modify, distribute etc.

But it's not a 2-way street. You have no rights about what goes back into the project, the author is under no obligation to receive code contributions, no obligation to add features, fix bugs, or anything like that.

Of course lots of projects actively seek out contributions, but it's certainly not a requirement - nor (IMO) should it be.

Coversely open source has struggled to find viable financial models. This sounds like a success story and we should look long and hard at any successful financial model.

So, I don't think you should feel unsure. If you want to contribute then chip in some loot. If it means the project becomes sustainable you are the big winner.

But most of all, I think, be careful of adding "more freedoms" to your understanding of OS and FS, when they don't exist.

The logical conclusion of everyone taking the model of "pay me to review patches or read your issues" is fragmentation. Instead of a vibrant ecosystem where people collaborate on patches and the project grows, the issues and solutions remain internalized in private forks. Is that a better outcome? From the time/money standpoint it's great, and it may make the project more sustainable since there are fewer issues and PRs to review, but it hurts the project long term.

You have articulated well the trade-off between "project first" and "business first".

From a user point of view, project first is the only thing that matters. There is an instinctive resistance to anything that gets in the way. On the other hand users generally don't care about the project authors getting paid or not.

From the author side, getting paid is often a goal. If that means limiting the community to paying users, then so be it. From their perspective they are offering value, and they choose to spend their time focused on users who are paying.

In other words they need your money, not your code suggestions. They can code, but code doesn't pay rent.

As you say, others can choose to silo their changes, and not post them back, that is their right, and indeed likely happens anyway.

I'm not saying I think the maintainers have any obligation to do things for me (I tried to make that clear in the original comment). What I was really trying to say is that I don't think this model would apply well to most projects, as the GP was saying.

To take an exaggerated example, if I tried to use this model with any of my small OSS side projects, the only result would be that no one would contribute. This model means that the development of the project is going to be almost entirely driven by:

a) The original maintainers of the project (who will rightfully get bored of maintaining it at some point), and

b) The handful of companies that have financial interest in a certain bug/feature.

Again, that's probably fine for projects like Fody, but certainly not all of OSS.

I like it personally. Free to use, pay for support.

The distribution of something already made is free. Supporting, understanding your issue, developing a fix and releasing it…all of that takes a real person’s time.

As a contractor, you learn very quickly that people will ask for anything if it doesn’t cost them anything. There are a lot of people happy to take advantage of you if you let them.

I like seeing a good model to get OSS devs paid.

I totally agree for things that would normally be described as support (e.g. feature requests or low quality bug reports), but a lot of things aren't that.

Personally, if I submit a bug report or PR to an OSS project (which admittedly doesn't happen very often), it's almost always because I think the time I've spent investigating the bug/feature could benefit other users of the project.

For my use cases, it's generally much faster and easier (at least in the short term) to just fork a project and make whatever change I need locally, than to wait for it to go through review/merge/release in the original project.

Another commenter has pointed out that they make exceptions for certain types of contributions though, which I guess would help with this.

There's an important qualification on that page:

> This process will depend on the issue quality, and the impact on the larger user base.

So, if I understand correctly, they won't automatically close issues if you aren't a subscriber, but the bar for the quality to keep it open is probably significantly higher.

I don't think that's a bad model. Although, I don' think it would scale well to every open source project having it's own subscription stream. But maybe if there were companies that maintained collections of projects?

Yeah that qualification helps a lot.

Depends on where the bar is set but as long as "A PR that fixes actual bug with nicely written code" passes I think that model is entirely fine (especially in modern era when it can bet mangled thru test suite via CI and merging it is near-zero effort for maintainer).

That's essentially someone helping your paid customers to have better product for free.

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