[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How Debian Packaging practices could apply to VistA maintenance and distribution

Adding my two bits' worth, for what they're worth.

First, the easy part.  The mechanics of creating a Debian package of VistA will be completely straightforward.  I know because I have created many VistA installers.

VistA will be distributed as a large number of source program files and database extracts, 100% ASCII source code.  The Debian package will be around 175MB (33MB routines zipped, 141MB database extract zipped, less that 1MB miscellaneous zipped, such as shell scripts).  Routines will be compiled on the local machine by the postinstall script.  In fact, compiling routines can even be optional because GT.M compiles them on demand.

A binary Debian package doesn't make sense: the object files will be approximately twice the size of the routines and both routines and object files will be need to be in the package anyway - one of the features of the M language is a $TEXT() function that allows a program to look at its source code at run time, and most M applications use $TEXT().

VistA consists of over 25000 routines of M source code.  For example, with the WorkdVistA EHR flavor:

gtmuser@gtmworkshop:~$ ls -l /opt/WorldVistAEHR/VOE10/r|wc
  25164  201306 1559911
gtmuser@gtmworkshop:~$ du -sh /opt/WorldVistAEHR/VOE10/r
142M    /opt/WorldVistAEHR/VOE10/r

M source code, especially as written for VistA is information dense.  Here is a completely random sample:

IEN . ; otherwise, we're in the IEN subscripts & need to process
 . . E  Q:'$O(@DINDEX(DISUB,"ROOT")@(DIVAL,""))
 . . S DIMNEM="" Q
 . D TRY
 . Q

There are a couple of (proprietary) M to Java converters, and the story has it that when someone tried running one on the VistA code base, they ended up with around 5GB of Java source code.

So, from a size point of view, VistA on the server side will be about the size of a pure-server GNU/Linux distribution.  It is a character mode application.  Client applications are completely separate.

The complexity of VistA comes from its vertical integration.

Consider an office suite or a web server.  The package is quite separate from the content.  It's easy to upgrade LibreOffice without touching the documents, spreadsheets and presentations created with it, or to upgrade Apache without touching the web pages that it serves.  VistA is not like that.

In VistA, the code and database are tightly integrated.  Even sites that use only part of the functionality of VistA invariably install all of it, because even if you only want to implement minimal functionality (e.g., Admission/Discharge/Transfer), it's almost impossible to pull that apart from everything else.  Once you start configuring a VistA environment (e.g., by defining locations), it becomes more integrated.  Once you add patients, that's another layer of integration.

So, what a VistA Debian package can do is provide the core VistA system that can be installed on a computer and from which environments can be created on that computer.  Existing environments cannot be upgraded by installing an updated Debian package.  VistA has its own package management system (called KIDS) and each installed VistA environment on that computer will need to be upgraded by applying KIDS packages.

I hope this is good beginning.

-- Bhaskar

On 01/24/2012 12:37 PM, Luis Ibanez wrote:
This is email is the continuation of a conversation
that started here:

VistA has a large code base (~2.5 million lines of M code,
that are probably equivalent to ~10 MLOC in C language).

This is complemented with a family of applications that 
include GUIs and web interfaces among other things.

OSEHRA (http://www.osehra.org) is creating an open source
environment for VistA to thrive on and to be made available to
a larger user base.

VistA is currently composed of 168 Packages:

and it has been compared to a combination of an operating
system with a collection of related applications.

The packages are not completely independent among 
them, and therefore require some form of versioning 
care when they are patched, updated and distributed.

When we picture the challenge of growing an open source
community that would be able to properly take care of VistA,
we can imagine the scenario where each one of the 168 packages
is guarded (or "sponsored" to use Debian terms) by one or two
developers. (which means that we need between 200 to 350 
VistA 'packagers').

Along with the packagers, the actual maintenance and daily care
of the code will require about 10 time more developers. For an
estimated total of about 3,500 developers. For all this to be 
effective, these developers should be collaborating closely
with about 7,000 people with clinical background (doctors
nurses, pharmacists...). That close collaboration is one of the
reasons why VistA fit so well in the medical environment.

This estimation of a ~10,000 people strong community would
follow the typical power-log distribution of participation, where
a small group does most of the work.

A large fraction of this community would have to be composed
by  the developers, managers and clinical personnel that take care
of these tasks at the VA today. They would be complemented
with members of the larger open source community, and by
a new generation of M developers that we need to start training
and educating today.

Just to clarify, here we are not talking about creating a Debian 
package for VistA.  Although that is certainly something we 
want to do, and that it seems that it will be the next best target
once we have a Debian package for  fis-gtm.   (we probably 
should follow up on this in a separate thread).  Instead, of a 
VistA Debian package, the conversation here is about:

     Could VistA build an open source community 
     after the model of Debian packaging community ?

It would seem that the human+technology infrastructure,
+ governance, that Debian has established for its own
packaging is the proper level of support and organization
that will be needed to take care of the natural complexity 
of VistA. In particular, Debian has found the sweet balance
between agile behavior and formal processes, that make
possible to keep up with the rapid innovation of the upstream
packages, while still maintaining structure and organization.

To answer that question above we would need to get the 
combine the expertise of Debian packagers with the
experience of VistA developers and users.

I hope this topic is of interest to this list, and if so,
we probably should make an effort to bring more
VistA developers into this conversation as well.


GT.M - Rock solid. Lightning fast. Secure. No compromises.
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

Reply to: