Please see the announcement below for your attention.
Your views on the future direction of openEHR are especially important
at this time.
Please feedback any/all views to this list to generate the discussion we
need.
Hi Tony!
Thanks for inviting comments in an open way. Organisational issues
have been touched upon earlier (see previous discussions on the
technical list). I believe some of us would like to know what will
happen to the feedback this time. Some previous discussion responses
(and partly an interest in implementation rather than organisation)
have made me keep a version of this message in draft for several weeks
instead of finishing and sending it. My hope is that this message
helps more than it hurts.
Previously parts of a board announcement said...
On Wed, Dec 1, 2010 at 14:29:
[The following from prof. David Ingram, UCL]
...
We have adopted a low profile, to avoid being drawn into the
multiple vortices afflicting the field. We have thereby retained
flexibility to focus on requirements and implementation issues,
making no pretence of democratic process.
Has this changed and is there now real interest in figuring out what a
more meritocratic or democratic formal openEHR organisation would look
like?
If so I'd suggest reading through
http://www.apache.org/foundation/how-it-works.html thoroughly and
reflect on it's content.
Seriously, read that link before going on reading this long mail. That
document captures many years of experience in a lot better way than my
ramblings below. Also if you believe Apache is only about web servers,
have a look at the nearly 150 projects and initiatives at
http://projects.apache.org/indexes/quick.html and
http://incubator.apache.org/ before going on.
Sometimes the openEHR foundation to some has sounded like having a
commercial startup company mentality saying: "We've been working very,
very, hard (and late in the evenings) investing lots of resources in
openEHR (even though we have jobs/departments/companies to run) and we
now want somebody with good finances to either buy us out or help us
scale up our venture to keep doing things pretty much the same way we
have done so far (but at a larger scale)."
I guess there is now a sense that openEHR is no longer in startup
mode, but an uncertainty if there is any other option than a resource
rich buy-out after the IHTSDO approach failed.
Please understand that many comments (e.g. previously on the technical
list) were not asking anybody to work harder, but rather asking the
foundation work in a smarter, less individual dependent way, reducing
risks and enabling distributed workload and decision making. Do take a
close look at what the Apache foundation has figured out over the
years. The suggestion is instead to reflect over things like
"sharpening the saw" or "we're too busy mopping the floor to shut the
faucet.", see...
http://c2.com/cgi/wiki?SharpenTheSaw
http://www.codinghorror.com/blog/2009/03/sharpening-the-saw.html
...i.e. work smarter and allow distributed helpfulness, coordination
and decision making - not only look for more money to keep doing
things as usual, only more and faster (even though money would be
helpful). Getting stakeholders to invest working time might be both
easier and more important than large monetary contributions if done in
the right way. Do read about "agency costs" on page 6 in
http://web.mit.edu/evhippel/www/books/DI/Chapter1.pdf
Several Apache projects certainly get a lot of time investment from
big stakeholders that at the same time are users. (IHTSDO is also
depending on members contributing large amounts of
non-IHTSDO-reimbursed working time in addition to fees.)
When discussing future openEHR organisation with peers I know that
some of them strongly disagree with me and rather than
Apache-inspiration opt more for an IHTSDO-inspired organisation style
based on commitment from tax-based national authorities and a high
degree of synchronous physical or telephone meetings to get things
done. So the Apache-style angle is my personal point of view, not
necessarily my employer's or research group's view.
I agree that an IHTSDO-like approach would be better than the present
openEHR situation. The IHTSDO-style of organisation is easier to
understand by national authorities then the Apache-style. If there is
a strong sense that there is plenty of financial and national support
just waiting to start an IHTSDO-styled organisation for openEHR, then
it will probably work. If there is not any such support, then shifting
over to something Apache-like delivering standard suggestions to other
SDOs might work better.
Many organisation styles do have some kind of member based highest
decision making general-assembly function that I believe openEHR is
lacking now. The difference is in how that assembly is elected e.g.:
- pay the fee (IHTSDO, The EN13606 Association, HL7?)
- anybody can join free (OHT)
- be helpful, work, and get recommended (Apache)
- be/start a nation (CEN, ISO)
All have their pros and cons, and it comes down to what kind of
thing(s) openEHR wants to be and how it will interact with other
organisations.
Perhaps different parts of the openEHR ecosystem needs different
organisation types? Maybe an official openEHR archetype repository
could be governed in a different way than RM-specification
development? What tool development actually needs to be under the same
umbrella as the specs or the archetypes? In Apache different projects
organize themselves differently.
For decisions that affect a nation one could reasonably argue that the
elected bodies of a nation should have some influence over and
responsibility for the process. So the specifications from an Apache
style (meritocratic) organisation should not become national standards
without passing a national or international SDO like CEN, ISO or
IHTSDO.
I believe one problem for Apache-style organisations in the health
care area is if the nations (preferably the real problem owners, like
organisations running health information systems) are not enough
involved during development but only later during synchronous
relatively fast SDO-negotiations where they twist and change the
technical specs in untested manners. Developing specifications in an
Apache style organisation without good national involvement and trust
would thus not work very well, thus getting broad trust and
involvement would be central to an Apache-styled organisation in this
field.
In IHTSDO the committees deciding on actual technical and clinical
work are appointed by and pretty much trusted by the general assembly
so things don't get twisted too much in the approval process. Also the
mailing lists and meetings are open to anybody in the world who cares
to join (presence, not voting).
Below some things to reflect over when reading about Apache that could
be useful for no matter what organisational style openEHR selects:
1. Making sure core assets (e.g. specifications, important tools and
archetypes) are technically and legally "patchable" and that there are
enough independent trusted people with rights and possibilities to
apply patches to the (sub)project (called committers in the Apache
document). A "patch" in a software meaning of the word is a file or
set of files that improves or corrects a file or document. Via tools
the patch can be easily inspected and applied to the targets.
This means that workload can be shifted over to people/organisations
that have a desire to fix something that they consider important (or
easy) to fix, provided that the community agrees by not putting in any
veto and counter suggestions. This can be done even when "core
developers" are busy tending to more urgent matters. A problem today
in openEHR is that many small matters need to go through people that
really need to focus on other things.
In openEHR I'd say the Java implementation despite it's state has a
lot of resemblance with Apache thinking. Patches are being exchanged
and there are committers within at least three independent
organisations. If the project leader, Rong Chen, would shift
interests, change employer or just need a long break, the Java
implementation would probably slow down, but it can still be updated
and kept alive. OSHIP seems to have similar goals.
The ADL Workbench and the (now old) LiU Archetype editor are examples
of projects that have good licences, available source and are
technically patchable, but where there is no wide developer community,
so they would currently probably not go past incubation stage
according to Apache community criteria. The community situation for
the very nice LinkEHR editor might be similar - I don't know since I
didn't see a public code repository there last time I looked.
The archetype development within the CKM seems to have a good
community. Perhaps someone else could say if there are people from at
least three independent organisations that have commit/publish rights
and what would happen to openEHR hosted archetype development if Ocean
Informatics would go bankrupt e.g. because of getting sued by some
angry American patient. 
Archetype development could of course still go on using other
community tools, so this is not a burning issue for the openEHR
community. Discussion groups and a versioned file repository would do
much of the work.
Regarding archetypes, the more important issue is to switch license
for openEHR-hosted archetypes to CC-BY, Apache 2, or something else
without a contagious SA-clause, in order to gain trust from commercial
actors wanting to base systems on openEHR-hosted archetypes. (See
http://www.openehr.org/wiki/x/HACt ) Currently only Ocean Informatics
and UCL can feel really safe putting such archetypes to use in closed
source systems. My interpretation is that since the Ocean+UCL based
foundation board trust themselves to always be nice to everybody, they
will never see the practical trust problem for someone else betting
their company/region/nation on the use of openEHR hosted archetypes.
(That's a perspective a general assembly with broader base hopefully
could change. Mailing list & wiki comments obviously have no impact.)
If not changed, the likely impact is that an alternative global
archetype forum with better licencing will surface and gain a lot more
momentum than it would have otherwise. That would be a waste of
efforts and would reduce interoperability.
Another less important issue is that the CKM tool itself is not
patchable due to license issues etc (yes we have understood the
historic reasons) and if Sebastian Garde or Ocean Informatics would
lose interest in or lose resources for development it's unclear what
happens. Thus it's important that the openEHR community in the long
run either creates and shifts tooling, or keeps some really good
public backups of everything that happens within the CKM, including
archetype revisions and all discussions, so that experiences don't get
lost. (That's why I've been speaking of complete logical DB backups
rather than just a zip of the archetypes. Again, if you are on the
inside of the organisation you might not see the trust problem.)
Regarding the openEHR specifications I don't know if the entire
Architecture Review Board has "committer" rights or if it's limited to
less than three independent people/organisations. Technically I
believe the specifications are only practically patchable if one buys
a licence for FrameMaker. Last time we discussed this, in the long
thread named "Documentation Desperation" starting at
http://www.openehr.org/mailarchives/openehr-technical/msg04592.html
parts of the (friendly and understandable) responses were similar to
"Too busy sawing by myself with my excellent personal hand saw to
change to another sawing system allowing more workers, besides that,
how do we know if anybody else would help?". Now when MLHIM has
actually done the work of converting parts of the openEHR
specifications (https://launchpad.net/mlhim-specs) then perhaps this
issue could be reconsidered, possibly combined with changing license
to a more well known CC-BY style.
2. Can the Apache way of decision making via slow discussions and
consensus voting (http://www.apache.org/foundation/voting.html) via
mailing lists, including veto mechanisms, be a way to avoid some of
the problems with voting by a limited group of volunteer persons
present in physical meetings (that have been described, e.g. by Tom,
as a problem of some current SDOs)?
3. Would it be important to openEHR engagement that there was an
outspoken path similar to the Apache path of: user -> developer ->
committer -> voting member. Would that be interesting both for
companies/organisations and individuals?
(Consider the Apache claim "What is interesting to note is that the
process scaled very well without creating friction, because unlike in
other situations where power is a scarce and conservative resource, in
the apache group newcomers were seen as volunteers that wanted to
help, rather than people that wanted to steal a position.")
4. Would the Apache way of having personal rather than organisational
project membership be useful in openEHR? (Apache financial sponsoring
is mostly from organisations, but project membership stays with the
person even when a person changes employer.)
5. Why do you think a company like Google submitted it's Google Wave
research investment to Apache, see
http://googlewavedev.blogspot.com/2010/12/introducing-apache-wave.html
when they could have kept control over the project organisation
themselves and still faithfully be called an open source project?
I hope that those points above are somewhat helpful when considering
the future of openEHR.
One last thing: In the board announcement it said "We would like to
invite initial discussions on organising this meeting on the openEHR
lists, which Sam Heard will moderate." - It might be helpful if you
let somebody not being CEO of a very openEHR-intertwined business
moderate discussions, at least _during_ that meeting. Tony together
with somebody from the technical ARB might do that well. That way it
would be easier for Sam and others to separate foundation perspectives
and business perspectives and he would be free to speak as a CEO not
having to balance this with moderator neutrality.
Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
P.s. If going for an Apache-style meritocracy, for parts of or for the
entire openEHR foundation, then one of several options for creating
the first general assembly needed for bootstrapping could be to take
the union of the Architecture and Clinical Review Boards complemented
with some national openEHR-savvy representatives from presently
underrepresented but interested countries. I guess such a decision is
presently completely in the hands of the current openEHR foundation
board. That assembly could then discuss how to broaden it's base in an
open but controlled manner.