ClearHealth project compiles VistA to MUMPS-LESS web interface.

124 views
Skip to first unread message

Fred Trotter

unread,
May 21, 2008, 11:08:33 PM5/21/08
to Hardhats
Today at TEPR, ClearHealth announced that they have a web-based
version of VistA working without MUMPS.

Apparently the strategy is to compile the MUMPS code to C, run it
through some extensive processing, and then it becomes available in a
fashion that can be called from php.

They are currently in beta in one hospital with this technology.

I know very little about it so I cannot field questions. For those who
are very interested, take a look at this post on the ClearHealth
forums:

http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105

I am sure they might field questions from you on that same forum.

Interesting times :)

-FT
--
Fred Trotter
http://www.fredtrotter.com

Joseph Dal Molin

unread,
May 21, 2008, 11:33:06 PM5/21/08
to Hard...@googlegroups.com
....what some people will do to avoid learning a new programing language
is simply awe inspiring :-)


J

Joseph Dal Molin

unread,
May 21, 2008, 11:39:31 PM5/21/08
to Hard...@googlegroups.com
I posted a request for some screenshots on the Clearhealth forum...

J.

> .
>

Nancy Anthracite

unread,
May 21, 2008, 11:51:27 PM5/21/08
to Hard...@googlegroups.com
Patching it may be a very interesting exercise.

--
Nancy Anthracite

Chris Richardson

unread,
May 22, 2008, 6:05:53 AM5/22/08
to Hard...@googlegroups.com
And does the database scale when there are a bunch of users on?

Roger A. Maduro

unread,
May 22, 2008, 8:28:04 AM5/22/08
to Hard...@googlegroups.com
My understanding is that it is a replacement for CPRS, not VistA. It
should have the same functionality as CPRS but running on a browser. I
don't any of the MUMPS code is changed.

Roger

rtweed

unread,
May 22, 2008, 8:37:09 AM5/22/08
to Hardhats
Now if Mumps had someone fashionable like Google using it, everyone
would want to learn it instead of junking it. A lot of people will be
busy quite happily learning Python right now, simply because Google's
App Engine requires it. Turn a Google or Yahoo onto the wonders of
Mumps and globals and the tide would turn for sure. Will it happen?
Probably not.

In the meantime, all you can do is be safe in the knowledge that most
of these efforts have been ultimately doomed to failure for one reason
or another. The amazing thing is that nobody ever thinks to do any
research into the many high profile casualties there have been over
the years, or consider the untold millions (or is that billions?) that
have been poured down the "replace mumps at any cost" toilet. Why
should their efforts be successful in the light of such grim evidence?

Shrug your shoulders, smile sweetly and give a knowing sigh...

Chris Richardson

unread,
May 22, 2008, 10:37:39 AM5/22/08
to Hard...@googlegroups.com
Roger;

That is not what they said. They said " a web-based version of VistA
working without MUMPS" and "the strategy is to compile the MUMPS code to C,

run it through some extensive processing, and then it becomes available in a

fashion that can be called from php." I believe that both GTM and Cache can
work with PHP just fine without having to be converted to "C". I would love
to see their data model and watch their performance stats. I have a pretty
good idea what those will look like. If they wanted to say that they were
just replacing CPRS, then they should say so. If they didn't replace CPRS,
they could still claim that CPRS runs without MUMPS right now (as long as
you don't expect any data to come with it). If I am not mistaken, GT.M is
already written in "C" or some other compiler and pretty well optimized for
the data handling model. Re-inventing MUMPS in C would be a trick, getting
scalability and performance would be a miracle. Say you could (by some
miracle), what would you be loosing? Access to the source code (it is all a
black box and the end user is kept at arms length from verifying the
operation of the code). The user is at the mercy of the vendor once again.
Is this a good thing? I don't think so. Where is the good here?

Interesting, but is it really necessary? What is wrong with MUMPS? I
have heard of such efforts to replace MUMPS for over 20 years. If all of
this effort to replace MUMPS was so easy, it would have been done already.
It isn't a matter of money, the DoD and the VA have spent gobs of money to
replace it. What is keeping them?

Joseph Dal Molin

unread,
May 22, 2008, 11:35:14 AM5/22/08
to Hard...@googlegroups.com
It's billions. The health IT world needs to start practicing evidence
based medicine and realize that the opportunity cost of chasing the next
software fad in health systems is measured in lives.

Joseph

> .
>

Roger A. Maduro

unread,
May 22, 2008, 12:14:32 PM5/22/08
to Hard...@googlegroups.com
Chris,

As I said, I've head some extensive discussions with the Clear Health
guys on this. They took at look at CAV Systems' MJSP
<http://mjsp.sourceforge.net/>. This is an open source toolset that
can be used to create rich HTML clients that can run on top of Mumps
applications. MJSP has been used by CAV Systems to create some
beautiful browser-based web apps for Mumps applications. I have seen
these demoed and seen the CAV guys write HTML code for the base Mumps
app on the fly. It's impressive. CAV Systems' code however (for the
web piece) is J2EE. You can read the sourceforge documentation to get
the details.

ClearHealth has been doing all their browser work using PHP. Thus they
either used the MJSP code that connects to Mumps to connect to the RPC
broker or developed similar code using MJSP as the model (I am still
not clear). Then they used PHP to render the web front end. What the
Clear Health people told me is that they have not touched the Mumps
code, so I don't know where that part comes from.

The idea here is to replace the Delphi code behind CPRS with an
Ajax/Web 2.0 framework.

At this point, I would say that David Uhlman or some of the Clear
Health guys will hopefully provide some more details. I think this is
a very significant development and hope that they continue working on
it.

Roger

st...@stevenowen.com

unread,
May 22, 2008, 12:59:11 PM5/22/08
to Hard...@googlegroups.com
I think they are taking the right approach by developing a rich browser
client as the next generation CPRS. That's why I'm putting together a
developer's virtual machine based on M/gateway's Enterprise Web Developer
platform. Write your methods on the mumps side, compile the php pages on
the mumps side, and output them to your webserver. Plus, it has custom tags
to make use of javascript toolkits like extJS.

Yeah, very cool stuff this web 2.0

Chris Richardson

unread,
May 22, 2008, 1:46:42 PM5/22/08
to Hard...@googlegroups.com
Steve;

I'm not at odds at all with rehosting CPRS as a thin client. The
coordination of the clients with the server is a major headache in the
field. The webification of VistA is the logical extension of the
technology, but if you read the statements being made, that was not at all
clear from their words. MUMPS never was to run on the client, but it is
very difficult to run CPRS without VistA and the RPC interface (or weblink
or any of the other technologies being brought forward) on the server.

I can't tell you the number of times I have seen people say, "CPRS is
great, but now if we could just get rid of that darned VistA" without
knowning that the power of the rendition of CPRS or a web interface is still
the VistA-MUMPS back end service. BTW, the idea of running VistA from the
web is not new, Jim Self and his folks at UC Davis have accomplished this
about 15 or more years ago.

Maury Pepper

unread,
May 22, 2008, 2:12:33 PM5/22/08
to Hard...@googlegroups.com
I'm not sure what others have seen. All I could find was this slide show at:
www.clear-health.com/download/tepr-2008.pdf

One slide contains this summary:

● Web Based CPRS
● Possible Web Based ViewCentric
● Proven System, Excellent Record
● Ease of Web Based Systems,
especially over M stack
● End-to-end system with
scheduling and billing
● Inpatient or ambulatory
Compatible with CH Advantage
● M/CACHE to PHP/MySQL & C,
Modern Technology
● Compatible with HealthCloud

I don't know how to interpret the next to last point which refers to M/CACHE.

Roger mentioned CAV Systems and their Java library. They also have a product (not open source) called JUMPS which will convert MUMPS to Java + SQL. Perhaps ClearHealth has used this or considered using it.

st...@stevenowen.com

unread,
May 22, 2008, 2:17:34 PM5/22/08
to Hard...@googlegroups.com
Ah, now I see that Fred mentioned something about re-compling mumps code to
C...that seems a bit odd if they can access the mumps backend via MJSP

david...@gmail.com

unread,
May 22, 2008, 3:27:24 PM5/22/08
to Hardhats
I wanted to weight in here so that there can be some on-record
discussion coming from us directly. I do not in any way want to offer
a general commentary on why some people want to use MUMPS or don't
want to, or X language is better than Y, I am not looking to instigate
a flame war or really say that what we are doing is a better or worse
approach from a technical standpoint than anything else. It is the
right approach for us. Additionally I need to make clear that this is
a preliminary announcement, we have moved beyond proof of concept but
there is still a lot to be done. We now have 2 beta sites we will be
rolling out over the course of the next 12-18 months while actively
seeking 1 or more additional sites.

What we are doing:
*Implementing a CPRS-like web based interface
*Breaking a live VistA server into static libraries and components
that can be utilized outside of a running GT.M instance or at-least a
continuously running instance
*Extracting datasets and so forth tied up in CACHE to be accessible in
other things including MySQL
*Integrating features that based on our market aren't present or are
underrepresented in a VistA/WorldVistA/etc installation with regard to
scheduling and X12 electronic billing.
*Enabling a lot of interfaces and integration points so that both data
and logic, that from our standpoint were difficult to work with in
VistA, are accessible using things like a PHP module and web services.
*The entirety of what we are going will be licensed under a feasible
combination of GPL and LGPL

What we aren't doing:
*Saying the M/Mumps/WorldVistA etc is good, bad or otherwise
*Saying we have a completed production ready system right now
*Saying it is trivial to get from where we are now to a completed
production system
*Building a web based front-end that uses RPC/etc to talk to a VistA
server

With respect to understanding the industry and the history of VistA we
aren't novices here, we are by most measure the largest open source
healthcare solution in patients, sites and dollars in the US. We
understand the engineering challenges. We understand that in the past
people have tried various other strategies and have failed. I am happy
to have fruitful discourse about what we are doing, I am not
interested in having a zealous back and forth about why we should or
shouldn't be doing this. If you disagree with our approach or think we
are crazy for x,y, or z that is absolutely your right and noted for
the record.

With regard to the "doomed to fail" comments, we are not naive and
have been doing complicated difficult things with Open Source with a
combined experience amongst are staff of more than 100 years. People
are welcome to their opinion but I think if you look at the life of
virtually any large open source project today it arose from a
situation where a lot of people said "doomed to fail". Linux, Apache,
MySQL, and PHP as well as many others have all, at times, had that
comment made about them and they now represent the most popular system
for each of their respective markets .

Our analysis of the market indicated that there were a lot of
institutions interested in VistA based solutions that for a variety of
practical reasons had difficulties integrating with the current
architecture, making customizations to the current architecture or
addressing needs in a different way than the current architecture can
reasonably provide for, that is our motivation for doing what we are
doing.

I expect that the first open source licensed code bundle we will be
releasing is still several weeks away. As the discussion indicated
there are a lot of technical challenges to what we are doing and we
want to first release to be reasonably accessible with regard to its
ease in compiling and getting running a basic version of the WebVistA
system. We do have some screenshots and such we will be releasing as
time permits.

I hope this clarify to some extent where we are and I am happy to
response to any inquiries beyond that. Thanks.

-David Uhlman
Customer Happiness Guru & CEO
ClearHealth Inc.

K.S. Bhaskar

unread,
May 22, 2008, 4:16:26 PM5/22/08
to Hardhats
Thanks, David. I am curious about your server side technology. Did
you use Kevin O'Kane's MUMPS to C translator to translate VistA to C?
Anything you can say to explain your server side technology would be
appreciated.

Regards
-- Bhaskar

On May 22, 3:27 pm, daviduhl...@gmail.com wrote:
> I wanted to weight in here so that there can be some on-record
> discussion coming from us directly. I do not in any way want to offer
> a general commentary on why some people want to use MUMPS or don't
> want to, or X language is better than Y, I am not looking to instigate
> a flame war or really say that what we are doing is a better or worse
> approach from a technical standpoint than anything else. It is the
> right approach for us. Additionally I need to make clear that this is
> a preliminary announcement, we have moved beyond proof of concept but
> there is still a lot to be done. We now have 2 beta sites we will be
> rolling out over the course of the next 12-18 months while actively
> seeking 1 or more additional sites.

[KSB] <...snip...>

Jim Self

unread,
May 22, 2008, 10:01:51 PM5/22/08
to Hard...@googlegroups.com
Chris Richardson wrote:
BTW, the idea of running VistA from the
web is not new, Jim Self and his folks at UC Davis have accomplished this
about 15 or more years ago.
  
Thanks for the mention, Chris.
  I think we clearly showed *how* it could be done about that long ago with a web interface to our own system (VMACS, for veterinary medicine) and some general tools and demo applications showing some of the possibilities for general M-to-Web applications, including high-level data to table generation in HTML, Javascript, and later XML.

More recent are some tools for generating and processing AJAX data entry forms tied to Fileman API's and data definitions. There is also an initial implementation of a functional menu interface for the VistA Options file.
-- 

---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Information Technology Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
---------------------------------------
M2Web Demonstration with VistA
(http://vista.vmth.ucdavis.edu/)
---------------------------------------

Jim Self

unread,
May 22, 2008, 10:44:10 PM5/22/08
to Hard...@googlegroups.com
st...@stevenowen.com wrote:
I think they are taking the right approach by developing a rich browser
client as the next generation CPRS.
I agree that development of a web based CPRS replacement would be a good project. I wish I had (more) time to work on it myself. I have a demo of most of the functionality required for building it. (See the links below)

That's why I'm putting together a
developer's virtual machine based on M/gateway's Enterprise Web Developer
platform.   Write your methods on the mumps side, compile the php pages on
the mumps side, and output them to your webserver.
I agree that EWD seems worth investigating. (Sorry, Rob, but I haven't gone very far with that yet. When I last tried, there were some issues with getting the appliance to load in Parallels on my Mac.)

What advantages do you see in generating dynamic HTML, Javascript, etc for VistA from php instead of doing it from mumps?

Or might you be doing both? That might be relatively easy with EWD and/or M2Web?

Plus, it has custom tags
to make use of javascript toolkits like extJS.
  

Please compare extJS with Dojo? (http://dojotoolkit.org) I found a few links from google comparing them but all from before Dojo 1.0.

I built some preliminary M2Web tools a while back for generating and processing Dojo based data entry forms for VistA from Fileman data definitions and API's. These can be used to make applications with very little source code.

Unfortunately the version I started with (Dojo 0.43) lacked some of the functionality I would like to see in a full scale data interface and upgrading to the current version (1.1) requires significant re-learning and re-programming. Their data API's and data enabled widgets have changed greatly between versions.

Yeah, very cool stuff this web 2.0

  
I agree. There seem to be many ways to go about developing it. So much to learn and so little spare time to do it in...

Still there must be some commonality in the different approaches...

If you keep a blog reporting your progress and problems along the way (and/or report it to hardhats) it might help to illuminate the way for you as well as others.

rtweed

unread,
May 23, 2008, 5:08:54 AM5/23/08
to Hardhats
Jim

> I agree that EWD seems worth investigating. (Sorry, Rob, but I haven't
> gone very far with that yet. When I last tried, there were some issues
> with getting the appliance to load in Parallels on my Mac.)

No problem. You might want to try the latest Virtual Appliance. The
network driver it uses seems much more reliable


> What advantages do you see in generating dynamic HTML, Javascript, etc
> for VistA from php instead of doing it from mumps?

The philosophy of EWD is that it doesn't and shouldn't matter where
the actual markup, Javascript etc is being served up from. It
abstracts that away from you so it's largely irrelevant.

The real advantage of EWD is that it makes the task manageable and
scalable. With increasingly complex UI functionality becoming
possible with the latest generations of Javascript-based widgets from
the likes of Yahoo, Dojo, ExtJS etc, the pages you have to serve up
become increasingly complex to write and (critically) to maintain.
That's where EWD's Ajax framework comes in - it simplifies how you
conceptually design your pages, and also where the custom tags come
in, because they can simplify the complex JSON-structured Javascript
coding required for these widgets down to a bunch of simple to use and
simple to understand XML tags. Witness the EWD/ExtJS desktop which
you can get working with just 2 custom tags: see
http://gradvs1.mgateway.com/download/extjs4.0.684.pdf, page 34.

A separate question is whether EWD could be made to work with GT.M
without the need for PHP. The model there would be akin to WebLink
and Cache. That's something I'm currently pondering. However, as
people who use EWD with Cache know, there would be no difference
within your EWD pages: whether and how an EWD application runs with
PHP, CSP, JSP or WebLink is handled by EWD's compiler and makes no
difference to the developer.

>
> Or might you be doing both? That might be relatively easy with EWD
> and/or M2Web?
>
> > Plus, it has custom tags
> > to make use of javascript toolkits like extJS.
>
> Please compare extJS with Dojo? (http://dojotoolkit.org) I found a few
> links from google comparing them but all from before Dojo 1.0.
>

Opinions may vary but my view is that ExtJS has become the leader and
everyone else is now playing catch-up with them. The latest ExtJS
widget library is nothing short of stunning and unbelievably
sophisticated. From what I've seen of the current CPRS interface,
there's not one bit of functionality that couldn't be done using ExtJS
widgets. The problem is that it would involve some very complex use
of the ExtJS widgets, but the good news is that EWD would make it do-
able and maintainable.

I'm afraid that the days of the hacked-together MUMPS routine to
generate web pages are out the window when you're into this level of
UI sophistication. You need a tailor-made toolset to make it
practical, manageable and maintainable and avoid going insane!


> I built some preliminary M2Web tools a while back for generating and
> processing Dojo based data entry forms for VistA from Fileman data
> definitions and API's. These can be used to make applications with very
> little source code.
>

One of the problems is not that any one bit of coding is particularly
complex, it's that if you attempt to emulate something like the CPRS
interface, you end up with so much stuff to write, manage and
maintain. You need automation tools like EWD to allow you to
conceptually simplify the process and allow you to crank out the
pages. And of course you need to maintain state and security, all
stuff done automatically for you by EWD so that burden is relieved
also.

> Unfortunately the version I started with (Dojo 0.43) lacked some of the
> functionality I would like to see in a full scale data interface and
> upgrading to the current version (1.1) requires significant re-learning
> and re-programming. Their data API's and data enabled widgets have
> changed greatly between versions.

I think it's safe to say that the Javascript widget world is advancing
at a blistering pace. One more reason for custom tags: to abstract
the physical implementation so the underlying code can be kept up to
date with the widget libraries whilst their use in your pages can
remain relatively constant.


> Yeah, very cool stuff this web 2.0
>
> I agree. There seem to be many ways to go about developing it. So much
> to learn and so little spare time to do it in...


...so anything that can make lighter work of it has got to be a good
idea, right?


>
> Still there must be some commonality in the different approaches...
>

> If you keep a blog reporting your progress and problems along the way
> (and/or report it to hardhats) it might help to illuminate the way for
> you as well as others.

I know that Steve is doing some great pioneering work with EWD, ExtJS
and Vista, so I too am looking forward to what he'll be able to
demonstrate in the hopefully not too distant future

Rob

Fred Trotter

unread,
May 23, 2008, 4:45:52 PM5/23/08
to Hard...@googlegroups.com
Chris,
Remember that this is completely second hand information.
I have neither seen the code, the process, nor the interface. I am
just parroting what was said in the talk at TEPR and I could easily be
wrong. I think it is pretty relevant that Roger has been talking to
the same people and has a very different technical summary. I would
assume that my 10000 foot summary turns out to be pretty off base. The
only reason I indicated that it was not just a CPRS replacement was
that I understand that David either has the pharmacy stuff working or
believes that he will be able to get it working.

As with anyone who has even a passing familiarlity with
MUMPS, I appropriately dubious. However I have seen David do some
amazing things with PHP, and I while he may sometimes be
overconfident, I have never known him to completely BS. So I am very
interested to see what they have. I just wanted you to know that I do
not actually know what they have... so make sure you do not rely on my
understanding too much.

On Thu, May 22, 2008 at 9:37 AM, Chris Richardson <r...@rcresearch.us> wrote:
>
> Roger;
>
> That is not what they said. They said " a web-based version of VistA
> working without MUMPS" and "the strategy is to compile the MUMPS code to C,
> run it through some extensive processing, and then it becomes available in a
> fashion that can be called from php." I believe that both GTM and Cache can
> work with PHP just fine without having to be converted to "C". I would love
> to see their data model and watch their performance stats. I have a pretty
> good idea what those will look like. If they wanted to say that they were
> just replacing CPRS, then they should say so. If they didn't replace CPRS,
> they could still claim that CPRS runs without MUMPS right now (as long as
> you don't expect any data to come with it). If I am not mistaken, GT.M is
> already written in "C" or some other compiler and pretty well optimized for
> the data handling model. Re-inventing MUMPS in C would be a trick, getting
> scalability and performance would be a miracle. Say you could (by some
> miracle), what would you be loosing? Access to the source code (it is all a
> black box and the end user is kept at arms length from verifying the
> operation of the code). The user is at the mercy of the vendor once again.
> Is this a good thing? I don't think so. Where is the good here?
>
> Interesting, but is it really necessary? What is wrong with MUMPS? I
> have heard of such efforts to replace MUMPS for over 20 years. If all of
> this effort to replace MUMPS was so easy, it would have been done already.
> It isn't a matter of money, the DoD and the VA have spent gobs of money to
> replace it. What is keeping them?
>
>

--
Fred Trotter
http://www.fredtrotter.com

George Timson

unread,
May 23, 2008, 5:16:00 PM5/23/08
to Hardhats
One of the challenges in replacing a MUMPS system is that MUMPS code
writes more MUMPS code and XECUTEs it on the fly. MUMPS really is the
"X language", to use Mr. Uhlman 's term. :-)

FileMan uses XECUTE all over the place. To be able to run a FileMan
report "outside a continuously running instance", how would the XECUTE
command be handled?

--George Timson

Chris Richardson

unread,
May 23, 2008, 11:23:35 PM5/23/08
to Hard...@googlegroups.com
Fred;

I am not trying to shoot the messenger, just find out where the reality
ends and the FUD begins. Yes, this is interesting work, and I have seen
many attempts at replacing MUMPS with compiled code on multiple occassions,
but why? Why is there all of this effort to replace one tool which was way
ahead of its time? Does VistA need to be re-writen, sure, but why not use
what we have and what works rather than build a compiled monstrosity that
you may or may not get the source code for. Where is the advantage? Lets
use what works, has worked, and has proven to be scalable beyond many of the
other environments that are being proped up to try to replace it, and only
coming in a poor second in nearly every case. I have seen no other system
out there that can hold and manage more than 30 years of patient history
like VistA can (the major exception is Octo Barnetts' model at Beth Israel
Hospital in Boston, but that is a MUMPS model as well. MUMPS must be doing
something right.


----- Original Message -----
From: "Fred Trotter" <fred.t...@gmail.com>
To: <Hard...@googlegroups.com>
Sent: Friday, May 23, 2008 1:45 PM
Subject: [Hardhats] Re: ClearHealth project compiles VistA to MUMPS-LESS web
interface.


>

Aylesworth, Marc CTR USAF AFMC AFRL/RISE

unread,
May 27, 2008, 9:20:21 AM5/27/08
to Hard...@googlegroups.com
Doesn't GTM compile Mumps down to .o files and then only check to make sure the source is older than the compiled code to make it faster.

Marc Aylesworth

RRC C3I Grooup
525 Brooks Road
Rome, NY 13440
PH: 315-330-2422

________________________________

http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105

Interesting times :)

-FT
--
Fred Trotter
http://www.fredtrotter.com <http://www.fredtrotter.com/>


winmail.dat

Maury Pepper

unread,
May 27, 2008, 10:33:20 AM5/27/08
to Hard...@googlegroups.com
Yes, but it dynamically invokes the compiler for any indirection or Xecute. It is not "MUMPS-LESS". (BTW, Cache, DSM and MSM all compile the source into p-code and the resulting execution is not much different than GT.M's threaded code.)

kdt...@gmail.com

unread,
May 27, 2008, 12:46:37 PM5/27/08
to Hardhats
Seems like there is already program that takes M code and converts it
to standard object files, and is callable by php.

It's called GTM.

Kevin

Fred Trotter

unread,
May 27, 2008, 2:13:39 PM5/27/08
to Hard...@googlegroups.com
I looked into that code briefly, but it does not work with php 5

Generally that makes it a non-starter.

kdt...@gmail.com

unread,
May 27, 2008, 6:07:57 PM5/27/08
to Hardhats
I guess I should let Bhaskar comment, but GTM has an interface for
call in from other languages. For example, someone has written an
interface form perl to GTM. So if php 5 is not able to connect to
another program written in c that has predefined channels for such a
connection (such as GTM), then I would see that as a limitation of
php.

I suspect that it is doable, but there just hasn't been a need for it,
so the channel has not yet been created.

Kevin

kdt...@gmail.com

unread,
May 27, 2008, 6:12:09 PM5/27/08
to Hardhats

kdt...@gmail.com

unread,
May 27, 2008, 6:24:49 PM5/27/08
to Hardhats
This has perked my interest (read: more fun to research this than to
finish office charts...)

According to this link:
http://www.php.net/manual/en/intro.pdo.php
There would need to be a database driver written for GT.M

This is a list of databases already having a driver established.

The following drivers currently implement the PDO interface:
Driver name Supported databases
PDO_DBLIB FreeTDS / Microsoft SQL Server / Sybase
PDO_FIREBIRD Firebird/Interbase 6
PDO_IBM IBM DB2
PDO_INFORMIX IBM Informix Dynamic Server
PDO_MYSQL MySQL 3.x/4.x/5.x
PDO_OCI Oracle Call Interface
PDO_ODBC ODBC v3 (IBM DB2, unixODBC and win32 ODBC)
PDO_PGSQL PostgreSQL
PDO_SQLITE SQLite 3 and SQLite 2

So a connection is theoretically possible, but not currently ready to
go. I would guess that the interface would need to talk SQL, so one
would have to include a GT.M SQL engine as well....

Sigh, it's hard when it seems that 98% of the rest of the world talks
a different language...

Kevin




On May 27, 6:07 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:

rtweed

unread,
May 27, 2008, 6:42:32 PM5/27/08
to Hardhats
Our MGWSI gateway (http://gradvs1.mgateway.com/main/index.html?
path=mgwsiMenu) provides a connection between GT.M and:

- PHP (all versions)
- Java Server Pages
- ASP.Net

Our latest version, due for release soon, adds Python and Ruby to the
list.

In all cases MGWSI allows you to access a GT.M system from within any
of these environments, to access and manipulate globals and/or to
invoke routines/functions and send/receive data.

It's free too!

Rob

kdt...@gmail.com

unread,
May 27, 2008, 7:23:06 PM5/27/08
to Hardhats
Wow! That's great!

Does it doe the interface via one of the PDO type drivers mentioned in
my prior post? Can you elaborate a bit on the technology? How is it
set up? I don't operate much in PHP etc, so don't know the details.

I guess with this the LAMP stack could be:
L - Linux
A - Apache
M - MUMPS :-)
P - PHP

Kevin

edsalvador

unread,
May 27, 2008, 9:11:05 PM5/27/08
to Hardhats
I do not think this is a matter of learning a new programming
language.
I think it is a matter of Vista gaining traction in the physician
practice community. You can knock the current commercial EMR
applications all you want, however, they have anywhere from hundreds
to thousands of users.
How many does Vista have? What is being done by WorldVista to gain
market share?
When you can solve this issue, the point will be moot.

Ed

On May 21, 10:33 pm, Joseph Dal Molin <dalmo...@e-cology.ca> wrote:
> ....what some people will do to avoid learning a new programing language
> is simply awe inspiring :-)
>
> J
>
>
>
> Fred Trotter wrote:
> > Today at TEPR, ClearHealth announced that they have a web-based
> > version of VistA working without MUMPS.
>
> > Apparently the strategy is to compile the MUMPS code to C, run it
> > through some extensive processing, and then it becomes available in a
> > fashion that can be called from php.
>
> > They are currently in beta in one hospital with this technology.
>
> > I know very little about it so I cannot field questions. For those who
> > are very interested, take a look at this post on the ClearHealth
> > forums:
>
> >http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
>
> > I am sure they might field questions from you on that same forum.
>
> > Interesting times :)
>
> > -FT- Hide quoted text -
>
> - Show quoted text -

K.S. Bhaskar

unread,
May 27, 2008, 9:44:35 PM5/27/08
to Hardhats
If you really want a PHP 5 interface to GT.M, Fred, I'm curious why
porting a few older PHP modules to PHP 5 is a show-stopping obstacle?
I know people who saw how small http://downloads.sourceforge.net/fis-gtm/phpgtcm.tar.gz
is, read it and then wrote their own Java interface to GT.M.

In any case, you can also use PIP (http://www.fis-pip.com &
http://sourceforge.net/projects/pip) to get FOSS JDBC/SQL access to an
M/Fileman database, but that may be more work.

Also, as Rob points out, the M Gateway code (which is really cool)
provides another great free (don't know if it is Free) way to access M/
Fileman data.

I fully understand if you are stymied by lack of interest - let's not
forget that MUMPS is infectious! 8-)- - lack of funding, lack of
enthusiasm, etc., but you shouldn't be stymied by a lack of
technology.

Regards
-- Bhaskar

K.S. Bhaskar

unread,
May 27, 2008, 9:56:24 PM5/27/08
to Hardhats
Good point, Ed.

For the last three months WorldVistA EHR has been downloaded from
Source Forge at the rate of around 1400 downloads/month and last week
was at 98.38 percentile of all projects by activity at Source Forge.
The WorldVistA project (mostly FOIA VistA flavors) was at 96.83
percentile last week and has been averaging around 700 downloads/month
for the last three months.

GT.M (independent of activity and downloads bundled with VistA) was at
98.73 percentile last week, and has been averaging 600 downloads/month
over the last three months.

So, you're probably right - it's a dying application on a technology
that's about to go belly up. Time to move on to something else...
any decade now.

-- Bhaskar

Fred Trotter

unread,
May 27, 2008, 9:56:49 PM5/27/08
to Hard...@googlegroups.com
If I had the bandwidth to work on something here, it would be a python
to GTM bridge. From what I can tell python has many of the same
web-enabled benefits of php, with stricter OOP.

Again, it is really an issue of what is doable and what I personally
have the bandwidth for.

edsalvador

unread,
May 27, 2008, 11:32:35 PM5/27/08
to Hardhats
Bhaskar,
Download stats are meaningless unless physicians actually use the
application.
Where are the real-world stats?

Ed

I agree that the applications has potential.
However, like someone told me:
Sh*t in one hand and wish in the other. See which one gets filled-up
faster.
> > Ed- Hide quoted text -

rtweed

unread,
May 28, 2008, 2:49:25 AM5/28/08
to Hardhats
Most people use MGWSI behind the scenes when using Enterprise Web
Developer (EWD) (http://www.mgateway.com/ewd.htm). MGWSI is the key
underlying reason why EWD can potentially cross-compile to PHP or
potentially any other web technology: MGWSI provides a normalised way
of accessing GT.M (or Cache) from them all.

You can use MGWSI manually however if you really want to hand-craft
your PHP, Python or whatever (personally I no longer see the point
doing this any more as EWD automates the whole process and avoids me
having to write any PHP or whatever code).

MGWSI is a general-purpoose service that mediates between two systems,
one deemed to be the server (in this case GT.M) and the other the
client (eg PHP, JSP etc). The endpoints may be on the same or
separate hardware: provided they can communicate via TCP/IP, then
MGWSI will integrate them. One instance of MGWSI can support access
to multiple GT.M and/or Cache servers from a client environment,
allowing it to support distributed back-end data or heterogeneous
database access.

All the documentation for MGWSI is included in the downloadable zip
file from our web site (www.mgateway.com), but here's a few examples
which will perhaps help to explain how you use it.

PHP:

$result = m_proc("myFunc^myRoutine", $ar2, "London");

Invokes a call from within PHP to GT.M, the equivalent of s result=$
$myFunc^myRoutine(.ar2,"London")

where ar2 is an array. Arrays are mapped automatically between PHP's
associative arrays and M's local arrays. GT.M may update the array if
required and send back new content.


Various low-level primitive global calls, eg:

m_set("^MGWCust", 1, "Rob Tweed");
m_set("^MGWCust", 2, "John Smith");

from within PHP would create:

^MGWCust(1)="Rob Tweed"
^MGWCust(2)="John Smith"


Java Server Pages equivalent to the above (ie calls from within JSP
pages):

m_jsp.ma_arg_set_array (args, 1, records, 1); // pass-by-
reference.
m_jsp.ma_arg_set_string(args, 2, "London", 0);
m_jsp.ma_proc("myFunc^myRoutine", args, 2)


key[0] = "1"; // no of subscripts
key[1] = "1"; // value of subscript 1
m_jsp.ma_set("^MGWCust", key, "Rob Tweed");
key[1] = "2";
m_jsp.ma_set("^MGWCust", key, "John Smith");


All the other language interfaces work similarly to either the JSP or
PHP ones. You have functions for:

- setting globals
- killling globals
- traversing globals ($order equivalent)
- merging to/from globals or local arrays
- invoking routines (+ sending/receiving data)
- invoking functions (+ sending/receiving data)


MGWSI is deliberately kept very simple and straightforward, but allows
complete flexibility. The great thing about MGWSI is that it allows
you to invoke legacy functions from within any of the supported web
technologies/languages, making it idea for interfacing with existing
Vista business logic.

If you want to see MGWSI in action, the simplest approach is to
download our EWD Virtual Appliance which includes MGWSI pre-installed
and pre-configured in a VMWare Virtual Machine based on Linux/PHP/
Apache/GT.M. Most of the time in the Virtual Appliance you won't even
be aware it's there, since it's providing the gateway between GT.M and
EWD-generated PHP applications.

You'll also be using MGWSI if you download the Asus Eee kit for EWD
which I described in a recent post here and which Steve Owen has been
using.

For more information,. download MGWSI and consult the documentation.
All our products are free to download and use without restriction and
can be obtained from http://www.mgateway.com

Rob

rtweed

unread,
May 28, 2008, 3:06:49 AM5/28/08
to Hardhats
Personally I'd prefer to neither know nor care what language/web
technology I was using when front-ending a GT.M application, provided
it runs fast and scales well.

That's the idea of our Enterprise Web Developer (EWD) technology which
allows you to describe your web applications in a high-level
abstracted way that makes it appear as if you're just designing a
storyboard of web pages with calls to GT.M functions to fetch the data
for each page and validate/save data coming off the page. EWD then
generates the language/web technology of your choice, so if you want
to run your application using PHP, just compile to PHP and EWD writes
all the PHP code for you. Once I've integrated the new MGWSI build
that supports Python, you'll be able to select Python as the
compilation target and EWD will generate Python code instead from the
original application: the application will run identically in either
PHP or Python without you making any changes to the EWD application
definition.

I have versions of demo applications written using EWD that will run,
simultaneously if required, in any or all of PHP, VB.Net and JSP all
against the same back-end GT.M database.

When you have technology that allows you to do that, it really is
pretty much irrelevant whether you choose Python or PHP. Since all
the PHP, Python, JSP etc code is 100% generated, whether the target
language is an OO one or not is neither here nor there. All you need
to focus on is the page/UI design and the back-end function calls you
need to make to access the back-end GT.M functions which fetch and
update your database. Want to see how/if your application would
perform and scale better in a PHP, Python or JSP environment? Just
recompile and give it a go: it really is as simple as that once you're
writing apps using EWD.

Available bandwidth is what it's all about, as you say. Making you
more productive is what EWD is all about, and avoiding having to grub
around at the low level in PHP, JSP, Python or whatever code is one of
the keys to achieving that productivity.

Rob

K.S. Bhaskar

unread,
May 28, 2008, 7:13:16 AM5/28/08
to Hardhats
I think there are an increasing number of clinics and hospitals that
are starting VistA implementations. I don't disagree with you that
the installed base is small (unless you count the dozens of secondary
and tertiary care hospitals where VistA is implemented at Instituto
Mexicano del Seguro Social). But the number of new implementation
projects seems large, and growing, as evidenced, for example by
attendance at VistA Community Meetings.

Regards
-- Bhaskar

Fred Trotter

unread,
May 28, 2008, 10:33:21 AM5/28/08
to Hard...@googlegroups.com
> $result = m_proc("myFunc^myRoutine", $ar2, "London");
> m_set("^MGWCust", 1, "Rob Tweed");

This is, in my view, exactly what is needed for php <-> GTM
integration and could be a real game-changer. However there is a
licensing issue. I see no sourcecode download from your site, and I
see no mention of a specific license. I am also unsure of how you can
create a php module that links into GTM without complying with the GPL
license that GTM (linux version) comes with.

What is the license of your code. Would you consider releasing it under the GPL?

rtweed

unread,
May 28, 2008, 10:52:19 AM5/28/08
to Hardhats
Our licensing is not currently Open Source, though we are actively
considering going down that route.

We don't release source code for the core MGWSI service component.
The GT.M-side listener/daemon code is provided as source code however,
so I see no conflict with GT.M licensing in that respect.

Our licensing is very liberal. We allow you to use EWD and MGWSI
freely to whatever extent you like, and you can redistribute it as you
wish. The only limitation is that our products are provided without
support.

MGWSI is now the standard PHP integration gateway in the Cache
community and is in use by a large number of users, and it would be
good to see similar uptake in the GT.M community.

K.S. Bhaskar

unread,
May 28, 2008, 11:58:15 AM5/28/08
to Hardhats
Fred --

The PHP client talks over a TCP connection to a GT.CM server process
that is part of GT.M. None of GPL v2, GPL v3 or AGPL v3 have any
clause that causes any license interaction between a client and a
server that are on two sides of a TCP connection.

From a 2003 forum post by some guy called Bhaskar:

"Should you wish to use GT.M as a database engine, please be assured
that Sanchez does not place any restriction on the licensing or
publication of source code for applications developed using GT.M. I
have clarified this previously in comp.lang.mumps and other forums.
If, on the other hand, you make changes to GT.M itself and distribute
the modified version of GT.M, I would expect you to make source code
for your changes available under the terms of the GPL."

From GPL v3 and AGPL v3:

"A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate."

There is no interaction between the licensing of application code that
runs on GT.M with the FOSS licensing used for GT.M itself.

Regards
-- Bhaskar

Fred Trotter

unread,
May 28, 2008, 12:04:30 PM5/28/08
to Hard...@googlegroups.com
On Wed, May 28, 2008 at 9:52 AM, rtweed <rob....@gmail.com> wrote:
>
> Our licensing is not currently Open Source, though we are actively
> considering going down that route.
>
>
> Our licensing is very liberal.

It seems like going open source is a pretty obvious choice for you.
The "GTM community" are attracted to GTM because of its license. Using
GTM, GNU/Linux and either WorldVistA or, now Medsphere OpenVistA, we
can have a complete FOSS stack. There is no way that we would consider
working with a project that messes that up. So if you are actually
interested in serious adoption by that part of the VistA commuity, it
will not happen without a license change.

This is true for many software companies, including Intersystems and
DSS. The difference is that I do not see how you are making any money
from your software. You are already doing a services model, so I do
not see how you would be impacted by this negatively at all.

If you release your code you stand to become a central component in
the "webifcation of VistA" effort. As the ClearHealth efforts
demonstrate, that is going to happen one way or another. The only
question is with what particular solution?

There is also no reason that you would need to open source everything.
You could keep your cache module proprietary. GTM actually does this
with its non-Linux binaries, (or it used to) and that is totally
legit.

Fred Trotter

unread,
May 28, 2008, 12:29:01 PM5/28/08
to Hard...@googlegroups.com
Bhaskar,
Actually the AGPL v3 is designed to close this "ASP
Loophole" but I know that you are still using the GPL.

I just did not understand what architecture they were
using. They are quite right to do it the way they are doing it, but
they really are leveraging the ASP loophole alot. They are actually
doing the integration with GTM, in a GPL script, that exposes a TCP/IP
interface to the same calls. In fact this design is the reason the
AGPL was created.

-FT

--
Fred Trotter
http://www.fredtrotter.com

K.S. Bhaskar

unread,
May 28, 2008, 1:02:33 PM5/28/08
to Hardhats
On May 28, 12:04 pm, "Fred Trotter" <fred.trot...@gmail.com> wrote:

[KSB] <...snip...>

> There is also no reason that you would need to open source everything.
> You could keep your cache module proprietary. GTM actually does this
> with its non-Linux binaries, (or it used to) and that is totally
> legit.

[KSB] To clarify: GT.M on several platforms - IBM pServer AIX, Sun
SPARC Solaris, HP Itanium HP-UX & Linux, and HP PA-RISC HP-UX *is not*
FOSS. It is available on reasonably priced traditional user based
software licenses. GT.M on x86/x86_64 Linux, HP Alpha/AXP OpenVMS and
Tru64 UNIX *is* FOSS - currently GPL v3 & going to AGPL v3.

There is a wrinkle on GT.M for x86_64 Linux - the source code is
released (the same tarball can be used to build for x86 32-bits and
x86_64 64-bits). However, while the 32-bit binaries are freely
available at Source Forge, 64-bit binaries that we build, test and
support are provided by us only to customers with support contracts.
Anyone who wants 64-bit binaries but doesn't want a support contract,
will need to compile from source.

Regards
-- Bhaskar

rtweed

unread,
May 28, 2008, 1:26:02 PM5/28/08
to Hardhats
Let me explain the MGWSI architecture in some more detail because it
sounds like there are some misconceptions.

The GT.M-side code is simply bog-standard MUMPS code that OPENs, USEs
and CLOSEs standard ports - nothing really different from any MUMPS
application code that anyone might feel free to write on a GT.M
system.

All the action really takes place in the MGWSI service component which
is a quite separate module/process and nothing to do with GT.M (or any
other server) at all. The MGWSI service component looks after the
management of TCP socket connections to the server(s), distribution of
requests across available connections, opening new connections on
demand if required, closing them down if required. It contains all the
configuration, logging and error reporting functionality.

What is at the other (client) side of the MGWSI service is actually
unknown and irrelevant to a GT.M server. PHP, JSP, ASP.Net, etc
communicate with the client interface of the MGWSI service. MGWSI
acts as a mediator between the two endpoints and normalises their
behaviour as far as the GT.M (or other server) is concerned. The GT.M-
side code neither knows nor cares whether the client request
originated from PHP, Java, some ASP.Net language, Python, Ruby or
whatever: the requests all look the same to it and what it sends back
to the MGWSI service component is always the same irrespective of the
client technology. So a GT.M system could, if you wanted, be
integrated simultaneously with client front-ends running in PHP, Ruby,
Java, etc etc and it would quite happily interoperate with the lot.

Indeed MGWSI is actually designed to be a totally general-purpose
mediator capable of pretty much linking anything to anything. Some
folks are even using it to integrate legacy DSM applications with
WebSphere MQ.

Hope this helps

Rob

K.S. Bhaskar

unread,
May 28, 2008, 3:04:51 PM5/28/08
to Hardhats
Fred --

I think perhaps you misunderstand AGPL v3. Quoting from section 13:

"... if you modify the Program, your modified version must prominently
offer all users interacting with it remotely through a computer
network (if your version supports such interaction) an opportunity to
receive the Corresponding Source of your version by providing access
to the Corresponding Source from a network server at no charge,
through some standard or customary means of facilitating copying of
software."

So, if someone is serving an application with a modified GT.M over a
TCP connection, AGPL v3 would oblige them to make available the source
code to their modifications. However, there is no obligation to make
available what is on the other side of the connection, i.e., the
process talking to the modified GT.M over TCP. The loophole in GPL v3
that AGPL v3 fixes is that GPL v3 would allow the use of the modified
GT.M in this "ASP" environment without an obligation to make the
source code available.

Regards
-- Bhaskar

Fred Trotter

unread,
May 28, 2008, 5:29:23 PM5/28/08
to Hard...@googlegroups.com
You are right... it does not apply to RPC type services....

-FT

--
Fred Trotter
http://www.fredtrotter.com

kdt...@gmail.com

unread,
May 28, 2008, 11:00:49 PM5/28/08
to Hardhats
Fred, you initially seemed concerned that you couldn't program in php
and utilize mumps. I am surprised that you are not reacting more
about a new-found ability. I am seeing much more written about
licensing here than coding ability. The php <--> GTM on the web site
says that this is a FREE download. Are you worried that it is a trap
of some sort? Are you looking a gift-horse in the mouth?

Kevin


On May 28, 10:33 am, "Fred Trotter" <fred.trot...@gmail.com> wrote:

Fred Trotter

unread,
May 29, 2008, 2:02:28 AM5/29/08
to Hard...@googlegroups.com
I am not willing to spend time or energy on "costless" projects. My
time is not costless. I will invest it only in projects that offes to
share ownership with me.

If Bhaskar decided to only allow GPL GTM downloads with "club
memberships" that cost $100 a year, I would still consider it a better
investment to spend two months learning MUMPS, and pay for GTM to get
GPL code.

That still seems like a better investment than spending 0 dollars and
10 minutes looking at a free download.

I write a website about just this issue GPLMedicine.org

In answer to your question: I always look at Trojan horses "in the
mouth" < because mixing metaphors is fun :)

-FT

--
Fred Trotter
http://www.fredtrotter.com

rtweed

unread,
May 29, 2008, 3:28:47 AM5/29/08
to Hardhats
Sounds like yet more misconceptions that need to be clarified. Boy
it's hard to even give stuff away these days without people being
suspicious. Timeo Daneos et donna ferentis.

We only make our money from support and consulting, not directly from
our software. Although my time is not costless either, I've
nevertheless invested a huge amount of it into creating sufficient
documentation, examples, self-training information, pre-built virtual
appliances etc into making it possible for someone who is willing to
invest a small amount of their time to be able to use our products
without any further direct assistance from us.

Purchasing support or consulting from us is not a requirement of using
our products - nowhere is that stated or implied on our web site.
Purchasing support and consulting from us is simply an option. We
work on the basis that ultimately a proportion of our user base will
eventually require the very high quality and responsive support and
consulting advice for which we're renowned and upon which we've built
our business and reputation. Our business model works and we make
what I believe to be an extremely honest living by supporting those
who ask us to support them. If someone uses our products and never
contacts us, our attitude is good luck to you and we're glad if our
software's made a difference.

The only difference between our commercial model and open source is
that we currently choose not to make our core source code available
(though lots of peripheral stuff is), the reason being simply to
protect our core intellectual property.

Anyway, tried and tested enterprise-grade GT.M integration with PHP,
Java, ASP.Net, Python and Ruby is there if you want it for free.

No such thing as a free lunch, or willing to look a gift horse in the
mouth? The choice, in the end, is yours to make.....but of course it
won't cost anything to find out which it is :-)

rtweed

unread,
May 29, 2008, 4:14:15 AM5/29/08
to Hardhats
..and my old Latin teacher will, no doubt, be turning in his grave at
my terrible spelling which should, of course, have been:

"timeo Danaos et dona ferentes"

K.S. Bhaskar

unread,
May 29, 2008, 7:46:26 AM5/29/08
to Hardhats
On May 28, 11:00 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
> Fred, you initially seemed concerned that you couldn't program in php
> and utilize mumps.  I am surprised that you are not reacting more
> about a new-found ability.  I am seeing much more written about
> licensing here than coding ability.  The php <--> GTM on the web site
> says that this is a FREE download.  Are you worried that it is a trap
> of some sort?  Are you looking a gift-horse in the mouth?

[KSB] For clarity, the PHP client is a BSD style license, which is far
more permissive than a GPL. For years, the Windows NT (and maybe
2000) TCP stack was actually FOSS code that Microsoft used in a non-
FOSS product.

Regards
-- Bhaskar

K.S. Bhaskar

unread,
May 29, 2008, 9:40:13 AM5/29/08
to Hardhats
[KSB2] That was inadequate clarity. I meant that the Windows NT TCP
stack was code used under a BSD (Berkeley Software Distribution)
license which is permissive enough to allow FOSS code to be
incorporated into a non-FOSS application. The GT.M PHP client is
available under a BSD style license (it is a BSD license only when it
comes from UCB, otherwise it's a Berkeley style license) to allow the
code to be used by FOSS and non-FOSS applications when accessing a
GT.M database.

-- Bhaskar

Fred Trotter

unread,
May 29, 2008, 11:14:01 AM5/29/08
to Hard...@googlegroups.com
On Thu, May 29, 2008 at 2:28 AM, rtweed <rob....@gmail.com> wrote:
>
> Sounds like yet more misconceptions that need to be clarified.

Nope. I just disagree with you.


> Boy
> it's hard to even give stuff away these days without people being
> suspicious. Timeo Daneos et donna ferentis.

I enjoy communities that regularly quote latin. :)

>
> We only make our money from support and consulting, not directly from
> our software. Although my time is not costless either, I've
> nevertheless invested a huge amount of it into creating sufficient
> documentation, examples, self-training information, pre-built virtual
> appliances etc into making it possible for someone who is willing to
> invest a small amount of their time to be able to use our products
> without any further direct assistance from us.


So far so good.


>
> Purchasing support or consulting from us is not a requirement of using
> our products - nowhere is that stated or implied on our web site.
> Purchasing support and consulting from us is simply an option.

I have no problem with you getting paid. So my concern is not, and
will never be, that you make money on the deal. Unless you making
money by trapping people with your software.
I have suggested to Bhaskar many times before that he should be more
aggressive about the "freeloader" problem. I am pleased to see the
32/64 bit divide, that is a great line in the sand for paid/unpaid
support.

Someday I will write an article about this too, but people who
download and use software for free, without contributing anything
back, I feel are little more than leeches on the community.

> We
> work on the basis that ultimately a proportion of our user base will
> eventually require the very high quality and responsive support and
> consulting advice for which we're renowned and upon which we've built
> our business and reputation.

Or they will require a change to your software. A change that only you
can make because only you have the sourcecode. This is the problem.
Your business model is support *but only you can provide it*. So this
is about control. You have it. Your users do not.

> Our business model works and we make
> what I believe to be an extremely honest living by supporting those
> who ask us to support them.

Alot of people take my criticism as an attack on them personally,
which is unfortunate. I am really trying to talk about the problems
with the model itself.
Consider a Casino. The manager is an honest hard working guy. He works
his shift and takes home the "bacon" to his wife and kids. I do not
have a problem with him.
The Casino itself is also "honest". They tell you what your odds are
upfront. So you know that if you put a dollar in you know that you are
going to get 60 cents (or whatever) back.

But just because everyone involved is honest, does not mean that the
fundamental business is morally OK. I am obviously not interested in
getting into a debate about casinos, or whether gambling is immoral,
but rather to note that there are other industries where "the morals
around the model" are the debate, rather than the morals of a
particular person in the model.

The moral issue in gambling is that our brains are poorly wired to do
the math that makes it apparent that gambling is typically a bad idea.

The moral issue here is that software, especially medical software,
always needs to be changed. Only a proprietary vendor can change the
software. Because you are an honest hardworking guy, there is no
change in your foreseeable future that would cause you fall down on
the job and not make a change that was required. But then, no one
really "forsees" their own death, or the bankruptcy/buyout of the
company that they worked to build. Further, these events WILL happen.
When they do, those relying on your software will not be able to make
the changes they require. In other industries, the resulting migration
is measures in dollars and cents. In medical software, the resulting
migration could be paid with human suffering.

> If someone uses our products and never
> contacts us, our attitude is good luck to you and we're glad if our
> software's made a difference.

You should add:
"But if you ever need changes, we are the only people who can do that for you."

>
> The only difference between our commercial model and open source is
> that we currently choose not to make our core source code available
> (though lots of peripheral stuff is), the reason being simply to
> protect our core intellectual property.

"intellectual property" is largely meaningless to those on this list
with my bent. Copyrights do not work like trademarks, trademarks do
not work like patents, and none of the tree work like "property" in
the real world. For instance, if I give you a shovel or a house, you,
and only you can "own" that house or shovel.

When you say intellectual property you are actually making an
implication that even though nothing "intellectual" works anything
like anything "property" you should be able to make arrangements to
control the scarcity of that resource, as though it were "property".
Of course after making this clever shift of focus, then you can easily
then argue that it needs "protecting", the same way that locks and
alarms protect our homes and cars. The problem is that this
"protection" means that your users lose software freedom.

>
> Anyway, tried and tested enterprise-grade GT.M integration with PHP,
> Java, ASP.Net, Python and Ruby is there if you want it for free.

free as in costless. Not as in freedom.


>
> No such thing as a free lunch, or willing to look a gift horse in the
> mouth? The choice, in the end, is yours to make.....but of course it
> won't cost anything to find out which it is :-)

I already know what it is and so does everyone else. What we disagree
about is the appropriateness of the deal.
Just as some people think Casinos are immoral, I think your whole
model is immoral. (Not you mind you, but your model)

Your software quality is probably good. You do sound like you know
what you are talking about.
However, you are offering a costless option that restricts users freedom.

Thankfully people like me have a much better option than giving up our
freedom. We can work or wait.

I am not going to work on this (I am working on other relevant stuff
however) but thankfully, someone else who agrees with me eventually
will.
When they do, people will be able to choose between your solution,
(good software, costless use, proprietary license) and a
free-as-in-freedom
option (good software, costless use, FOSS license). Which one would you choose?

It does not really matter if you agree with me or not.
My way wins in the end because of economics anyway.

Skip Ormsby

unread,
May 29, 2008, 11:34:09 AM5/29/08
to Hard...@googlegroups.com
Fred, I think I would think about rephrasing this quote:


"Someday I will write an article about this too, but people who
download and use software for free, without contributing anything
back, I feel are little more than leeches on the community."

I down load and use *For Free* Real Player, Quick Time, Java, FoxIt, etc. and there ain't no way can contribute to the code or is there a Contribute button, therefore I am a leech.  Kinda of rude to say the least.
-skip
Montani Semper Liberi

Fred Trotter

unread,
May 29, 2008, 11:53:25 AM5/29/08
to Hard...@googlegroups.com
I disagree with you. There is a way to contribute. It is just not apparent.

I will try to fix this soon however...

watch this space.

-FT

--
Fred Trotter
http://www.fredtrotter.com

Gaber, Roy G.

unread,
May 29, 2008, 12:18:11 PM5/29/08