[Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1 Marketing Brochures

[Stephen Hoffman]

On 2016-10-01 14:56:24 +0000, Kerry Main said:

> While ports are available on different platforms, Apache and nginx are 
> native *nix developed so have a *nix focus of development.

Okay.    So?   Keep going.   What are you implying with that?    Unix 
and particularly Linux are the predominant competitors for OpenVMS, as 
well as an exceedingly large source of software, as well as the server 
platforms that OpenVMS will be commonly interoperating with in most 
environments.   They're fine platforms, with many good ideas and some 
of which are well worth borrowing and improving upon, yes and with some 
bad ideas and bad designs and frustrations in other parts, and Unix and 
Linux systems can be easier to manage and deploy and develop for than 
is OpenVMS.    If VSI wants to grow past the current OpenVMS installed 
base, the VSI folks will have to gain customers that might otherwise 
have deployed Unix and Linux, which means VSI needs to understand the 
advantages and disadvantages and cost advantages and cost disadvantages 
of those platforms, too.   As compared with OpenVMS.

> IIS is a good example where the vendor Microsoft has developed a 
> platform specific alternative to Apache/nginx. While many could argue 
> which web solution is better on a Windows platform, there are a lot of 
> Windows focused groups who do IIS because it is a native Windows 
> solution.

Microsoft is a wee bit larger and better funded than is VSI, and with a 
slightly larger customer base.   If VSI gets to the scale of Microsoft? 
  The calculations then differ.  Slightly.   Right now, VSI doesn't 
have enough staff for what they have written on their whiteboards — not 
by any stretch — and VSI just did an acquisition of an IP stack, and 
that's before discussing taking on the continued development and 
maintenance of project of the scale of a web server.   Whether that 
starts with WASD and hiring folks familiar with same, the development 
of a new stack, or otherwise.  For now, Apache likely means somewhat 
less customer training is required; folks already know that.

> Imho, the bundling of a solution developed specifically for a platform 
> e.g. WASD does not prevent an alternative solution like Apache from 
> also being used on a specific platform. A pre-installed Apache on LD 
> container similar to how Perl is distributed on OpenVMS might be one 
> option.

Having Perl and Apache integrated into the distro and always present 
would be far better.     Having to deal with the configuration 
permutations of separate installations means more code in OpenVMS and 
in layered products and third-party packages, more testing complexity, 
more risks of failures as the software versions skew, and more than a 
few projects that simply won't use or won't require the tools because 
they're not always present.    In short, this approach continues with 
the same scatter-shot software platform strategy currently in use, and 
with the addition of another patch path and yet another update strategy 
required, and with a completely different way to find out if the pieces 
are present, and with no obvious way to place a front-end on any of 
this to reasonably manage what's installed.   That's not forward 
progress.

> In terms of overall solutions enhancement, I remember what a Microsoft 
> Engineer told me one time - the biggest driver for new features and 
> enhancements to the core Windows platform did not come from Customers, 
> but rather the internal SQL Server, IIS and Exchange groups at 
> Microsoft. In other words, the Windows core was not being enhanced for 
> other vendor products.
> 
> That’s a pretty amazing concept - support other options like Apache, 
> but focus major core improvements on platform specific solutions.

I'd been my experience that customer-facing polling will give you very 
few new ideas, and what feedback received — and as happened at the most 
recent boot camp — will seek to dissuade development from changing the 
platform in any incompatible fashion, and — where changes can or do 
occur — will trade off current software investments and approaches for 
(often greatly) increased future development work and future management 
much more difficult, delayed release schedules, and such.   It's all a 
trade-off, of course.  But I'd prefer it if VSI had the conviction of 
their decisions, and started looking forward.   Because that's what 
brings new users.   Compatibility with the past is what makes 64-bit 
addressing such a mess to deal with.  Customers don't (yet) understand 
the value of changes and newer approaches, and — unless the questions 
are asked very carefully — will err toward avoiding costs and changes 
with their current platforms.   Quite justifiably preferring to avoid 
any changes, in many cases.   But that subset of sites — those sites in 
environments or organizations that can't or won't change — shouldn't be 
dictating the future of the platform.



-- 
Pure Personal Opinion | HoffmanLabs LLC