[Fwd: Re: [Gnumed-devel] Vision and implications: Strategic planning]

[Richard Hosking]

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
>