[Info-vax] Beyond Open Source

[johnwallace4 at yahoo.co.uk]

On Friday, 8 May 2015 12:37:12 UTC+1, 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).
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

"up until "tactical incompetence" becomes "strategic
incompetence", you can want and need and use as many developers
as you have access to. "

Ever read The Mythical Man Month? If not, now might be a good
time. Throwing staff at a project helps. Sometimes.

The book's technology aspects are rather dated, but the
organisational stuff is probably mostly as relevant as it ever
was.

One main point it tries to make is that software (be it
architecture, design, code, test, document etc) is not
necessarily like bricklaying. Doubling the number of
workers on a project does not necessarily halve the elapsed
time to completion (etc), with or without new-fangled
"productivity" tools (not a reference to Xcode, as I don't
know it, but I have seen management-imposed panaceas
destroy productivity directly and indirectly, and contribute
to project failures).

Lots of spreadsheet jockeys in management still seem to
think that if you double the available working hours
per week, you'll halve the time to completion. And
that's without even considering the relevance of the
skills and experience of the staff in question. 

There might be a hip trendy modern equivalent document,
suggestions welcome. 

Till then, the original is now a legitimate free download
at the wayback machine (them again):
https://archive.org/details/mythicalmanmonth00fred

Enjoy.