[Beowulf] Application Deployment
james.p.lux at jpl.nasa.gov
Sun Oct 10 12:02:44 PDT 2004
----- Original Message -----
From: "Joe Landman" <landman at scalableinformatics.com>
To: "Jim Lux" <James.P.Lux at jpl.nasa.gov>
Cc: "Mark Hahn" <hahn at physics.mcmaster.ca>; <beowulf at beowulf.org>
Sent: Sunday, October 10, 2004 11:22 AM
Subject: Re: [Beowulf] Application Deployment
> Jim Lux wrote:
> >Precisely so...
> >MS, and the legions of developers who develop for the Windows
> >generally want some mechanism to be paid for their work.
> (please note: not intended to be flame bait or trolling)
> hrm... so do those of us who try to survive and grow in companies that
> specialize in the Linux environment.
Indeed, this IS true as well. I suppose it comes down to what you actually
want to pay for. In the generalized (oversimplified) Linux/GPL/free as in
beer model, the income stream comes from providing support, etc. while the
software development is provided altruistically (or, as advertising, good
will garnering). The U.S.Gov't and various EU institutions (ESA) pay for
development of all sorts of software, some of which has general usefulness.
USGS map data might be a good example here.
> As I have said privately to others, the GPL is not a business model.
> Moreover, the ivory tower concept of giving away the source to sell the
> consulting seems to work for very few groups, if any (I can think of
> one, mySQL AB). As it is unlikely that there will be millions of linux
> clusters out there, the MySQL model of leveraging the needs of a huge
> installed user base will not work here.
Very true, I think. Fortunately, there are people who are willing to work
with stars in their eyes.
> Most of us who are betting their families well being and livelihood on
> this, would like to be able to earn a living from this. There is
> nothing wrong with asking for money for the value you provide. Most of
> the consumers of the OSS stuff do so for varied reasons. One of the
> larger components is the "Free as in beer"* approach to cost
> containment. The control is nice, but as I see it, control is not what
> is driving the adoption of Linux based systems. Its TCO. If it costs
> you $2500 for that RHAT install, it doesn't cost you per client
> connecting to it. This immediately puts it at a (tremendous) cost
> advantage over any MSFT based solution. Add to this that this is a real
> market, with several competing vendors with mostly overlapping
> offerings. Hence there is real competition. Prices are held in check
> (to a degree).
However, in the enterprise market, I think that MSFT is holding their own
(yes, partly by anticompetitive practices, I suspect) in the TCO area. I
don't know the details of how MS licenses thousand unit installations, but
I'll bet it's not a "per copy, per year" basis. More likely, it's a "you
have X thousand computers, so you fit in our 3000-6000 unit bulk rate". The
last thing MS wants to have to do is count desktops and audit the numbers.
This is how MS deals with OEM consumer mfrs.. you shipped X number of
computers (a publically available number), so send us a check for Y*X
dollars. We don't really care if you installed Win on them or not.
> (* I know, I know, not too much free beer out there ...)
> MSFT has (at last check) the wrong licensing model for their software
> for clusters. They would need to change it in order to make it sensible
> from a financial perspective, to deploy such clusters. As this is a
> tiny market compared to their major market, I think that the needed
> changes will not happen.
I think you're right. The relatively small number of cases involved could be
handled by special deals with PR tie-in.
I could be wrong (and I think the MSFT HPC
> folks read this stuff in stealth mode, so feel free to correct me
> >Per use revenue is
> >a nice way of getting around the "bootleg copy" problem. Who cares if
> >copy it, if every time it runs, you have to hit a license server and pay
> >your little micropayment. In fact, bootlegs are great... they cost the
> >originator of the software nothing. It's the whole compatibility,
> >configuration managment thing that is a big problem (all those components
> >have to be compatible with all the other components, etc.).
> The per use view presumes you are using a consumable resource in some
> sense, and then attaching a value to it. It reminds me of the
> innumerable requests for registration going on now, coupled with the
> "would you like to view this article? only 1.95$USD right now..." I see
> linked from various news sites.
I would never maintain that the price someone is willing to pay for a
commodity is related to its intrinsic value. Something is worth what
someone is willing to pay for it. I pay (grumpily) $7 to watch a movie at
the theater. I don't imagine that the marginal cost to show the movie to me
is even close to $7.
> Of course, apart from electrical power, it is hard to understand what
> resource you are consuming when this occurs. I suspect that consumer
> backlash against this will likely halt this march. I do see a
> subscription model becoming far more likely, whereby for a fixed
> (continuous) fee, you get access to content (much like a magazine, but
> software content in this case). I think people generally would be more
> accepting of this model than a micropayment per click.
But people are willing to pay "per click" for things like SMS messages and
phone calls. (There are various "bulk purchase" schemes for both...500 free
minutes, etc., but I think those have more importance from a marketing
standpoint than from a revenue standpoint. Industries with "cost
reimbursement" models (most gov't contractors, gov't agencies, health care,
etc.) are very attracted to a "dollars per click" model, because it allows
easy allocation of costs to multiple accounts.
> Now do something interesting (which I have not seen done yet by MSFT,
> though I expect in in short order). Change the acquisition model to
> that of a subscription. So instead of paying $500 for an install with a
> free set of patches, pay $50 to acquire the base + $100/year of
> subscription. Roll the next "versions" out in phases, with
> inter-function dependencies rather than entire version dependencies.
> The software becomes the platform.
> Talk about lock-in. There will be no upgrade cycle to contend with.
> Changes can be made quite modular. New features better tested and
> rolled in in an evolutionary manner. Brand new functionality could be
> created into different subscription paths. Copying and "pirating" would
> be encouraged (you need that subscription after all) as each machine
> would require its own subscription to function.
> Rough guess, but I would bet on something much like this emerging.
This IS really the .NET model...
Get away from software being "WinXX compatible" and to "generalized Windows
platform compatible", with a steady revenue stream, just like the gas
More information about the Beowulf