There has been a lot of ViewComm version vs. serial number changing the last year, so I feel that I owe you an explanation.

Almost all software companies use a version number of some kind to individuate each change, each new public release. Internally, most software companies also use a Build notation which is typically an incrementing decimal number. Each time the software is compiled, linked and whatever else is required to create a new entity, the build number is increased. This way, in a sense, internal to the software vendor, version number is partly an inconvenience or perhaps an administrative fiat the developers must live with. Much of today's software is so very complex that it is a very different thing from those special purpose applications that end users cannot buy but rather must tailor specifically to internal needs. In those cases version numbers may be relaxed to some degree.

Software tools, compilers, libraries, frameworks, APIs and the like continually evolve to meet the growing needs of an almost explosive growth pattern. Twenty years ago companies made decisions about whether to use software or stick with pen-and-ink. Today the decision process is that companies make decisions about which software to buy--and in some cases whether to develop it in-house. Today the decision to continue using pen-and-ink is for the most part a non-decision. Nobody can keep up with well designed software. But "well designed" is a moving target. And so, the version number and serial number became an organic notation. In many cases a serial number is simple enough that it reveals the year and month of release plus perhaps a build number and in almost all situations a number or string of some kind unique to the individual copy of the software.

Vendors have had to protect their intellectual property rights by keying a box of software, documentation and the like to a specific user who (hopefully) has paid for the right to use the software. Generally, when you buy a box of software, you are not buying the actual intellectual property of the developer; you are buying or leasing the right to use the software (in most cases as-is) for some period of time. In some cases this period ends when you buy the next upgrade.

Updates are contentious and interesting. Contentious because there is typically a need on the part of the user to have this or that feature--and take it from one who knows--developers listen for what the market wants; they have novel and/or pet features they want to add to the software (when was the last time you saw a really good feature disappear upon availability of a new release?). But what developers and even the market wants is not always forthcoming, for software vendors must also listen to their sales and marketing cohorts who often have different criteria for changing software. One popular graphics and desktop publishing vendor became so addicted to feature-itis that you could tell when Christmas was approaching because this company would release a new version, repleat with new features. The problem in this is many such features are not required by many users and so not everyone feels the need to upgrade. Also, a tight development cycle breeds bugs that don't get fixed until the software is released to the market. In effect, users become the beta testers.

Have you noticed that the length of serial numbers, unlock codes, CD keys, and such have become extremely long? Twenty-five characters is moderate by todays's standards. Algorithms that compute and print serial number tags and other places have become complex; No more "write it on the wall and increment it each copy you sell." Theoretically, and in fact in many cases, serial numbers are registered to individual users and are required for access to technical support, though alternate methods of identifying callers who have dogs that eat serial numbers have come into play in some software vendors. Registration can occur at the time of sale or after; in some cases you must register period; in others providing proof of purchase is required; in others reading the serial number to Tech Support when you call sufficies. To a degree, it's a matter of how well the vendor wants to treat customers.

In a few isolated cases, vendors have complex serial / version number systems where the installer can install different capabilities given different serial numbers. ViewComm 2.x and 3.x worked this way. Newer releases of ViewComm and Frontline products may or may not work this way. Complex, wish-it-would-go-away, whatever you think and however you feel about version / serial numbers, know that we vendors don't much like it either, but here's what we're up against: Ever since I've been doing this -- nearly 25 years -- I've known and gotten past worrying about one thing: For every copy of a particular software package I sell, there's two of them "out there." Either you get past worrying about this or you get ulcers or worse. I chose to get past it. Our licenses are pretty standard, "treat it like a book", remove it before you install it on some other computer. Everyone knows what these licenses say but not everyone pays attention. This is just the way the world works. I'm not advocating "Love Your Software Vendor Month," at least not yet, but thought it might be helpful to air the view from this side of the fence.