[Info-vax] Taking a break - Open Source on OpenVMS Conference Calls Resume in the FALL of 2022...

[Arne Vajhøj]

On 6/15/2022 8:23 AM, Simon Clubley wrote:
> On 2022-06-14, <pedersen at ccsscorp.com> <pedersen at ccsscorp.com> wrote:
>> John and I STILL BELIEVE that the GNUlib Assist Library makes the most sense
>> to help reduce the effort of porting to OpenVMS the myriad of Open Source
>> Packages that are out there and which are beneficial but which folks have
>> not undertaken due to the various efforts that have be more or less randomly
>> applied based upon the findings during the porting process.  If we could get
>> a build with minimal effort and then worry about how to optimize and
>> integrate OpenVMS specific features the process could be sped up by at least
>> an order of magnitude or more.
> 
> The Cygwin approach of providing core Unix compatibility functionality
> in a library and then building Unix applications against that library
> would indeed appear to be the best approach for VMS, given that it has
> been a major success story on Windows and has provided us with a rich
> Unix userland environment on Windows.

*nix compatibility is definitely a good thing.

But a few comments.

1) Cygwin is not a success on Windows. It is a great thing, but
    it has not gotten mainstream for Windows development and
    its use is pretty rare.

2) *nix compatible libraries are great but please do not make it
    a separate *nix "subsystem" with *nix shell.

    That is not what most VMS users want.

3) The open source world in 2022 is not the same as the open
    source world in 1992.

If one looks at:
   https://madnight.github.io/githut/#/pull_requests/2022/1

It shows:

Script
------
Python 16.7%
JavaScript 14.3%
TypeScript 9.1%
Ruby 6.2%
PHP 5.3%
Dart 0.8%
Perl 0.2%
Lua 0.1%

JVM
---
Java 13.1%
Scala 1.7%
Kotlin 1.1%
Groovy 0.3%

Traditional
native
------
C++ 7.0%
C 3.0%

New
native
------
Go 7.9%
Rust 1.1%
Swift 0.7%

CLR
---
C# 3.1%

Arne