[Info-vax] Evolve, or...

[Stephen Hoffman]

On 2015-01-18 23:57:58 +0000, David Froble said:

> Stephen Hoffman wrote:
> 
>> 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".

Picking a couple of ideas out of the air...  Would you upgrade for a 
release with a new native-language-integrated certificate-based 
encrypted secure network communications framework, and new frameworks 
that make it easier to catch and upload and automatically process 
application crashes?  Maybe a new BASIC environment that made 
programming in BASIC much more efficient and much more flexible, and 
something akin to the benefits of moving from VAX BASIC to DEC BASIC?  
Maybe that adds a BASIC "playground" mechanism that lets you prototype 
your code in an application environment that directly interprets the 
BASIC commands, and that displays exactly what's going on with your 
variables as you enter those commands?  There's all sorts of stuff 
happening in computing that's increasingly common, but missing from 
VMS, after all.


>> 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."

The era of hardware and software that runs for decades and that can be 
supported for decades is unfortunately gone.   The customers won't pay 
for that and/or the vendors can't afford to provide that.

> 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?

But are those folks actually buying enough software and/or gear and/or 
support to matter?

>> [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.

It wouldn't surprise me to learn that HP would preclude open-sourcing 
VMS, though open-sourcing would open up some possibilities for VSI.   
Software escrow is usually more workable.

> 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?

Yes, and part of that thinking likely involves being far more 
aggressive than DEC, Compaq and HP were...


-- 
Pure Personal Opinion | HoffmanLabs LLC