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

From:

Tim Churches

Subject:

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

Date:

Thu, 06 Jan 2005 06:02:48 +1100

User-agent:

Mozilla Thunderbird 1.0RC1 (Windows/20041201)

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.