[Info-vax] Evolve, or...

[David Froble]

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

Yes, yes, yes, and I think that conforms nicely with things I mentioned 
above.

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

Actually, moving from VAX Basic to DEC Basic on Alpha left some things 
behind.

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

I think that VAX Basic might have been headed toward some of those 
things.  Incremental compilation and execution is less than what you 
mention, but was in the right direction.

Yes, I think all of the above would be great.  Though I'm betting that 
the developers would be looking at something that would work for all 
languages, should they choose to do something like that.

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

Just because you say it doesn't make it so.  Ok, HW I'll give you. 
That's a no brainer.  We used to upgrade customer HW every 3 years, and 
the 3 yr warranty in leu of software support actually made the deal less 
expensive.

But why can't software remain usable for decades?  It doesn't wear out. 
  It doesn't cost anything once developed.  Getting support money for 
little investment is a GOOD business plan.

Now, that doesn't mean the Software has to remain static.  There will be 
those things that customers will want to see implemented.  As you wrote 
above.

It occurs to me that there may not be good understanding.  When you talk 
about "cruft code", I see something useful and in use going away. 
Perhaps that is not your intention.  Just as you may take what I say as 
"no changes".  That would be incorrect also, as shown above.

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

Are users going to purchase HW from VSI?  If not, then it's a non-issue. 
  As you may be aware, I feel the future will be in support moneys.  I 
will say that at this time, (and if I knew the future I'd be buying 
lottery tickets), all Codis customers do and will have a support 
contract.  So, in this case, there is your recurring revenue.

They pay for the application the same way, though it's not called 
"support", though it works out the same.  They get continuing upgrades 
and enhancements.  Nightly, if you'll believe that.  I'd think it could 
be the same with VMS.  New features, fixes, and such, for being on 
support.  Every month a paycheck, something that VSI can count on for 
their planning.


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

Perhaps it is the definitions that need to be discussed.  If open source 
is just that, you can have a copy of the sources, to archive, to study, 
as a paper weight, but you cannot sell them, you don't own them, and you 
cannot use them in any way outside stated conditions.  It could still be 
copywrited and undesired usage prohibited.  It's not much different than 
the source listings.  What's the cost?  Zero.  What's the benefits? 
Possibly more than zero.  Maybe used in education for class work.  Now 
that is a great idea.  Quit teaching *ux and weendoze.  Get some new 
people who actually know and perhaps like VMS.

"This term your course will be to study VMS, perhaps design in one new 
feature, build, run, and test your course work."

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

Well, you really set the bar rather low that time, didn't you?

:-)