[Info-vax] Evolve, or...

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-18 17:55:12 +0000, JF Mezei said:
> 
>> On 15-01-18 12:10, Stephen Hoffman wrote:
>>
>>> There is a whole lot that DCL is just not very good at, whether it's
>>> the perpetual confusion around how many single and double-quotes and
>>> ampersands are needed that confuse new users and trip experienced
>>> users,
>>
>> Touché.
>>
>> But don't all shells have some problem with the quoting ? VMS may be 
>> worse than others, but not alone.
> 
> 
> Operating systems are a very competitive business.  You're competing 
> with a pricing floor of free operating systems[1], and probably with a 
> price ceiling of what Microsoft charges for their Windows Server, RHEL  
> or whatever other products are the leading contenders in the target 
> markets.   Success is not from doing what was always done, nor from 
> aiming for what your competitors are doing now, nor from doing 
> everything exactly how it has always been done.   Sure, quality and 
> stability are important.  But so are costs, ease of use, and portability 
> of applications.

Got to agree, so far.

> Certainly aim at the existing VMS market long enough to get the business 
> going, and until VSI figures out what markets they're most successful 
> with now and which markets they can grow with, but any vendor needs to 
> aim at some combination of better, easier, faster, simpler, cheaper or 
> other benefits, if the vendor wants to attract new customers.

There is the really hard question of "what is better?"  I don't think 
there is any one answer, and for some it doesn't matter.

> Getting to a competitive and successful product is also not about 
> keeping current customers happy with what they have now, either.    It's 
> about making the current customers really want to upgrade their current 
> VMS installations, and about making third-party developers really want 
> to build and deploy on VMS.

What if they don't need anything else?  What if what they have is 100% 
satisfactory?  Not that I'm claiming VMS is such.  Lots of room for 
improvement in communications, security, and such.  But, those are 
incrimental improvements, not necessarily something new.  Well, Ok, at 
some time in the past they were "new".

> If the customers and the third-party providers aren't investing in VMS 
> upgrades, then there's a serious business problem.  If the folks are not 
> seeing the value and are not spending their money, that's bad for the 
> future of VMS.

Agreed.

> If VSI is smart and aggressive and can get enough of a revenue stream 
> going, then they'll hopefully also start training VMS customers to 
> expect some of the most crufty parts in VMS will get replaced and 
> removed, too.  Give the folks that need stability a long-term-support 
> (LTS) plan for their current application code, and get the 
> stability-oriented folks accustomed to doing upgrades on a ten-year 
> schedule[2], for instance.  But when those ten years are up, the old 
> stuff is gone from support, and the worst of the deprecated and decrepit 
> and superseded features and APIs are potentially then removed, too.  
> Yes, this is disruptive, but it's how a vendor can move faster, and can 
> adapt to changing requirements and expectations.   I'd rather have 
> improvements and rather less compatibility, particularly if I have a 
> upgrade schedule to work toward.  This whether I'm looking at more 
> bleeding-edge work for some projects, or toward an LTS upgrade schedule 
> for some production servers.

The problem with this is that for some people, it is the stability that 
they need, and not just for 10 years.  There will be some applications 
that really need that stability, and, it can be a selling point for an 
OS.  "If you use VMS, you'll be able to use it for as long as you want, 
and we won't make you change anything."

Not saying all users will be this way.  I guess my question is, since 
it's a decent guess that many of the remaining VMS users fall into this 
catagory, can VSI discount their needs?

> Predicting what the customers might want isn't easy, though.   If 
> there's not a good, embeddable, debuggable command line interface and 
> particularly that can attract upgrades and new users, then VSI might 
> choose to provide one.   But then spending buckets of time and money on 
> DCL enhancements or on a CLI replacement for DCL that doesn't then 
> encourage (enough) new users and existing upgrades?  That's a problem 
> for any vendor.
> 
> Being "worse than the others" isn't a particularly good strategy for 
> success.  Not unless you're much better in some other areas.  VSI has to 
> figure out how to get there, and to get folks to want to install and to 
> upgrade VMS, and to do so profitably.  It's _really easy_ to lose money 
> in the operating system business, after all.

I think that many will agree that "a steady paycheck" can be a good 
thing.  In the OS world, that's recurring support payments.  I honsetly 
cannot think of anything better, or as good, that VSI can attempt to 
implement.  Maybe I'll reconsider when Red Hat goes out of business.

> Shells and quoting?  Most languages don't require double- or 
> triple-quoting, nor unbalanced single-quoting.   C-like languages tend 
> to use a backslash as an escapement and not doubling or tripling the 
> quoting characters, too.  The weird quoting with DCL implies there are 
> missing features and/or accumulated hacks or different solutions, and 
> DCL is most certainly missing features such as arrays and dictionaries 
> and objects and asynchronous event notifications and asynchronous I/O 
> and UTF-8 support and command completion and binary data handling and 
> non-PIPE piping and the performance of JITing and the embed-ability of 
> compilation and...   Yes, various of those can be hacked into your DCL 
> procedures.  Then maintaining compatibility with some of that.   Which 
> is part of how we got into this whole mess.
> 
> Interesting times.  VSI has really smart folks working for them, and has 
> a whole lot of hard work and makes some good predictions.  Then we'll 
> see if VMS can swim.
> 
> ######
> [1] Linux and the BSDs are free.   RHEL is effectively free, in the 
> guise of its clones.   OS X and Windows licenses are embedded with the 
> hardware purchases.  VSI may or may not decide to follow free licenses 
> with paid support, and/or free licenses and upgrades with VSI-branded 
> hardware packages and/or paid support.
> [2] Some of the same stability-oriented folks are also going to want to 
> and need to mitigate the possibility that VSI might not be around in a 
> decade, too.  That might lead to requests that the VSI source code be 
> escrowed or archived somewhere, for instance.
> 
> 

Actually, providing users with buildable sources, along with some 
conditions and restrictions, just might be a good idea.

Face it, most serious users will not attempt to use the sources, and if 
they do, and would still be responsible for support if anything is used, 
then who cares?  Might be one way to take away any possible objections a 
user might have.  Objections can keep a potential customer from "taking 
a look".  Not a good thing, objections ....

Predictions are many times wrong, but in this case, I'm thinking that 
VSI is VMS's last chance.  Either it works, or it will not survive. 
Perhaps some "out of the box" thinking is advisable?