Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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...



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: