> You even come to the conclusion that such work isn't going to happen > for free, but leave the result dangling. Especially since OpenBSD > isn't a PRODUCT. If product-servicing is a requirement, first of all > choose something which is a PRODUCT, then choose a PRODUCT VENDOR who > actually does SERVICING. It's doubly hard, without having to hold > a non-product non-vendor responsible for a servicing requirement, > which WE DO WELL WITH, but expecting more is ridiculous. AND WHERE > IS THE PONY.
OK I have done a lot of cutting and I may have put your words out of context, this isn't intended of course, however I feel when you say "OpenBSD isn't a PRODUCT" that this just can't be. By that I mean, that I buy every CD that comes out, a) it has an ISBN number so it's a book (but not really) b) It has a booklet inside so perhaps it is a book. It has 3 awesomely decorated CD's inside too, that contain binary code to run on a set of computer architectures and the last CD has source code so the purchaser can study the inner workings of the binary, *) these are expected to be synced. When running the contents of your product it's able to compile itself from the provided source code with means of a GCC compiler. The fact that you don't want to promise service for your product is your decision, but it is a product. In fact it's a wise decision because you'd be facing a lot of work for which human resources are needed and human resources require money. The income of your product is not substantial to pay the human resources to deliver service. Perhaps for future customers who are looking around a book store and find your product it should say "AS IS. Promise no further service." so that they can spend their money wisely. Regards, -peter
