Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please.

[Thilo Schuler]

Hi everyone,

before I start writing I would like to point out that I know that I
haven't done anything and I don't know many things about Gnumed yet. I
am aware of that but still think a few lines could demonstrate what my
"problems" were when I approached Gnumed. The "insiders" (small circle
of regular committers) might not have this view because they know gnumed
like their pocket.

I also want to let you know that I recently visited Richard. He
explained me the reasoning behind his design and showed me his running
system (VB+Access). This system - although lacking of a progress note
facility - is quite impressive. It shows how much a well used computer
system can help a clinician to focus on more important things (the
patient) without neglecting necessary documentation. I saw him using the
system during an unplanned consultation.
As you you know his main interest is the GUI side of things. And I have 
-including commercial solutions- seldomly seen such a tidy, well thought
through and functional interface. He has achieved that by many design
iterations which he actually tests durning real-live consultations. This
is a very valuable asset.

Please don't think I am now biased towards his point of view. While we
were talking we discovered agreement on several issues regarding the
governace and appearance of Gnumed. I had noticed them when I first
became heavily interested in the project about 1.5 years ago:

Back then I was really convinced (and still am) by the overall concept
of Gnumed. I subscribed to the list and spend a considerable amount of
time on the different gnumed and gnumed related web sites. 

What I really missed was a consistend, self-explaining structure of the
web site and a couple of summarizing (white paper like) documents that
explained what, why, and (maybe -but not necessarily- the basics of) how
things have been done. I have found some docs here and there (mainly
from richard and horst) but most of them seemed outdated and it didn't
give you the feel that "if I read these how many docs whatsoever than I
have a basic understanding of what gnumed is about and where it is
heading". It is especially important since if you ever get the client to
run (takes considerable effort if you aren't the total geek) it is far
away from being self-explainatory. This could be a reason why gnumed
gets (although very rarly) good programmers like syan, carlos but not
many wrapper-uppers and documentators like Jim. It must be possible to
reach the state of feeling gnumed-literate without fighting through the
source code!

As far as I am concerned I am would rather try to inform myself as much
as possible through web site, wiki, ... before I go to the mailing list
and have to ask every single thing. Once I am convinced by the project
and have an idea how I could contribute, then discussion on the list is
obviously essential. 

But it should be CONSCIOUSLY SET TIME ASIDE TO DOCUMENT AND PRESENT WHAT
HAS BEEN ACHIEVED every now and then (a formal plan or roadmap for
writing white papers, howtos,... has to be adapted) so people who don't
follow the list all the time or who are new to gnumed can catch up. The
mailinglist archiv is not a proper medium for that and even the
"everyday working wiki" is not structured enough and therefore
unattractive (doesn't look like the project is well organised) for
somebody who wants to check out gnumed to decide whether they want to
get involved.y. The way it is now newbies can only understand gnumed if
they risk to take on a mini-project and then gradually by hundreds of
questions get to the point where actually know what gnumed is. This is
fine, but for me (I didn't have the time at that point in time) and
probably many other interested who could contribute in smaller tasks
that is not practicable.

Back to me, because the web site didn't give me the needed information I
travelled 600 km to the gnumed.de conf last december. I found it very
valuable to see the people behind the list and ask questions directly.
So I appreciate Richards proposal for more confs very much. I think -if
possible- it can be very fun to see the fellow gnumedders that you meet
a lot in cyber space. Such concentrated efforts -if well planned- can be
very productive and give the project a new boost.


I am telling you that in the awareness of the fact that gnumed is
lacking of contributors (especially documentators) and I very much like
the way how Jim has been doing so far. I would like to join him as a
documentator. I thought while I am trying to build a XUL front end for
Gnumed (as proof-of-concept part of my thesis on openEHR
archetypes-based interfaces) I could write some documents. Maybe one
about the basic ideas behind the backend schema. What is it capable to
store. What are the paradigms behind it? And a howto (with examples) on
the usage of the middleware API.
What happend to the plans to refurbish gnumed.org? I have seen some good
suggestions for the menu structure a while ago. I also think it should
be moved to a state of the art CMS system (plone,...) in the medium
term. Carlos single man effort to reset up the wiki (thanks a lot!!!)
shows that the knowledge is there.  


Uff, hope I kinda conveyed my thoughts.

Cheers, Thilo






On Wed, 2005-01-05 at 12:26, Richard Terry wrote: 
> One of my new-year resolutions was to try and re-start the debate again on 
> gnuMed and the way it is heading (or not heading depending on which way one 
> looks at it).
> 
> I'd ask anyone reading this to give it time and considered, not knee jerk 
> opinion. Though I've mentioned particular names of some of those involved in 
> the project, I hope that those mentioned are able to not take any comments 
> I've made in a personal way. Also, firing back comments to this post such as 
> 'its in the Wiki' 'It's in the road-map' is not going to be helpful.
> 
> Perhaps asking those who susbscribe to the list but don't take an active part 
> in development to pass an honest opinion on the processes of this group and 
> what they see the problems as and how things could be improved.
> 
> Slashdotters amongst you may possibly already have read one of today's links 
> entitled "Developers, is your project a sinking ship?". If not please read 
> the link before continuing: 
> 
> http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=239
> 
> and specifically try and apply the criteria to gnuMed, if necessary by this 
> quick link:
> 
> 
> http://www.acmqueue.com/figures/issue019/tiwana2.gif
> 
> Anyone checking out the gnuMed web site is confronted by the following 
> hopeful 
> description;
> 
> ==============================================
> As its major project, it is busy building a medical software package that 
> will 
> be
> 
>     * open source
>     * free
>     * secure
>     * respectful of patient privacy
>     * based on open standards 
> 
>       
> 
>     * flexible
>     * fully featured
>     * networked (client-server architecture)
>     * easy to use
>     * multi platform
>     * multi lingual 
> 
>           Gnumed is being actively developed, but is not yet ready for 
> clinical use. 
> ==============================================
> 
> The essence of the problem to me is whether or not gnuMed can ever offer an 
> alternative to current medical software, if it continues in its current 
> unmanaged direction. Having such an ambitious project which in the end only 
> works for a few individuals in the world because that's the way they designed 
> it, is not of much use.
> 
> Some sort of project management I beleive is essential for gnuMed. If one 
> looks at all the sucessful open-source software projects, ranging from KDE to 
> GIMP, Abiword etc, all have some sort of project management teams. There is 
> an overall goal, and each of the developers have an allocated role, with 
> someone having a final say in certain area's.
> 
> gnuMed seems to have no such structure. We addressed this in detail during 
> our 
> gnuMed conference in Sydney a long time ago. We attempted to put in motion a 
> process which would involve a proper plan for the project, to no avail. The 
> frustration for me is that a number of active developers on the list seem to 
> actually beleive that there is structure and process, almost like they have a 
> 'blind spot'.
> 
> I've watched a large number of talented people come enthusiastically to the 
> project, only to melt away into cyberspace. I Myself, have gone through long 
> periods of not even bothering to read the listmail, 'disappearing' for months 
> on end. 
> 
> IN Summary I beleive:
> 
> 1) We need a project manager WHO IS NOT INVOLVED WITH CODING.
> 
>  ie someone with project management experience and talents who at the end of 
> the day has the final say, who can overide Karsten, Horst, Ian, myself, 
> carlos, etc, because they will have the ability to have a larger over-view 
> than anyone in the project.
> 
> 2) Individuals who are accepted as part of the project development team need 
> to have their abilities respected, and given the final say in their aspect of 
> the project design over other team members, subject to the final decision of 
> the project manager.
> 
> 3) We need a heavy dose of reality checking in respect to what will make the 
> project actually become usuable e.g sticking to the niave belief that drugref 
> will be able to provide usable drug data to the office desk of working GP's 
> in australia needs to be replaced  with the pragmatic decision to make a deal 
> with say MIMS and use their drug data. As much as you try an argue against 
> this stuff it is reality. Perhaps in the future we can switch to DrugRef, but 
> not now.
> 
> Though I almost cringe at the thought of another frustratiing day, perhaps 
> its 
> time for another gnuMed AU(+DE) conference to thrash this out for once and 
> for all.
> 
> Thoughts??
> 
> 
> Regards
> 
> Richard
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel