Personally, I think that it is not at all unreasonable to help out a potential customer for free. In your case, since you try to behave as rational as possible it should be easy to establish a point of no return. The potential project will make you X dollars, you charge Y dollars/hour so don't work more than X/Y hours on it for free. Obviously you want to keep this ratio as small as possible. But at least you have a hard number for reference, so don't do more than 10% of X/Y for free.

Jazz, mostly big bands from the 50's and 60's. But anything without lyrics, works to get me into the zone.

I always write tests for the small components in the code (aka unit tests) for two reasons: 1. 1 day of writing unit tests saves me a week of looking for bugs in the small crevices of a larger project 2. unit tests describe the behaviour of the component, so they double as documentation Also, since I have mostly worked at small companies there is usually nobody to double check my code. So testing is fundamental to avoid big mistakes.

Its not a silly question to ask :) I would at least include: - source code documentation (Doxygen is your friend) - build instructions (which you tested on a clean machine) - description of the communication protocol between PC and the hardware - installation instructions (which you tested on a clean machine) - use instructions (e.g. command line arguments) - eventually an high-level flowchart of how the system operates The first two items are helpful when in the future, you or somebody else needs to do some work. The other are useful for the actual users and typically will be part of manual. Which I strongly advise you to make, if somebody else isn't doing. I have found that "have you read the manual ?" substantially decreases support effort :) A lot of work ? The first time yes, a few days at least, but then it is just minor edits to the documents. I use Doxygen for generating the documentation of the source code, of the language own tool if better. And Sphinx[^] for writing the manual and instructions.

Hello, I am using runbox[^] for a couple of years now. Inexpensive, although their web interface is a bit clunky. Got it working with my domain without any problems.

The most obvious valid reason to release code as OSS if you are a stand-alone developer is that it will add credibility to your CV. Then not only you can claim that you know how do/use X, and there is also tangible proof of it. And a better CV means higher pay. Another not so obvious reason, if you give out the source code then paying customers will be easier to lure in because if you stop working on it, they are not left with a binary blackbox which they cannot use/fix. Now, you may argue that the latter is not OSS but it depends on what your business model is. OSS is a distribution stragegy that may, or may not, make sense for you business. A typical scenario where it makes sense is if you are selling hardware, e.g. an IoT for a niche market. At my current company we are using an LTE router with specific hardware I/O, which runs OpenWRT customized by the vendor. They can, and do, give us almost(*) all of the source code because their advantage is the hardware, not the software. (*) and I wish it was really, really, really all of the source code. I stumbled the other day on a bug from an OSS library that our vendor uses, but that is bundled together into a binary blob with their own private code. If I had the full source, the fix would have been done by me that very same day. Without it, I have to wait 6 months (at least) for them to make a new distro release.