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

[Carlos Moro]

Hi all,

First of all, sorry for being a bit late in my response... in family
vacations  O:)

Richard Terry wrote:

> 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.
   I (and many othe people also involved in health informatics in
Spain) never thought GnuMed as any kind of unmanaged project, neither as
a project lead in the wrong way. I really think the opposite:
developping a  health information system is a terrible complex effort. I
recognize in Spain we're in great backwardness in health informatics
but, from my experience, even experimented hospital and company's *PMs*
(product managers and project managers)  would turn pale if confronted
to take decisions like the ones taken every day by the people working on
this project. I began to coolaborate on March  2004, so I'd talk only of
what I've experienced here since that moment. I specially want to remark
the great work and effort made by Karsten, not only in the  the pretty
well designed, safe and rebust backend... but also for the great and
hard code reviewing and teaching (as in my case, helping me day by day
in how to improve my code) work and effort...

   As a coder, i've worked in medium size projects suffering the pain
of writing code for lots of screens and forms and designing and
redesigning the model at the same time... the PM usually just gave us a
sketch of the functional requirements, but we cried for ... *model*. I
confess, even in those adverse situations, the projects were successful
and the applications are dealing with critical informations 24 x 7  ...
so , what could we have done if we had got the appropiate  model -
backend before coding the rest of the app? ;)

So, at this stage of development, I would schedule the model (GnuMed
backend) as the main objective. All of us know the objective is being
accomplished with ... an excellent mark.

> 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.
>  
   I repeat my opinion of a previous thread. We'll build for first 0.1
version a functional and stable base code and backend... There's no
doubt many individuals and organizations will then begin to try the
software and we'll get a lot of feedback. We'll also feel  free from
basic previously solved questions and will be able to make or brains
think in improving next steps (UI, context, integration...). The system
will be validated in some pilot experiences with the collaboration of
third party organizations... but the project will roll then like a snow
ball ... OK I'm not a fortune teller, but I can calculate probabilities
and needs...

> 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.
>  
I've contributed for some time to KDE and collaborated in other
successful open source projects and the first difference with GnuMed is
mainly *the amount of hours (hands, brains) dedicated to  write and
review the code*... For example, from my experience in KDE development
and mailing list participation (i'm *not* saying it's the right way,
just what my eyes saw):
   -even in the smaller mini project there are many active coders and
reviewers and cvs activity is high (tons of cvs commits mailing lists
mails per days)
   -people tend to encourage less discussion and more coding
   -there's not great pain in committing and releasing initial
approachs and "there's always time to fix the bugs"

> gnuMed seems to have no such structure.
   I can't figure out why you say that. I've heard people in
university, that are currently involved in health information systems
development, saying, after looked at GnuMed project and backend model:
'aren't we reinventing the wheel? Shouldn't we use GnuMed?'.  They are
currently not involved in GnuMed, but really appreciate it, and I
guarantee they're not *'blind spot'*  or easy to convince...

   If you look at KDE, there are the mailing lists, the roadmap and
some general good decisions. We have all of them. But we have not their
resources (material, human...)... really I prefer not looking at other
projects and comparing, I consider we're wise enough to drive this
project to the best way by ourselves...


> I've watched a large number of talented people come enthusiastically to the 
> project, only to melt away into cyberspace.
   And many were (legitimally) looking for a ready-to-use software. In
my experience, I found a very kind small community, lot of help and
collaboration and  concrete tasks to be progressively involved... who
can ask for more? ;)

> IN Summary I beleive:
>
> 1) We need a project manager WHO IS NOT INVOLVED WITH CODING.
>  
   Sorry if i repeat myself. For me, we *do have project management*,
and Karsten is doing an excellent work on driving and helping this boat
to arrive to a good harbour. If anyone, *coder or not, that's not the
question*, takes the effort of collaborating in managing in the
follow-up of this project, that's perfect ... people's hours in any
tasks (coding, designing - I really appreciate your designs and ideas,
Richard, managing) is what we need...


Best regards,
carlos