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

[Tim Churches]

Horst Herb wrote:
> On Thu, 6 Jan 2005 10:57, catmat wrote:
>
> > > 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.
> >
> > these people are full time, trained for SD, company employees or paid
> > computing academics,
>
>
> I was actually "there" when KDE started out. It was even more chaotic than our 
> gnumed. And look a t it now.
>
> Things need to evolve, and need time for evolution. If you manage too tightly, 
> you can restrict to a degree where you enslave your creativity.

That's something a manager would have to (and can) understand. "Manager" 
does not automatically mean "idiot".

> That said, Richard has an excellent point.

My take on this is as an interested bystander who a) has (wearing public 
health hat) a professional interest in seeing GNUmed suceed as a vehicle 
and platform for furthering public health in primary care; b) (wearing 
health informatics hat) a professional interest in seeing GnuMed suceed 
due to its well-chosen technical foundations (Python, PostgreSQL etc); 
c) (wearing Che Guevara red beret) a personal/political interest in its 
success as a free, open source software artefact and example of an 
alternative means of production; d) (no headgear at all) someone who 
attended the August 2003 Gnumed.au conference at Sydney Uni, and who has 
monitored the Gnumed mailing list for several years now (predating the 
Aug 2003 conference)

It seems to me that since Aug 2003, there has been a significant 
increase in activity and code writing, but remarkably little significant 
progress towards a working prototype. I regard a working prototype (by 
which I mean something which has the minimum set of essential features - 
and defining that minimum set is an essential and early task in itself) 
as important because, to me, Gnumed seems like a large and ambitious 
project, which will inevitably require a small team of full-time people 
working on it to bring it to production-ready status. Slinging code is 
easy - its the tedious stuff of writing and conducting formal testing, 
writing good end user and technical documentation, and iterative 
fiddling with thousands of little packaging, documentation and 
installation details. It takes an enormous amount of time, and you need 
a few people who have the luxury of having to think about nothing else 
but Gnumed for a few months to be able to do all that. Otherwise the 
project will, I fear, forever remain in a state of alpha status, 
pre-production "thrash".

But at the moment, its not even at alpha status. The reasons, I think, 
is because there is no shared, absolutely explicit list of minimum 
requirements (and underlying architecture) for Version 1.0, and no 
agreement to stick to that minimum list. Inevitably, such a minimum list 
will never be totally "correct" for everyone, or even anyone, but that 
doesn't matter - at least it enables a reasonable, working Version 1.0 
to be produced. Without the "plausible promise" of a working alpha 
version, Gnumed will never attract the full-time resources (volunteer or 
paid) needed to allow it to get past the alpha stage, I fear.

Finally, I'd like to note that having a set of explicit requirements and 
architecture documents and a manager to co-ordinate their implementation 
does not mean that those decsions can never be chnaged, even 
mid-project. It just means that any decision to change the architecture 
or requirements will take into account the impact on the project 
timeline. As a result, some changes, even though highly desirable, may 
need to be deferred to a later version. As an observer, what I see is 
that new ideas suddenly become the mainstream plan overnight in Gnumed, 
without general discussion of their impact on the rest of the project.

So, my (unsolicited) advice is: draw up a set of minimum requirements 
and an agreed architecture, and then stick to it, and vary the 
requirements and architecture only reluctantly and after careful 
consideration of the resource and time implications. In this way you can 
still make Gnumed Version 1.0 better than anything else, but save 
perfection for Version 1.1.

Tim C