[Info-vax] The Open-Sourcing Discussion, Yet Again (was: Re: Message from HP.)

[Stephen Hoffman]

TL;DR: open-sourcing isn't a technical issue.  It is a funding issue.

On 2013-12-11 11:22:15 +0000, johnwallace4 at yahoo.co.uk said:

> Did we ever get anywhere here with identifying important encumbered 
> bits left in VMS?

Well, yes, as much as any discussions ever get anywhere here in the 
comp.os.vms newsgroup. :-)

See 
<https://groups.google.com/d/msg/comp.os.vms/IB7RdYT9B_I/op0-f9fernMJ> 
for one recent discussion.

Folks are going to have to look at it all, per what would likely be 
considered due diligence, and the lawyers will be involved.

> Obviously there used to be quite a few encumbered bits, but how many of 
> them are still relevant?

>From my own and potentially faulty memory, there never were very many 
third-party pieces included within the base OS.  The IntraServer SCSI 
device driver, CDSA (which is open source, deprecated, and probably 
needs to be replaced with a wholly new security infrastructure in any 
case) and DXML (probably not central to most users) were among the few 
that were recalled by the folks that have seen or worked on OpenVMS 
itself.

Nothing technically insurmountable, but then this whole discussion is 
as much one of funding and revenues as technical feasibility.

> E.g. Display PostScript was there but is now irrelevant.

Layered products that might be included in this hypothetical spin-off 
or open-sourcing including DECwindows and TCP/IP Services would also 
require code reviews.   If the target is open source, then most of 
DECwindows is probably effectively in good shape as AFAIK the X and 
Motif and related copyrights and licenses (now) allow use in open 
source, and those parts of TCP/IP Services that might be encumbered and 
unavailable can probably be "SMOP'd" with BSD pieces.  Compilers and 
most anything else involved would need to be included in the review, 
too.

> Needn't be answered right here right now, but if it's already been 
> answered (at least in part) round here that might be useful (even if 
> incomplete
> and not yet necessarily 100% lawyer-proof).

Minimally, somebody's going to have to look at the copyright statements 
in all the modules involved in the OS, the build and related tools, any 
any layered products, and anything else included.   The lawyers are 
still going to have to be involved in the review.

Beyond the source code, the build and test environments are large and 
complex and with many dependences on smaller tools 
(<http://www.digiater.nl/openvms/freeware/v70/gnm/>), AlphaSDL (SDLC) 
(binaries only <http://www.digiater.nl/openvms/freeware/v80/sdl/>), and 
such.  The VDE source code control environment used for OpenVMS was 
itself custom, large, and with dependencies on Oracle Rdb and DECset 
CMS, binaries only <http://www.digiater.nl/openvms/freeware/v70/vde/>.  
You're also going to want the core compilers and probably at least for 
the parsers, particularly if you'll need to re-host those over onto 
LLVM.  Beyond C, Bliss and Macro32 which cover most of the operating 
system, probably the next gnarly hunk for porting will be the security 
system, as various parts of that are written in Ada.  Parts of the 
documentation and help text and related variously involved DECdocument 
(see the GNM output), which is now a third-party product.

OK, assuming and entirely hypothetically the source code is cleared and 
then released for the moment.  Then what?  Updating OpenVMS to meet 
what will likely be customer expectations, and porting OpenVMS to 
x86-64 will be *large* projects with *many* engineers and *years* of 
full-time work, and many of the existing OpenVMS customers probably 
won't care and won't migrate.  (You'll probably also get asked to 
back-port stuff you're working on to older releases, too.  Possibly 
even for new VAX releases.  :-) )  The port to Itanium took a 
fair-sized chunk of effort, and many of the folks working on that port 
had experience porting OpenVMS to Alpha, and x86-64 — while x86-64 does 
have four rings / modes, and there are EFI-based boxes around — is 
still rather different from any of the existing and supported 
architectures.   The port and the customers will also likely need 
third-party layered products and relational databases and such, whether 
Oracle commercial products for those that require those, or ports of 
PostgreSQL and related.  There are *many* pieces to this hypothetical 
project, and the schedule and funding and project scope and oversight 
and hosting and many other decisions and details are all ill-defined at 
present.  At best.  Assuming HP is even interested in any of this, of 
course.  It's HP's product, and they can do with it as they wish.  
Third-party folks, too, will have to spend time and effort and money 
for a hypothetical x86-64 port, too.

If you're thinking of actually doing this (HP willing, etc), then price 
out the rental on a building and power and cooling and a big network 
pipe and servers and storage and insurance, and estimate your headcount 
and calculate the local costs of the salaries and benefits involved in 
whichever region(s) you're planning on running the project within.  
That'll get you some very rough funding numbers, and a monthly burn 
rate.  Then you'll have to figure out how to make those numbers work, 
remembering to account for whatever other incidental costs might arise. 
 Then how much coding those folks might get done.  Oh, and of course 
you're going to spend shiploads of cash on marketing, because we all 
know that marketing is what OpenVMS really needed. :-)

You're also walking into an operating system competitive environment 
where there are good, free products available.  Are you considering 
having a hardware revenue stream to augment revenues when you might not 
be able to charge as much as you need for the software, and to reduce 
the support costs and the permutations of the devices that'll be in 
use?   OK.  Remember to run some financial numbers for how that might 
work, too.

If you're "just" thinking of open-sourcing and then assuming somebody 
will fix whatever code happens to break or whatever subsystem happens 
to rot as an ad-hoc project, there's still the overhead of the testing 
and builds and kitting and related, particularly if you're assuming 
some degree of code quality.  If you don't provide at least that and 
some minimal source code and API reviews, then the code-base gets 
crufty and harder to manage, and tends to start to diverge from what 
other folks might expect, and things usually start to fail (sometimes 
weirdly) in fairly short order.  There'll need to be at least some 
oversight here, as well as source code storage and build and testing.

Full disclosure: All of this is entirely HP's decision.  IANAL.  This 
posting — like all of my postings — is from old and potentially very 
faulty memory, contains guesses and the occasional stupid idea, and 
there are probably errors here.  AFAIK from The Old Daze, the idea of 
open-sourcing of OpenVMS never got past the discussion stage, including 
a session or two at Providence DECUS '99, where the customers in 
attendance shot down the entire suggestion, much to my own personal 
surprise and regret.  I'm not as familiar with the sources of the 
layered products as with those of OpenVMS, and those layered product 
source listings were not and are not AFAIK available.  The OpenVMS 
source listings distributions were and likely still are incomplete, and 
various hunks of source code were expurgated for any of various 
reasons.   Clearing all this source code for hypothetical open-source 
release is necessary, and won't be cheap.  This assuming a decision is 
even reached to do that release.

-- 
Pure Personal Opinion | HoffmanLabs LLC