It's a fair point, but I wouldn't say that I ignored it, just that the terms of the analogy require reinterpretation to 'fit' them to the reality.

A compiler and the copy command are very cheap, provided everyone who wishes to use your product has exactly the same compiler, and cp er.. copy command, but they don't, nor should they. Once you move out of your 'production plant', the effort required to copy and compile the product start to rise. Perl itself runs more places than almost anything else you care to name, but at what cost?

A Config that contains a little under 1000 variables.

A build process that, to be frank, makes the assembly instructions for your average automatic gear box, self assembly PC, even a full blown kit car I once assembled, look relatively simple by comparison. So complicated in fact, it is necessary to distribute and build two copies of perl in each dstribution. The first is a simplified version with just enough functionality to ease the problems of configurability, so that it can be used to glue the many other tools, configurations and utilities that are required, be used to build the full product.

The alternative approach is the packaged software route as exemplified by MS. With this, each application has to be pre-built to cater for all possible eventualities, and will only run on a very limited subset of target environments. Each application becomes enormous with the weight of its runtime configurability, despite the fact that late binding is available and that 'they' control the content and functionality of the environments that they target

If 'production', in software terms, meant the copying of the code (compiled or source) onto a CD (or server) and distributing it, then that indeed is cheap. However, it doesn't. Most manufactured goods leave the production facilities as finished products ready for immediate use. Software, even the best packaged consumer software -- which currently probably mean games -- is rarely "ready for use" as it leaves the production facilities. Even most games require a certain amount of expertise and knowledge on the behalf of the purchaser, in order to install them and set them up for use. Except for those that run on proprietory, single function hardware where the variables can be much more tightly controlled than with general purpose hardware. Eg. PCs.

Currently, software manufacturers leave the final assembly, tuning and shakedown of their products to the purchaser, and the costs of the training, expertise, man hours spent performing that final assembly -- and correcting it when it goes wrong -- are rarely considered along side the purchase price, except in highly dubious 'true cost of ownership' surveys.

So,whilst the anaogy leaves much to be desired, if you extend your thinking to encompass the complete process from initial concept to ready to use, the differences becomes less clear cut.