| I am about to personally evaluate the GPL-based EMR softwares and would like to offer the following thoughts on the matter:
Separate code for achieving the same goal does involve some duplication of effort, but it is not necessarily bad. It results in evolution through competition, and the fittest code will do better.
Excessive, pointless duplication of effort is naturally throttled by GPL. If there is a code that has a significantly much better way of doing things, the nature of GPL allows the people developing other codes to bring it into these other codes. This is one of the strengths of GPL - it tends to avoid excessive, pointless duplication, and speeds up code development.
If there is a bit of code that is horrible spaghetti, but the result is good, someone will rewrite the code to get the same result. A style manual (loose and informal at first anyway) tends to help. The better-written code will tend to do better.
If a code patch is hard to get in (due to bad code management - think of the X11free saga), the whole code will tend to fork and the fork with the best manager will tend to do better.
If the whole code stays too hard to install and run, and it remains like that for too long after the initial development phase, then it will fall behind others in the field in popularity, and will not be viable in the long term.
Consolidating efforts between various codes at any stage is always possible, but the effort depends on the kind of consolidation is being done. UI changes done in the style of the remarkable gimpshop - gimp with a photoshop-style interface - are relatively easy. So are emacs-like-key-bindings in vi. On the other hand, architecture-based and design-based consolidation is vastly harder and would lead to unproductive religious wars (emacs and vi again).
When I view the GPL EMR software situation from the perspective based on these premises, what I see is that the survival, further take-up, development, and eventual success of a code depends on:
- how well it is accepted by developers as well as users (easy to develop, customize and install? quality and features of code)
- how well it is managed by the developers (new patches handled smoothly? Moving in sensible directions?)
All these aspects are important. So the most successful code will be the one that is most easily installed, customized and developed, as well as actively managed.
Now, EMR softwares are pretty hard to get going. Only the inner circle (people who are associated with the developer) tends to be able to install and support it relatively easily and quickly. The tendency, I suspect, is consciously or unconsciously to allow the code to remain like this because there is a perception that it will bring better monetary returns to people in charge of the code. This perception is incorrect.
If EMR software is made so easy to install and customize that everyone uses it, then there is going to be much, much more of it around. This means that there will be more development, more work and more money for everyone. Yes, most of the work will now be simpler, but the high-end-tweaks and stuff-to-do will always be there. So the economic incentive to do this is present, if not easy to see.
To get maximum economic value, a developer of the code must indeed to harness the fact that he knows the code. But the developer will get more demand for his skills, and greater reputation, if his code is popular rather than scarce. The demand and reputation the developer garners is proportional to the number of people using the code. So giving away good code under GPL not only benefits the code, but also benefits the developer economically, as people turn to him for consultancy and installation and tweaking for higher end stuff.
Bell Labs computer engineers many years ago were in a field where there were few people around, and made unix pretty open. They remain an elite in a field that has become enormous, and where most work is at the low-end. They continue doing their high-end stuff. Rob Pike doesn't go around installing Linux and showing people how to use a mouse. He goes to Google Labs to play around with other fun stuff. |
