That’s great in this one case but it doesn’t solve the open source compensation problem. We need a new set of licenses that allow the general freedoms of free software but also force people making large sums of money with free software to send some of it back to the open source projects they depend on.
Putty maintainer on his attitude towards security and open source
121–130 of 140 posts
Re: Putty maintainer on his attitude towards security and open source
#122I thought this was such a fantastic response, particularly the sections where he talks about how he responds to companies demanding he reply as if he has a contract with them. The main point being that, with the log4j issue (and others before that), the thing that's struck me when maintainers complain about not being appreciated or that they are working as hard as they can, unpaid, is that maintainers are under no ob…
The best way to respond would be to pretend there was a contract, and that the company was in arrears on its payment obligations. "I cannot act on any changes until you remit past-due payments." That sends them on a wild goose chase for their copy of the contract, because they cannot admit they don't have it. Eventually they run into the person who tells them there is no contract, there are no delinquent payments, an…
What's to prevent them from responding to this by asking for an invoice?
(Note: If your answer is "well, send them an invoice", the problem is that you'll probably have to contact a lawyer to make sure that the invoice is legal. You don't want to fraudulently imply a preexisting contract or run into some other legal gotcha that you wouldn't even know about.)
Re: Putty maintainer on his attitude towards security and open source
#123Earlier quoted context omitted.
"reminding colleagues that using OSS means we have to own and maintain the software whether the original community/author does or not" No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there. "There seems to be a hesitance to fork abandoned or slow moving software t…
>No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there. Seems a little disingenuous to assume that GP meant that everyone should fully maintain their own OSS stack, when their comment could be read far more reasonably as a solution for when those processes aren't…
" could be read far more reasonably as a solution for when those processes aren't serving your needs entirely"
Yeah, that is why I rephrased it, to with OSS you can own and maintain your full stack.
Op said "must".
Re: Putty maintainer on his attitude towards security and open source
#124Earlier quoted context omitted.
"reminding colleagues that using OSS means we have to own and maintain the software whether the original community/author does or not" No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there. "There seems to be a hesitance to fork abandoned or slow moving software t…
Eh, I've submitted patches for everything from the kernel to bash scripts because of bugs I've run into at work that really affected us which we needed to fix ASAP. Sure I didn't have to but isn't that the point of open source?
There is a big cost of context switch. If you are such a genious, that you can just jump around in entirely different codebases fixing entirely different set of problems, in a way that actually improves things, than hats of to you, because I can't. I am not bored and I am fully occupied maintaining my own OSS codebase and I doubt some random dude could just come and fix a problem there (unless it is a really trivial one).
Re: Putty maintainer on his attitude towards security and open source
#125Earlier quoted context omitted.
"reminding colleagues that using OSS means we have to own and maintain the software whether the original community/author does or not" No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there. "There seems to be a hesitance to fork abandoned or slow moving software t…
It's much simpler: if you run into a missing bug/feature, report it to the maintainers and ask them to assign it to you. If each individual licensee is itching their own scratches, then there's a really good chance the entire codebase gets love. Absolutist approaches are the death of all good things. "Some" is better than "none."
"Absolutist approaches are the death of all good things"
Agreed. Hence "can" and not "must".
Re: Putty maintainer on his attitude towards security and open source
#126I thought this was such a fantastic response, particularly the sections where he talks about how he responds to companies demanding he reply as if he has a contract with them. The main point being that, with the log4j issue (and others before that), the thing that's struck me when maintainers complain about not being appreciated or that they are working as hard as they can, unpaid, is that maintainers are under no ob…
The best way to respond would be to pretend there was a contract, and that the company was in arrears on its payment obligations. "I cannot act on any changes until you remit past-due payments." That sends them on a wild goose chase for their copy of the contract, because they cannot admit they don't have it. Eventually they run into the person who tells them there is no contract, there are no delinquent payments, an…
> The best way to respond would be to pretend there was a contract, and that the company was in arrears on its payment obligations.
I favor a response along the lines of "that falls outside the scope of our current maintainer-user relationship, but I'd be happy to discuss a development and support contract that would cover that effort for $X USD".
Be perfectly forthright to cover your costs, including costs of attorney, tax preparer, bookkeeper, first line support (don't forget whether support is best effort or follow the sun, or something in-between), forex conversion rates, money transfer conversion rates, and so on. Do not cave to threats ("I'll tell everyone I know your software sucks", "I'll post everywhere you are a terrible coder!") or inducements ("I have a million YouTube subscribers, I'll plug you!", "I'll make sure you are credited in our awesome game credits scroll!"). Do be nice and professional.
Learn how to say in the nicest, most professional way, "Fuck you. Pay me." [1]
To give yourself a sense of scale, proven coders with a consistent track record of delivering when they say they will, to within an order of magnitude of original delivery (to account for a hobby open source project), for an established codebase that is relied upon by the user in production and would cost them >$300K USD in fully-burdened cost across five years to rip and replace, can justifiably charge $40K USD for an enhancement that takes them a week to code up (including documenting it on both developer and user end) and a week to validate with the client. And I'm sure there are others here who can whip up an IRR spreadsheet to tell me that's charging on the low-end.
Add another $12K to support just that feature for a year after passing validation and open-sourcing it right away. Charge something on the order of $100K per year to support if if they want to own the source patch instead of it open-sourcing but still want you to maintain it; maintaining separate forks doesn't come cheap to commercial customers, the code being open source means no different. Charge for taking back in the source patch later if they want to make it private, want to stop paying support after the first year, then change their minds later. Charge for delaying open-sourcing it. Charge for changes that will take you longer than 15 minutes (including every associated task like documenting and validating) to throw in, charge for more than four of those kinds of changes. Doing anything different than just developing and open-sourcing the new feature costs you time; estimate that time, pad it for mistakes, and quote a fee. Enterprise software generally won't even begin a discussion of a forked change private to a specific client, and conversations of a feature developed for a specific customer will only start at around $1M USD, feature made available when it is finished, and the vendor owns the code.
Don't shortchange yourselves if you really know how to code, code for a specific problem domain and communicate with users in that domain in their lingo, gather requirements, set validation criteria, support technical customers, and can put up with the hassles of running a side business. You lose nothing by "firing" these customers who demand freebies with no compensation, except the Asshole Aggravation Factor in your life. Your IRL is filled to the brim with assholes. There is no need to let your open source hobby get filled with it, too.
I feel the Open Source community would be well-served by a standard boilerplate that comes right alongside the source license for charging fees for services, to set expectations that any participation by maintainers is a precious, unexpected gift at their sole discretion and whimsy. All other interaction first paid by cash.
[1] For those unfamiliar with US/Western pop culture, see https://www.urbandictionary.com/define.php?term=fuck%20you%2...
Re: Putty maintainer on his attitude towards security and open source
#127Earlier quoted context omitted.
You can’t control others emotions. But setting healthy expectations goes a long way. One of my takeaways from the log4j issue is that the log4j devs should have never accepted the patches to add LDAP urls in the first place. Or perhaps, they should have removed that feature when it became burdensome. I would have. There’s a pressure to accept whatever patches come your way as an opensource developer, but actually, yo…
Another alternative is to build a stable plug-in API rather than handling such requests in the core product. That way users with particular needs can code their own plug-ins rather than forking the entire code base. Now obviously open source maintainers have no obligation to do that, but purely from an engineering perspective it's an approach worth considering.
You then hit the two problems that everyone with a plugin API hits:
- you can't rearchitecture your software beyond a certain amount without breaking the plugin API
- if a plugin crashes, people will blame the host, no matter how you attempt to deflect this
Re: Putty maintainer on his attitude towards security and open source
#128What an excellent reminder of how easy and effective it can be to not be a jerk. I think there are plenty of people who could take some advice from this.
Are you referring to this? "But I've always been able to deal with this by pointedly reminding the most demanding people that I'm not at their beck and call. Most of those companies who mistake me for a contracted vendor are prepared to recognise their mistake once I point it out, and the more self-aware ones even apologise. I've not even found it necessary to be especially rude: a plain statement of the facts of lif…
This YouTube-video where a streamer talks about the difference between the communication on EU vs. NA servers always comes to mind when this is discussed. It is quite humorous, and perfectly illustrates your point about native English speakers: https://www.youtube.com/watch?v=8j2iX8Fgq3Q
Re: Putty maintainer on his attitude towards security and open source
#129Earlier quoted context omitted.
The best way to respond would be to pretend there was a contract, and that the company was in arrears on its payment obligations. "I cannot act on any changes until you remit past-due payments." That sends them on a wild goose chase for their copy of the contract, because they cannot admit they don't have it. Eventually they run into the person who tells them there is no contract, there are no delinquent payments, an…
What's to prevent them from responding to this by asking for an invoice? (Note: If your answer is "well, send them an invoice", the problem is that you'll probably have to contact a lawyer to make sure that the invoice is legal. You don't want to fraudulently imply a preexisting contract or run into some other legal gotcha that you wouldn't even know about.)
You ignore that. The goal is to minimize your own time wasted.
Re: Putty maintainer on his attitude towards security and open source
#130Earlier quoted context omitted.
You can’t control others emotions. But setting healthy expectations goes a long way. One of my takeaways from the log4j issue is that the log4j devs should have never accepted the patches to add LDAP urls in the first place. Or perhaps, they should have removed that feature when it became burdensome. I would have. There’s a pressure to accept whatever patches come your way as an opensource developer, but actually, yo…
Another alternative is to build a stable plug-in API rather than handling such requests in the core product. That way users with particular needs can code their own plug-ins rather than forking the entire code base. Now obviously open source maintainers have no obligation to do that, but purely from an engineering perspective it's an approach worth considering.
That's what log4net does, and presumably log4j has a plugin api too.