[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fwd: Re: [Gnumed-devel] Vision and implications: Strategic planning]
From: |
Richard Hosking |
Subject: |
[Fwd: Re: [Gnumed-devel] Vision and implications: Strategic planning] |
Date: |
Sun, 18 Dec 2005 20:44:58 +0800 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20050317) |
Damn I always forget the "reply all"
-------- Original Message --------
Subject: Re: [Gnumed-devel] Vision and implications: Strategic planning
Date: Sun, 18 Dec 2005 16:46:28 +0800
From: Richard Hosking <address@hidden>
To: J Busser <address@hidden>
References: <address@hidden>
Dear all
Herewith the results of a quick Google for “successful Open Source projects”
*Characteristics of a successful OSS Project*
What are the characteristics of a “successful” OSS project?
I thought it might be a useful exercise at this stage in Gnumed's
development to look at the characteristics of some projects that are
widely acknowledged as “successful” and apply these to Gnumed.
I have done a brief (3hr) Google search on “successful Open Source
projects”.
*Some brief conclusions *
1.
*Most OSS projects fail*
90-95% of all startups disappear
2.
*Of the projects studied, all arose out of a need to improve a
current program*
Apache, Mozilla and Sendmail all arose from the need to improve a
current program. Hence a working “prototype” was available. It
appears difficult to generate community interest without anything
to work on. It could be argued that Gnumed 0.1 is a prototype,
even though it has only minimal functionality.
3.
*There is little literature on traditional design methods*
On this quick search, I could find very little on the upfront
design process we have been discussing. Feasibility and user
requirements appear to be not formally considered in most OSS
projects. Presumably the developers involved consider these issues
informally
4.
*Most OSS developers are users*
As such, they understand the “domain” the software is to work in,
and have a clear idea of (at least their own) “user requirements”.
This appears to me to be a major problem for Gnumed – while the
developers are medical, there is divergence on what functionality
the program should provide as a minimum. Most potential long term
users will not contribute to development as happens in many OSS
projects
5.
*Project “governance” varied*
Of the three projects considered, one was a spinoff from a
commercial venture (Mozilla) and Netscape retained control and put
considerable resources into managing and testing the codebase (6
teams). Apache was probably the most similar to Gnumed. This had a
much smaller codebase than Mozilla. There were 8-25 “core”
developers, with 4-8 active at any time. Most of the codebase
(>85%) was contributed by 15 core developers. They had a “quorum”
for voting on major issues. Most communication was via E mail
lists. Sendmail was coordinated by a single developer.
6.
*Users who are knowledgeable contribute to identifying and fixing
bugs*
Approximately 10 times as many users as “core” developers supplied
fixes and many more again identified bugs and tested software
In summary I see the problems for Gnumed as "user requirements" and
sheer technical feasibility with the current resources of a very complex
software suite. It could be equated to the complexity of Mozilla
Does anyone want this (or more) posted to the Wiki?
I could add an attachment to the Development Process page
Richard (H)
References
http://www.research.avayalabs.com/techreport/ALR-2002-003-paper.pdf
http://www.cmcrossroads.com/ubbthreads/showflat.php?Cat=&Number=53266
<http://www.cmcrossroads.com/ubbthreads/showflat.php?Cat=&Number=53266>
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
<http://www.catb.org/%7Eesr/writings/cathedral-bazaar/cathedral-bazaar/>
http://aseigo.blogspot.com/2005/11/writing-successful-open-source.html
J Busser wrote:
/**************************************/
/If people wish to reply with a related but separate issue, suggest
(per Richard) they change the thread to/
/ Vision and implications: <something else>/
/**************************************/
I am thinking that the subtopic "design principles" might await being
informed by Hilmar's upcoming "specs". But "specs" and the software
engineering design pointed to by Daniel will be better to fit inside a
strategic plan. Therefore this thread.
Pending adjustments, the vision *may* be
an affordable, reliable, comprehensive, interoperable, scalable
software solution for paperless medical practice with emphasis on
privacy protection, secure patient-centric record sharing,
decision support and ease of use.
So what pieces are needed for a strategic plan? Perhaps
- decide more-specifically what we want to achieve
... maybe called goal-setting
- decide how we want to achieve it
... there is both "tactical" and "strategic"
... "tactical" is what we do because it has short-term value even if
it is later discarded
... "strategic" is consistent with, and builds toward, a design that
is *not* to be discarded, so this piece is very important, meaning to
identify what is needed to be successful in the longer term
- I am thinking we also want "planning principles". Things like
planning in cycles. Not just "software development" cycles but other
cycles, too. Planning cycles. Advocacy / advertising cycles. User
uptake cycles. Deciding how "big" to make any one cycle. Figuring out
how much time and energy will be required for a cycle, and whether and
how it is needed to recruit extra help for a cycle.
------------------------------------------------------------------------
_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel
- [Fwd: Re: [Gnumed-devel] Vision and implications: Strategic planning],
Richard Hosking <=