This post just in on the hardhats list: ‘Thursday, May 12th to Sunday, May 15th, WorldVistA is holding a small
technical meeting to verify, package, and release OpenVistA version 4.
Since this will be a technical meeting, it will not make a good venue
for those seeking an introduction to VistA, or looking for installs on
their laptops or discussion sessions, or even to socialize or make
plans. It will be an old-style, heads-down, hard-working meeting
focused on achieving results as efficiently as possible…’ Read More for the complete text of the announcement.
This release is a turning point in how OpenVistA is developed, and will
finally set in motion changes we have been planning since 2001:
1) OpenVistA will be kept in sync with VA’s FOIA release of VistA. It
will be a superset of FOIA VistA. All VA FOIA functionality will be
included. In addition, verified development done outside the VA and not
yet adopted by the VA will also be included; this add-on work will be
done in the form of KIDS patches applied to the FOIA, so that the exact
relation of OpenVistA to FOIA VistA will remain close and explicit. The
OpenVistA 4 release will include the most recent FOIA as well as the
FOIA with the OpenVistA patches applied, so that OpenVistA adopters can
run comparisons easily.
2) OpenVistA will be a decentralized product consisting of three classes
of changes. Class I changes are those issued by the VA, and will
constitute the core of OpenVistA. Class II changes are those issued by
WorldVistA, and will constitute the verified superset around which we
build our software lifecycle. Class III changes are those made outside
these two verification shops. Class III changes that meet the published
standards or can easily be made to do so may be submitted to the
responsible development team for possible inclusion, testing,
verification, and release as a Class II change.
3) OpenVistA development will be coordinated with the VA, so they always
know where our focus of work is, and to ensure that our work remains
compatible with theirs. We will emphasize joint ventures whenever
possible.
4) OpenVistA will be developed modularly by teams, as VA VistA used to
be. The code base for each package will be the responsibility of its
team. Whether developed by its team or by outside volunteers, changes
to a package will only be released as part of OpenVistA with its team’s
review and approval, after field testing, and with the verifiers
confirming that the change meets our standards.
5) OpenVistA will be written according to the VA’s own Standards and
Conventions document, including MOP-UP and related ancillary development
standards. We intend to adopt the next version of the SAC, the one
developed several years ago but not yet adopted by the VA. The
development standard we adopt will be one of the products of the Seattle
meeting.
6) OpenVistA will be verified to published standards that meet or exceed
the VA’s own verification standards. Thus, all OpenVistA patches will
be VA-ready, to make it easy for the VA to adopt OpenVistA work whenever
they choose to do so. The OpenVistA verification standard will be one
of the products of the Seattle meeting.
7) OpenVistA will be documented to published standards that exceed the
VA’s own documentation standards. There are a number of ways in which
VA code is inadequately documented from a troubleshooting and support
perspective, so OpenVistA’s documentation standard will be tightened to
make OpenVistA easier to support than FOIA VistA. The OpenVistA
documentation standard will also be a product of the Seattle meeting.
8) After the meeting, changes to OpenVistA will be routed through the
patch module on OpenForum. Patches, whether Class I (VA) or II
(WorldVistA) will be sent by the patch module to subscribers for them to
install to stay up to date. After each new FOIA release we will release
new snapshots of OpenVistA as reference points and to simplify
installation for new adopters, but the focus of development will shift
from releases to patches, a much more dynamic and verifiable mechanism
for change.
9) The first release of OpenVistA will be fairly close to the FOIA. We
are aiming first of all to formalize and strengthen the software
development lifecycle, and only thereafter to stress that lifecycle with
rapid development.
10) At the conclusion of this meeting, the resulting code will be ready
for pre-alpha (non-production) testing, and we will be looking for
volunteers to do so. We anticipate a cycle of testing and patching
before we will be ready to go to alpha test (in a production setting).
Our first patches after release will be driven by this testing, and so
will emphasize bug fixes and accelerating the software lifecycle (tools
for testing, verification, analysis, troubleshooting, etc.).
11) One of the main reasons for creating OpenVistA 4 is to settle on a
common, verified platform into which we can integrate all the useful,
verifiable code developed by various OpenVistA teams over the last two
years. Some of it has already been donated to WorldVistA, more has been
promised, and we will shortly be soliciting donations of code from
throughout the community. All of this is essentially Class III, i.e.,
unverified code, so it will have to be evaluated, tested, documented,
and verified before we release it. When it is released, it will be
released as patches to OpenVistA 4, and will be sent from OpenForum to
subscribers, so there will be no confusion about the difference between
the Class III donations and the Class II verified and released code.
12) In short, at present all code that is in OpenVistA 2.51 (the
previous release from two years ago) but not the FOIA is Class III, and
so is all the unofficial OpenVistA code that has grown up around the
community in the meantime. This meeting transforms OpenVistA to a mix
of Classes I & II, and sets in motion the process to convert Class III
work from around the community into Class II patches to OpenVistA.
For the next few days, I will be sending daily email messages about this
meeting, OpenVistA, and related topics in preparation for the meeting in
Seattle. To make OpenVistA 4 and its lifecycle possible, we need to
decide on a license for OpenVistA 4 and its patches. That will be the
subject of tomorrow’s email.
Sincerely yours,
Rick Marshall
President, WorldVistA
PS: At the Seattle meeting, work will also continue on developing a web
front end for VistA. As that is R&D, no specific deliverable is
expected at the end of the meeting other than a status update.