Tim,
a few points by way of response:
1. the NCSA web server (which I used to administer in one company) was
built by normal paid engineers in jobs where they were directed to build
that tool - i.e. dedicated paid time.
2. there has been no barrier that I am aware of to people wanting to
come and work on any openEHR project, indeed it is and has always been
highly encouraged. If you think there is some barrier, please let us know.
3. with respect to Sam, you are doing him a disservice. Sam is a medical
doctor, and people technical here sometimes forget that the main game in
the real world for doctors is giving care: seeing patients individually;
improving methods of care; sometimes working at policy level to change
health care systems. From that point of view, the ideology of software
is pretty uninteresting; people in this position are heavily oriented
toward /solving the problem/. As a GP familiar with computers, Sam was
using Windows to built desk-top tools 20 years ago, and even 10 years
ago, it was the only realistic way to built desktop applications. There
was no way for small companies to easily build a desktop app out of C++
or other such engineering languages. So the choice of using (today) .Net
has nothing to do with the ideology of open source or otherwise; it was
just about using tools that were available to solve the problem.
As it happens, Sam is very interested in open source, and the Archetype
Editor was open source since day 1. It turns out that the world at large
is not interested in helping write even this tool. It may be that unless
something is written in Java, Python, PHP etc, it is not seen as open
source. For the other tools built by Ocean, the priority was always to
build something economically that solved the problem most efficiently.
4. There is nothing stopping other companies being particularly open
source oriented. Indeed, Zilics did it some years ago, building on
Rong's original Java openEHR code. This also didn't magically make
hoards of programmers come on board (in fact only the programmers from
their company worked on it). The same thing can be said about the CHIME
Opereffa project. As Seref said, this is largely because any such
project that actually is open sourced, is not perceived to be
sufficiently relevant to other parties in solving their problems that
they should start work on it. So they don't, the write some other
software of their own. This in my view is an indicator not of the
bloody-mindedness of people, but of the massive complexity and diversity
of the field. Its needs just can be solved by building a single tool
like an Apache server.
5. One key difference between the kind of solutions being built in this
domain and Apache is that Apache is ubiquitously useful - to everyone.
It's like running water - everyone wants it. So of course it is easy to
get bazaar-style open source taking off in that situation. Same with
Linux. In the e-health area, it is much much harder, and that's what
history shows. The various attempts to set up and run communities,
cannot be said to have succeeded - even with hundreds of individuals
available and apparently motivated to make something happen. Yet, no
real open source EHR solution has appeared. I suggest that this is because:
* it is intellectually hard, and is not a problem that can be solved
by jumping into code before doing some serious design work
* many people have different, incompatible ideas of what an EHR is,
and therefore don't agree on what to build anyway
* it requires interoperability as a key feature, and
interoperability requires agreement. It is extremely hard to get
meaningful agreement on technical standards for e-health, and the
poor results of the official bodies (using completely the wrong
algorithm and business model) are evidence of this. Open source,
as a movement, has made practically no useful contribution to
interoperability, so clearly, it is a problem that has to be
solved elsewhere - in my view, as you know, by a dedicated
engineering/development group.
In hindsight, what was probably needed was an IBM to spend $30m
developing an EHR stack and then giving it away through Eclipse or so.
Nevertheless, progress is happening, and it will not be long before more
open source tools are available.
- thomas
On 18/11/2010 00:29, Tim Cook wrote:
> On Wed, 2010-11-17 at 22:19 +0000, Seref Arikan wrote:
>> I personally see this big bootstrapping requirement as a unique
>> problem of this domain,
> Compared to creating your own world class web server in the mid 1990's?
>
> RE: http://www.apache.org/foundation/how-it-works.html
> =========================================
> Unlike other software development efforts done under an open source
> license, the Apache Web Server was not initiated by a single developer
> (for example, like the Linux Kernel, or the Perl/Python languages), but
> started as a diverse group of people that shared common interests and
> got to know each other by exchanging information, fixes and suggestions.
>
> As the group started to develop their own version of the software,
> moving away from the NCSA version, more people were attracted and
> started to help out, first by sending little patches, or suggestions, or
> replying to email on the mail list, later by more important
> contributions.
>
> When the group felt that the person had "earned" the merit to be part of
> the development community, they granted direct access to the code
> repository, thus increasing the group and increasing the ability of the
> group to develop the program, and to maintain and develop it more
> effectively.
>
> We call this basic principle "meritocracy": literally, government by
> merit.
> =========================================
>
> At that point in history there wasn't an Apache Foundation. It was
> people working together. Openly, based on their interest and merit they
> were given access to participate. Right now the BUS FACTOR for the
> openEHR Specifications is ONE! Same as it has been since the beginning.
> I won't repeat Erik's points about archetype licensing. But as you can
> see; the only thing 'open' in openEHR are the specifications as
> published and handed to you. [Okay, there are a couple of tools but no
> one has created a community around any of them.] If you want to
> translate the specifications to another language check to see what hoops
> you have to jump through and software you have to purchase. Want to
> setup your own local CKM? It is open source right? Well, all except
> for the fact you have to purchase the proprietary engine it runs on.
>
>> and that's why I've been suggesting the things I've been writing.
>> I know that there are many paths an open source initiative and
>> business model can take, but I'd like to have that discussion with
>> clear suggestions/list for work items, and people who will be
>> responsible with it.
> I agree. Of course you get to decide what you consider responsible
> also. :-)
>
> I have a story for you that I like to call; "The Tale of Two Companies".
>
> Two "open"? companies; and their differences. I personally know the CEOs
> of both.
>
> The first is Rob Page of Zope Corp. He doesn't like or even today
> really understand open source. However, he did listen to his advisors
> and investors and open sourced what he considered to be their most
> prized possession. He did not try to control where the technical
> aspects of the specifications for the product went as far as overall
> design. He let the community and his internal engineers collaborate
> openly and even went on to later release Zope Enterprise Objects (ZEO)
> as open source. Today, the Zope Tool Kit is a huge robust library of
> tools used and supported by a large international community. Something
> that one small company could have never accomplished.
>
> Sam Heard of Ocean Informatics. Again a software company CEO that
> doesn't like or understand open source. He was convinced to open the
> specifications. But he controlled his internal staff so that they only
> produced tools that run on Windows platforms. With the exception being
> the ADL Workbench and that was by accident, not by design. If you look
> at the openEHR Foundation Board of Directors and the Architecture Review
> Board (ARB) you can see that it is heavily controlled by Ocean
> Informatics and their close associates. None of whom are or ever have
> been involved in open source/open content in anyway outside of the
> foundation. Changes to the specifications always come out of experience
> from the commercial software that they produce. The ARB is a closed
> decision making, invited members only group. The implementations of the
> specifications are of two kinds (with one exception); closed source
> commercial companies and short term academic projects left to die after
> the thesis is completed.
>
> Both of these companies have been in existence for approximately the
> same length of time.
>
> So what is the difference? It is "community". That is where MLHIM comes
> in. As I said, I did not embark on this lightly. I spent a lot of
> uncompensated time, money and energy trying to change the openEHR
> Foundation from the inside out over the past ten years. I didn't invent
> open source. I simply recognize what works. It is impossible with the
> current structure and the control issues the foundation exercises.
>
>
> These are my thoughts and opinions. I hope someone finds them more
> valuable than what they paid for them. Otherwise it really doesn't
> matter. :-)
>
> Cheers,
> Tim
>
>
>
>
>
>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101118/0776f457/attachment.html>
