Subject: Re: Development vs. aquisition costs
From: "Karsten M. Self" <>
Date: Wed, 29 Dec 2004 13:47:56 -0800
Wed, 29 Dec 2004 13:47:56 -0800
on Wed, Dec 29, 2004 at 10:53:08PM +0900, Stephen J. Turnbull ( wrote:
> >>>>> "kms" == Karsten M Self <> writes:
>     >> >>>>> "kms" == Karsten M Self <> writes:
>     kms> I did a quick calculation for my own configuration, using MS
>     kms> Windows XP Professional as the base OS.  Rules were that
>     kms> software on the Microsoft platform had to be proprietary and
>     kms> fully-paid-up versions, where available.  Net cost: $4,522.
>     >> Why is this calculation interesting?
>     kms> Speaking for myself: I found it interesting putting numbers
>     kms> on this.
> OK, but you do admit that's an upper bound, and that even so it's
> pretty damn low for what you get in terms of economic productivity?

No, it's not an upper bound, it's discernable market costs for software
aquisition.  For a small/home office, probably relatively realistic,
depending on the software bundle.  My interest is in presenting a
 realistic  picture of costs, and I'll modify the estimate as facts

It is also only a partial cost estimate:  it's cost of aquisition.  It
ignores ongoing renewal costs (antivirus and other security software are
typically annual subscriptions), administration, and maintenance.  My
own recent experience is that recurring cleanup costs on legacy MS
Windows systems at billable rates exceeds purchase costs, and is
probably repeated several times annually.

I'll note too:  discounts are generally available *with bundling*.  It's
the nickle-dime and ad-hoc approach to systems provisioning that really
costs you, particularly compared to the low friction imposed by
GNU/Linux systems.  Proprietary oftware licensing here gets in the way.
For the home user or small/home office user, where flexibility is an
advantage and bundling opportunities are few, FS/OSS offers benefits.
Even in a larger corporate environment there are considerable benefits.

Anecdote from recent experience:  Outfitting the lab at work for a
section on sound mixing, I prepared to install the software we'd
obtained, free of charge, through a grant, on our systems.  There were
two problems though, legal and technical.  Technically, the software
wouldn't install off a server-based copy, and in fact, wouldn't run
without the install disk in the drive.  This for a network of ten
systems.  The license also restricted us to a single copy.  Looking over
Free Software alternatives, I found that Audacity offered largely
comperable features, installed from share, and (yes) allowed use on
multiple systems.

Point:  Even with zero aquisition cost, licensing terms (and resulting
technical restrictions) of the proprietary alternatives made them 

It also 
> Re CALs:
>     kms> What I'm confused about are the specifics of when CALs are
>     kms> needed, for what services, and when they're not.  It's
>     kms> decidedly confusing.
> Oh,  that .  Don't think like a central planner.  This is just what
> happens when transactions cost drop enough that "segments" can hive
> off into independent markets: they get their own prices.  (License
> fees are not transactions costs; they are revenue to the vendor.)

You're still not understanding the question.

Mind:  I'm not a legacy MS Windows admin, though I've played one on the

  - What exactly is a "CAL", in terms of the deliverable?  If you've
    ever seen 'em, you're FedExed an envelope with a bunch of papers in
    'em.  I don't recall exactly how, if at all, they're entered.  I
    think there's some sort of input screen server-side.

  - Who needs 'em.  For what?  If you follow the link you provided to
    the Minasi article, it seems to be file/print, terminal services,
    and "remote access" (whatever that subsumes), and sometimes Exchange
    access (I also STR SQL Server and related server systems).
    Different Microsoft client platforms have different CAL provisions,
    if I recall, with Win2K and/or XP including an implied CAL, at least
    for some services.  But not the DOS-based clients (3.x/95/ME), and
    possibly not NT.  

  - Add to that:  the server itself has some bundled CALs.

  - ...and "client" platforms (WinXP Pro, Win2K) have a certain number
    of concurrences.  So your small office with a bunch of share drives
    will allow up to ten concurrent accesses to a given file or print
    share, offered from a desktop.  But no more.

  - Other OS Interaction.  If you're working in a heterogenous
    environment with GNU/Linux systems smbmounting shares, my experience
    is that each mount counts as an access.  That is, the CAL (if this
    is the limiting factor) applies neither to server nor client, but
    the smbmount instance.  So one GNU/Linux system with five shares
    mounted on SERVER FOO counts as five instances, not one.
    Frustrating the first time you encounter it.  Hint:  autofs with
    very short (1-3 second) timeouts tends to minimize this problem,
    though if you're in the habit of running searches over a network via
    scripts or wildcards, you'll still periodically encounter it.

  - Are your CALs server-based or client-based?  The former allows for
    concurrent accesses, and aren't tied to a specific client system.
    Client-based CALs are tied to a specific client "signature"
    (determined Fnord-knows-how).

  - Client-based CALs aren't immediately freed up.  So if Contractor Bob
    leaves the company (with his personal laptop) and Contractor Carl
    shows up (with his personal laptp), Bob's CAL isn't freed up for
    Carl to use.  Rather, at some period (IIRC 3-6 months plus a random
    interval) the CAL is recognized as expired.  But the process is
    decidedly nondeterministic.  This may have changed since I ran
    across it (~2002), and was the cause of considerable grumbling.
> Vendors (including Microsoft) will require CALs for services where
> they think they have monopoly power.  If they find out otherwise,
> they'll change their policies.

Sure.  I'm not arguing economics here, I'm bitching about
>     >> Obviously, servers like IIS will typically admit
>     >> unauthenticated users, and they don't require CALs.
>     kms> That's actually a bit of a change from earlier policies.
>     kms> IIRC, NT distinguished between workstation and server in that
>     kms> workstation was limited to some low number (five or ten) of
>     kms> remote connections to *any* service, Web included, while
>     kms> server allowed more concurrencies.  This was before a full
>     kms> realization of what the Web was struck Redmond.
> Could be; I didn't get a good idea of what past policy was.

Tim O'Reilly actually generated quite a stir with this.  Turns out there
were two Registry entries which controlled whether a given system's
personality was NT 4.0 Server or Workstation.  One of these controlled
whether or not WS could allow more than ten simultaneous clients to
access "services of the software product, such as file and print and
peer Web services". servers/print.html

Noted for historical interest.  As you point out:  software and systems
vendors typically practice price discrimination by artificially
constraining system performance.  It's a practice with a long and
storied history.  And clients very nearly always hate it.

However, in the case of Microsoft's NTS/NTW configuration, it was argued
that Microsoft were using their vendor leverage to monopoly advantage:

    The price comparison is unfair and deceptive because the cost on the
    Netscape side of the ledger erroneously assumes the user can run the
    Netscape Web server software on Windows NT Workstation and make
    unlimited connections to a Web site without violating the Windows NT
    Workstation license agreement and without additional charge. That is
    not the case. The end user license agreement for Windows NT
    Workstation only permits up to ten connections. If the user wishes
    to utilize more than the ten connections, the user must license
    Windows NT Server. Windows NT Server is designed and optimized to
    provide maximum performance to support server services.

Note:  Dead link.  Internet Archive may help:*/

>     kms> CALs can be bought in 5 & 25-pack kits.  As well as bulk.
>     kms> AFAIU, which isn't much.
> If you want to get at a gestalt of what gets CAL'ed and what doesn't,
> I'd suggest googling for "CAL 5-pack" etc and seeing what the relevant
> services are and what they cost.  I didn't really recognize most of
> the services from glancing at them, but maybe you would---a lot seem
> to be database-related (no surprise to you, I'm sure).

No suprise, noted above.

However, and again, speaking with an admin's hat, not a pseudoeconomist,
a PITA to maintain, and given to unpleasent surprises at inconvenient
times.  Which I suppose, back to the subject of this message, impacts
costs and capabilities.


Karsten M. Self <>
 What Part of "Gestalt" don't you understand?
    You mean you were meant to hijack my truck, make me crash it, and
    have every security man in town looking for me?
    - "Brazil"

["application/pgp-signature" not shown]