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

[Richard Terry]

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