Hacker News Reader

Comment by ribasushi | Hacker News Reader

> Help in maintainship how?

Pay.

That assumes the maintainer wants to be paid. There are plenty of us who maintain FLOSS projects that do it for other reasons and any monetary exchange would burden us, since it might pressure one that this is now a job and you have to execute on tasks - there are enough headaches handling other things as it is.

Agreed - I already have a job where people come asking. If developing OSS came with obligations, I’d do something else instead.

That’s of course a fine approach for you. I think a big part of the problem in this case is not with the maintainer, but with the critical software that took a dependency on this hobby project (in the maintainer’s own words).

Agreed.

To me it would make more sense to add more eyeballs looking at what gets committed. For example, in this case who would you pay? The new (co-)maintainer was compromised and it would not help to pay him. Thus, in order for payments to help one would need to have some assurance that the person getting paid is not compromised. The easiest way to have some level of such assurance seems to be to pay ones own employees. This is of course not bulletproof, but certainly adds another layer to pulling something like this off.

At the same time, this attempt nicely illustrated that the chain is only as strong as the weakest link since, as I understand it, no part of the backdoor was committed to the git repository in cleartext. Instead, the part of the backdoor that was at least somewhat identifiable was only included in the tarballs that would be downloaded and used by Debian/Fedora when building the packages for these distributions, thus giving a very nice trade-off between the chance of someone detecting what was going on and the potential impact of the backdoor.

The new (co-)maintainer was compromised and it would not help to pay him

Depends upon your perspective.

Hacker: "Oh it was hilarious, you should have been there! They donated $1M to the project after I hacked the code, so I took the $1M too."

Pay is not the only thing regarding maintainership.

Time is another factor. It takes time to maintain software, improve the codebase, add features, etc. Then there are the other tasks such as answering questions, reviewing PRs, triaging bugs and feature requests, etc.

So getting more contributors, people to assist with bugs and bug investigations, etc. is arguably more important. Especially projects developed by a single person, or a small number of people. That's the avenue that opened up this attack.

It is easy to get burned out implementing features that end up being more complex than expected, interacting with users that want different things from a project, and having a growing list of issues and PRs. That's the scenario that happened with xz, and is common with popular software that is maintained by a solo developer.

The other aspect to this is the direction the maintainer wants to take the project in. If another maintainer has a different direction in mind, that's going to cause tension.

Time is money

Time and money are not actually 100% fungible, but there is a lot of truth to it, especially given enough money.

Maintainers are human. They need to eat, to sleep, to visit the doctor, to rest when they get sick, to participate in activities that reduce stress and foster human relationships. Money makes all of that much easier.

>So getting more contributors, people to assist with bugs and bug investigations, etc. is arguably more important.

Pay is how you get more contributors.

Huh? So anyone who asks/says something in OSS, should just throw money into the ring to have an opinion?

No. But if the maintainer is burning out and doesn't have free time available for it, paying them so they can take time off to actually work on the thing is a nice way of fixing issues.

Not everyone can take time off from their day job just because somebody paid them a nominal amount of money.

Besides, the maintainer in this case was already taking time off regularly, not to work on xz, but to get away entirely from any kind of programming work. Throwing money in his general direction probably wouldn't have helped with the burnout, unless you were offering to help him hire somebody.

The more money we give, the more viable it becomes for maintenance to become their day job. It's very likely that more money here would've mitigated the burnout. Aside from just being able to quit their actual job and focus on their passion project, it's acknowledgement that the world finds this work valuable. In many cases, burnout comes from a lack of recognition, or the sense that you've done all this work and nobody really cares.

I don’t understand this view of “If I give someone unsolicited money, they will do what I want”.

You have it backwards: The notion that open source developers can not or should not ask for monetary compensation for their work is what leads to their exhaustion and their project's demise.

Of course if the developers don't want to be paid, then that's that. But otherwise, there is a very heavy atmosphere in the open source community of excommunicating anyone who dares to ask for payment as heathens of the vilest order.

> there is a very heavy atmosphere in the open source community of excommunicating anyone who dares to ask for payment as heathens of the vilest order

I fully agree that forcing payment or using dual licensing is unfortunately heavily frowned upon. But a voluntary Patreon/donation option is perfectly acceptable to the same anti-payment people.

No, maintaining such software should be a paid job. Not that that guarantees all, but it could be a step.

Who is the employer? I’m all for supporting open source and am a maintainer and contributor myself, but I don’t think blindly stating it should be a job is the solution.

That's a thorny question. Self-employed is an option, but it limits the possibilities: a small project/library won't bring enough funding, so you'd have to acquire more projects and funding. A larger company doing only OSS could work. It can help keeping all those languishing projects up to date, because it's simply part of someone's job now instead of voluntary work after hours. Such a company could also organize security checks and vet the contributors. Didn't Redhat work like that?

But it's not a solution for all problems.

Reply on news.ycombinator.com