[Info-vax] Open Source on OpenVMS - A Progress Report

[BillPedersen]

In the last few weeks I have been discussing the needs and
requirements to revitalize the Open Source on OpenVMS Community.
Along these lines I have been involved in discussions on various
forums including: comp.os.vms, vms-sig-listserv, LinkedIn.com, my own
VMSblog as well as Twitter and Facebook.  The general concensus is
that there needs to be communication, centralized repositories,
coordination, continuity and critical mass.  These "5-Cs" are all
important to making the Open Source on OpenVMS Project succeed.

At present I can not say that any one of these issues is under
control.


Communication:

We are a diverse community.  Some of us are looking for simplication
in our lives and processes and do not want to worry about some of the
changes happening in technology and in fact would rather keep textual
communication in clear ASCII.  Others are involved in pushing the
envelope to communicate to as many as possible.  There are of course
those that float in the middle.  The challenge we face is having
effective communication between those that use these diverse
facilities.  We currently have discussions and conversations going on
the following platforms:

	comp.os.vms newsgroup
	VMS-SIG at LISTSERV.ENCOMPASSUS.ORG
	LinkedIn.com OpenVMS Community Group and other DEC groups on the site
	Facebook.com
	Twitter.com
	community-connect.org various groups and blogs on the HP Connect web
site
	VMSblog my own Blog oriented toward my thoughts and evangelism for
OpenVMS
	OpenVMS.org
	OpenVMSHobbyist.com
	VAXnotes on Eisner at the mail.encompasserve.org site

What has come of these conversations?  People are asking more
questions.  There is more interest in seeing something move forward in
the Open Source on OpenVMS arena.  The HP OpenVMS Team has started
some discussions with us.  This initial level of activity has shown
there is still a community interest in moving this segment of the
OpenVMS puzzle forward.

What has not happened?  We are still hampered by the need to
communicate in many different environments and styles.  Ah to have
some "super glue" to bind this environments together.  I have a bit of
that started with an interface between my VMSblog and Twitter.  I have
also been using the "AddThis" Firefox addon to help with some of the
other areas but I still have not found the application that really
ties things together.

So if there are suggestions or thoughts I would appreciate them.


Centralized Repositories:

Source Forge seems like the logical place for much of this work.  This
is especially true since the main line code trees of many Open Source
packages are already resident.  In discussions with folks in OpenVMS
Engineering it sounds like this is the way they are leaning.  They
already has a history there with GNV (although the code on Source
Forge has not been update since 30 July 2004...).  Other sites have
GNV including ftp://ftp.hp.com/pub/openvms/opensource/ where version
V2.01.002.1 resides as well as at ftp://encompasserve.org/gnv/ where
John Malmberg has posted various fixes and updates of the work he has
contributed.

OpenVMS.org has an excellent page on packages ported to OpenVMS
(http://de.openvms.org/OpenVMS-Ports/).  A few people have started to
add information to this about new or currently unlisted applications
and packages.  This could just as easily be used as a site for any
OpenVMS Freeware whether it be from the Freeware CD era or the DECUS
tape environment or the current Open Source fad.  I encourage you to
add your packages here or add information about packages that are
missing - EMACS for instance.  There are many more that need to be
updated and added as well.

The Freeware CD contributions and DECUS Tape contributions are another
area of repository that needs attention.  HP has indicated that they
are working to make this process more flexible and timely.
Specifically expect to see the ability to download specific
applications rather than entire CD images or tape images.  Also expect
to see a mechanism to support the updating of applications to current
versions are available in a timely fashion as well.

There is also some work being done to potentially identify a mechanism
of providing porting resources.  As an example my CCSS Interactive
Learning OpenVMS Lab Systems offer access to OpenVMS/VAX and OpenVMS/
Alpha at no charge.  While we have not yet added compilers we could do
so on request.  I am also looking at adding and OpenVMS/I64 system to
the mix and then clustering the Alpha and Integrity boxes so as to
provide development and testing resources for Open Source on OpenVMS
projects.  There are other sites available, the Deathrow Cluster for
instance.  There is also a possibility of a facility provided by the
OpenVMS Team.


Coordination:

This is one of the difficult ones. If I could wave a magic wand to
facilitate this I would.  I suspect this will take continued effort
and management.  It will also take the active particpation of
application authors and evangelists to make sure their offerings are
well represented and supported.

Documentation of best practices and solutions is very important.
Currently this information is scattered in many areas and needs a
location for focus and exchange of ideas and information.


Continuity:

None of this effort will be of any use if applications become orphaned
or if the project leaders get hit by the proverbial bus.  So the need
to make sure that each application is accurately documented and
archived so it may be supported in the future given the worst of
possible situations.  We have orphaned Open Source applications all
over the web which were great ideas and are now lingering and
potentially dying as their authors have gone on to newer, more
"interesting" projects.

The OpenVMS Community should take it upon itself to make sure that the
Open Source we use and contribute has the best possible documentation
and community support possible, no matter what the application.  We
pride ourselves on supportability and documentation and really
complain when it is not up to our expectations.  With Open Source we
need to make sure the documentation is what we would expect and the
support is similarly excellent.


Critical Mass:

Each project/package/application/utility needs a minimum number of
interested and active participants to ensure its success/completion.
The need to be involved and push information and comment to the
appropriate people is very important. The opportunity we have to move
OpenVMS forward in ways which we want and with tools we find useful is
here and making a firm commitment to these tools is necessary to show
HP Management that the OpenVMS Community is viable and wants to see
OpenVMS continue to be developed, thrive and be sold and support for
many years to come.

I look forward to the many voices and hands within the OpenVMS
Community creating a buzz and helping with the projects and all of us
seeing the fruits of our labor mature and evolve.


As we move forward I will continue my efforts to communicate with each
of you.  I will also work to improve the efficiency of the
communication and look forward to feedback and comment from any and
all in the OpenVMS Community.

Thanks,

Bill.