[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]