So are you saying that the source code itself is a side issue, i.e. I benefit by putting code in the sunshine for anyone's review, and organizations that plan to compete with the software don't care about access to the source code since they'll start from scratch anyway? Will they really? I suppose that organizations that plan to compete will have their own challenge if their "non-open source" stuff is not far spiffier.

With regard to the resellers I hope to sign up, I guess ultimately they don't care where the code comes from as long as it works and as long as it catalyzes the additional sales/services opportunities that will be part of their offerings. For them do I cast open source as "reliability insurance?"

Should I maintain the trappings of traditional software packages of installation keys for demo versions and serial number keys for production versions? Obviously the wrapper enforcing the key can be deleted but that would violate the license agreement, wouldn't it? :-)

Does 'open source' code present far different issues for maintenance? What about proliferating versions?

My main point was that many times issues of training, maintenance and feature enhancements aren't considered when you look at a problem and say, "That's not so hard." I know I've been guilty of that false hubris in the past.

Whether open source is appropriate in this case is another issue. If you're creating a framework that provides some basic functionality that others can customize (like a specialized application server), then open source can be a good idea. (IME open source software works best when it's infrastructure.)

This is particularly true for attracting VARs. The permanent availability of the framework can be a strong argument for a VAR to invest the time and resources necessary to learn the framework and possibly adapt existing software to fit in or use it.

Regarding installation keys: beats me, although I doubt people will miss them :-)

Chris
M-x auto-bs-mode