Live data from Hacker News

No Free Features

landshark.io

61–70 of 87 posts

Re: No Free Features

#61

If I give you a large number of scratch tickets (such that expected value is > $0), could it be considered compensation? Starting and contributing to a side project often has EROI > 0 and for many _that_ is their compensation. Now, as for Marak who is facing homelessness etc, that's just dumb (for society to treat such a beneficial member in such a manner) .

If all the dev wants is street cred, then great. I'm not telling anyone what is good for them.

I'm arguing against a norm that I see as being frequently one-sided and occasionally actively destructive, and for something like the Norm of Reciprocity in this narrow case of feature requests on open source projects.

Re: No Free Features

#62
post #56

Earlier quoted context omitted.

Here's a random simple request I got on icdiff: https://github.com/jeffkaufman/icdiff/issues/136 "ptzz: I would be nice with a new release so that options in .gitconfig works." I have no idea who ptzz is, and it really doesn't matter to me whether they're a hobbyist playing around or at a company using icdiff for paid work. Either way, I was happy for a friendly reminder that I hadn't done a release in a while and th…

This isn't a great example since dropping a new release is pretty trivial, but consider the counterfactual where you're having trouble paying rent and you do know that ptzz is a highly placed engineer at a Fortune 500 company. A little compensation starts to sound like a good idea.

I have no objection to people working on open source saying that they require payment to make changes. I think anyone who gets obnoxious and entitled in response to such a request is being a jerk.

I have a strong objection to the suggestion that this be socially required. If people felt that it was unethical to make a feature request or report a bug without offering payment, most people would not make feature requests or file bugs, and we would all miss out.

Re: No Free Features

#63
post #32

Earlier quoted context omitted.

I'm in the same position. We have a huge budget, but literally no way to transfer money to individuals or even aggregators like GitHub. Corporate credit card use for software is forbidden. Everythi g has to go through an 18 month purchase process. Sonic think a prerequisite for success would be to have a single organization that does the payment processing get set up as a vendor with lord knows how many large compani…

Having a payment processing vendor that handles OSS projects is an interesting concept. That sounds like a large hill to climb before we can get OSS project changes funded, but regardless it seems like a viable idea. As an engineer, what would you do internally to nudge things in that direction? What would you say to your manager to plant the seed and encourage it to grow upwards?

The one thing I would never do is advocate internally for 'supporting' or 'sponsoring' OSS. Managers will just hear 'we should pay for something we already get free'.

The best way to sell the idea is to make it transactional. 'We need feature X. It'll cost us N to pay the core devs for it, or we can do it in house for N^2.'

Then put together a spreadsheet of those examples and send them up the food chain come budget time.

Re: No Free Features

#65
post #35

Earlier quoted context omitted.

No bullying, but Facebook wanted a change in one of my repos. The engineer said it was important for “security”, but had no motivation to contribute: https://github.com/wbond/asn1crypto/issues/59 . Eventually I ended up having to do the work because other organizations didn’t like that I didn’t bundle 3MB of test fixtures with the releases on PyPi.

Sure, I'm not at all surprised that bigcos make bug reports or feature requests from time to time. This one seems like an issue that was also important to Ubuntu, so a good contribution from them? Or no? And it seems like the person was pretty polite about the request? Admittedly they could have been more specific, but that seems like a generic newb developer issue than a FAANG-specific problem.

I don’t think it is a newb question, they just wanted me to revamp how I release my project and couldn’t be bothered to contribute to the goal.

Re: No Free Features

#66
post #32

Earlier quoted context omitted.

Having a payment processing vendor that handles OSS projects is an interesting concept. That sounds like a large hill to climb before we can get OSS project changes funded, but regardless it seems like a viable idea. As an engineer, what would you do internally to nudge things in that direction? What would you say to your manager to plant the seed and encourage it to grow upwards?

The one thing I would never do is advocate internally for 'supporting' or 'sponsoring' OSS. Managers will just hear 'we should pay for something we already get free'. The best way to sell the idea is to make it transactional. 'We need feature X. It'll cost us N to pay the core devs for it, or we can do it in house for N^2.' Then put together a spreadsheet of those examples and send them up the food chain come budget…

Also why it makes sense for maintainers that have the capacity to offer some token "premium support" or something along those lines. "Just give this person money because we like them" is not in the vocabulary for people approving/checking expenses, "Give this person money in exchange for a service we say we want" is totally normal. Even if the "premium" is just something relatively minor like a guaranteed response (not solution) within X working days or private submission of bug reports (and thus not having to worry about redacting logs etc posted in public).

Re: No Free Features

#67
post #35

Earlier quoted context omitted.

No bullying, but Facebook wanted a change in one of my repos. The engineer said it was important for “security”, but had no motivation to contribute: https://github.com/wbond/asn1crypto/issues/59 . Eventually I ended up having to do the work because other organizations didn’t like that I didn’t bundle 3MB of test fixtures with the releases on PyPi.

Sure, I'm not at all surprised that bigcos make bug reports or feature requests from time to time. This one seems like an issue that was also important to Ubuntu, so a good contribution from them? Or no? And it seems like the person was pretty polite about the request? Admittedly they could have been more specific, but that seems like a generic newb developer issue than a FAANG-specific problem.

One thing I would note is that typically engineers from bigger companies tend to email more than leaving public issues on GitHub. Especially in the security space, lots of users tend to seem to not want a public record of their conversation.

Re: No Free Features

#68
post #33

What about documentation? The maintainer doesn't need to document the package in order to solve their own problem (at least, not to the same level.) Should that be chargeable too? In which case the project will likely never get off the ground, and there'll be no money coming in for other change requests either. Don't get me wrong, I agree in principle. There are just too many grey areas to make a blanket rule. But wh…

> There are just too many grey areas to make a blanket rule.

Indeed. I'm not trying to write a law. More like correct a social norm.

Re: No Free Features

#69
post #66

Earlier quoted context omitted.

The one thing I would never do is advocate internally for 'supporting' or 'sponsoring' OSS. Managers will just hear 'we should pay for something we already get free'. The best way to sell the idea is to make it transactional. 'We need feature X. It'll cost us N to pay the core devs for it, or we can do it in house for N^2.' Then put together a spreadsheet of those examples and send them up the food chain come budget…

Also why it makes sense for maintainers that have the capacity to offer some token "premium support" or something along those lines. "Just give this person money because we like them" is not in the vocabulary for people approving/checking expenses, "Give this person money in exchange for a service we say we want" is totally normal. Even if the "premium" is just something relatively minor like a guaranteed response (n…

I think recurring support contracts or subscriptions are actually very problematic in the case because the gains will naturally go the projects highest up the dependency tree because they are the most visible.

However, if we payed for change requests in individual projects there would be the possibility for

1. money to trickle down from well sponsored projects to their dependencies when those higher level projects need changes

2. teams to spread money around by directly requesting changes to more obscure projects they depend on.

Re: No Free Features

#70
post #31

Earlier quoted context omitted.

Honestly I think many companies would be willing to pay for open source if internally engineers could say, "look, we depend on this project for our success and we have a vested interest in seeing it maintained well and getting our features/bug-fixes actioned, and it's a lot cheaper for us to spend $1k/year (or whatever) than for us to pay our own developers to work on it (and not our own features)". I think a lot of…

Totally, I think you’re right, a lot of companies are open to paying for it if it’s saving money and providing value. I mean, all companies already do have a software expenditure budget for commercial software. But I guess it is not simple to just put OSS projects in the same budget bucket as proprietary software. Companies have a special aversion to unexpected expenses. I’ve done business with companies that would r…

> I guess I’m not convinced that if software is offered for free in the first place that it always makes sense to expect money to be offered without asking for it.

I'm explicitly not talking about the "software ... offered for free in the first place". I'm talking about changes to that software at someone else's request.

> I just don’t necessarily agree with the hyperbole that unpaid labor is “wrong”, because that undermines the initial OSS transaction.

I don't think this is true because of the genesis of the open source software itself. I created it for my needs. I would do it even if I didn't plan to give you a copy, but the transaction between us is near zero cost so I go ahead and let you use it too because I'm a cool guy.

> The software was offered for free-as-in-beer in the first place, and that is unpaid labor.

I'm making a claim that doing something to scratch your own itch doesn't qualify as 'unpaid labor' in any useful sense. It would be like saying doing a hobby is unpaid labor.

> It’s perfectly fine to request pay for changes, so isn’t that better and more straightfoward than not asking for money but complaining when none comes?

The current norm is to not request pay or to expect to pay. My argument is that norm should be inverted and maintainers should expect payment to be offered, and requestor should expect to offer to pay. If a specific dev doesn't want to be paid, then fine. It's really about the norm changing, not mandating individual behavior.

Post reply on HN