[Info-vax] Beyond Open Source

[IanD]

On Friday, May 8, 2015 at 9:37:12 PM UTC+10, Stephen Hoffman wrote:
> On 2015-05-08 05:38:37 +0000, IanD said:
> 
> > Opensource gains favour when one rapid development of a new idea but as 
> > the article alludes to, becomes more and more difficult as a project 
> > grows and code contributions come in from an increasing number of 
> > sources
> 
> It also becomes more difficult as the scale of the problems increases.  
> Even for the side projects, I'm working on vastly bigger problems than 
> I once was.   Better tools and better frameworks help somewhat here -- 
> this is part of why I whinge so often about tools and frameworks, and 
> why working on other platforms can produce results more quickly -- and 
> part of the increases in scale of the work just involves working with 
> ever-larger groups of people (or taking longer and longer to get 
> anywhere particularly useful).
> 

Frameworks are akin to a standard, yes, they allow faster development. For example, who, on large projects develops code outside of a framework now?

Even things as simple as a standard log format makes OpenVMS painful. No central registry of events, no common log file format from which to easily mine information from, very painful

I'm often getting requests for statistics like 'How many of xyz occurred over the past 3 months' in this application. To mine that simple information is painful. Log files dumping data in blurb fashion with little or no structure have to have scripts specifically written to deal with that particular log file - drives me crazy. Linux folk whip up quick scripts and often have the data ready in less time. Maybe my DCL sucks but I'm not that bad at it!
When 500 linux systems can spit out consolidated statistics versus 1 VMS system that seems to require a different script for each log file, it makes VMS look pretty shabby by comparison

Data events are the lifeblood for compliance checking and in this regards VMS is behind IMO

I'm going through a process mining course at the moment and that field is growing in importance over just data mining, process mining on VMS is painful because the different tools store different events in different formats making it a lot more difficult to roll up events across the system to get an end to end view

I'd love to see an event logger like windows has on OpenVMS :-)

> > I mentioned open source for VMS especially if a new stack was going to 
> > be developed but the jury is out on that one
> 
> A new stack?  Are we referring to OpenVMS or to IP or to something 
> else?   Bootstrapping takes vendor and community commitment, and a 
> bunch of people, a whole lot of time, and -- again -- better tools and 
> frameworks.   The developer and user expectations are also moving 
> forward rather more quickly, particularly in comparison to the pace of 
> OpenVMS in recent years.
> 

A 'new' stack was mentioned as per the roadmap

Quote: New TCP/IP stack

It's there, listed under Q4 2015, software subheading

'New' to me means NEW, not rehashed, not reworked, not already existing and given a new face, but NEW

In the HP/VSI OpenVMS breakfast a question about the new stack was asked and someone asked if it was Progress software under a license. No specific answer was given, in fact, the answer that was given was that details could not be disclosed

When I said 'new' I was quoting the new word mentioned in the roadmap taking into account that new in English normally means new, not revamped or pre-existing but new

Now it appears that possibly new is not really new in terms of what the English definition of new means...

> > Lots of examples of open source being used to fork projects when people 
> > see a different end need for the software in question - I don't think 
> > VMS has that luxury at this stage, the base is too small at this stage
> 

> Are you thinking of forking OpenVMS itself?  If so, I'm skeptical that 
> a non-commercial or non-commercially-funded entity would get anywhere 
> with such a project, beyond basic maintenance.
> 
> There just aren't enough folks with the free time necessary and 
> particularly the interest necessary to pull something with ~30 million 
> lines of code forward (fast enough to matter) to bring more folks onto 
> the platform.  Even within the OpenVMS community, there are and will be 
> schisms; some see OpenVMS as a desktop platform and some as an embedded 
> server platform.  Some look askance at newer tools and approaches, and 
> others want or need those.  Some folks are absolutely dependent on 
> formal vendor support and/or Oracle databases or other features, and 
> others not so much.
> 

In time who knows what's possible in the future

IF IF IF is the pre wording I would use here

Linux builds are a dime a dozen which allows people to create distributions that target a specific situation. Scientific linux, pclinux, centos, puppy, kali, tails etc are all specific versions targeting specific needs. One size does not fit all

That's the advantage linux has in terms of being able to be rolled to meet a specific need when one arises. The one's I listed above specifically exist to target a particular need and to excel in that need

VMS in contrast is mostly of the old school, trying to be monolithic, an all things to all type of approach

The point of open source to me is to get as many people interested in a project as possible (as mentioned before, some programmers will not touch closed source systems due to philosophical beliefs, so why limit the number of potential people possibly working on a system). I believe even MS are going to open up .NET source code going forward, they see the need to embrace certain philosophies around coding. From a business support aspect, closed source can be dangerous especially when the creator/owner decides to do something different in life or the company closes shop! At the breakfast, there was someone in anguish over the recent announcement by IBM to close down one of it's messaging systems on OpenVMS - leaving this persons business vulnerable going forward. Closed source is fine if you have a way of obtaining the source or a pathway out should the software owner get hit by a bus but it's risky for a business now and it shows up on business contingency plans now as a risk

I look after a system that see's certain folk trying to get rid of it continually. The source code is with a company that has been sold to another and they don't want to support the application anymore and the people who did develop it years ago have mostly moved on now - it's a huge business risk now. The eye is on transferring the functionality to some Oracle system and turning off the VMS box altogether. If the code was open sourced at least, we would have picked it up and reduced our risk exposure but now were stuffed in terms of staying on OpenVMS :-(

> > As long as there are enough core developers to keep enhancements and 
> > bug fixes coming in a reasonable time frame
> 
> Out of curiosity, how many folks do you think is "enough"?  VSI is 
> aimed at a ~hundred full-time paid folks, and only a fraction of those 
> will likely be working on OpenVMS itself (some will be working on 
> infrastructure, customer support, and in administration and management, 
> etc), and they probably really want more folks than the ~hundred.   It 
> wouldn't surprise me to be able to utilize four or five hundred 
> full-time paid folks without too much effort, for the kernel and for 
> all those parts and pieces and layered products that are now typically 
> part of the kernel, and for layered products and tools.  Again, the 
> scale of the problems has increased, as have the expectations, as has 
> the surprisingly difficult problem of increased simplicity.  Xcode is 
> rather larger than LSEDIT, the newer language standards tend to be 
> larger and more complex, and the typical web-facing tools and libraries 
> and frameworks are rather larger than libwww and Mozilla Seahorse and 
> Apache HTTPD, for instance.  Put another way, an operating system 
> project is the proverbial bottomless pit of software developers -- up 
> until "tactical incompetence" becomes "strategic incompetence", you can 
> want and need and use as many developers as you have access to.
> 

Number of programmers depends on different factors

I seem to remember a MS study that put the number at 20 as optimal. Scrum I think suggests 7 +- 2 (so between 5 and 9).
Above 20 and error rates start to creep in

I don't really know, I've worked in teams with around 15 programmers working on a single application but on different subsections of it and that number seems to allow for contingency (illness, holidays etc) as well and increasing/decreasing workloads - I really don't know to be honest

Release cycles were monthly. I guess most folk would be happy with OpenVMS functionally being released on say utilities on a 3 month cycle and core OpenVMS on say a 9 month/yearly update cycle?

> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

An OS over time seems to be going towards being a giant framework provider under which different entities will be able to exist and run in their own world as they see fit

Docker for example will almost decouple the underlining OS from the application

Will an OS eventually fulfill the enterprise directory paradigm I wonder?