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

[Syan Tan]

with respect to "impenetrable" , gnumed is definitely not 
impenetrable :- it has the following features:

- single threaded , event driven execution  - using wxWindows framework.
Someone mention QT, this is also single threaded event driven
  - event driven means a user event or a system event happens, and this
causes the program to offer a response

- it is a object relational mapping , and does disconnected transaction checking
  - it uses sql as a final backend because relational databases are usually 
fast,
easier to program with SQL, (then say network databases ), widely available 
documentation due to high demand from ease of use.
  - uses objects as way to group together functions , e.g. F*CRUD with 
integrity 
checks.
(F*CRUD - find, create, update, delete)

  - objects relate naturally as a Document :  medical records are collections
organized as one document/file  per patient,
     - a document can be viewed a single rooted hierarchy of objects, 
      a tree,  or directed acyclic graph ;  it is possible to serialize one
document <=> objects pertaining to one patient , into a single serialized text.
     - the main reason for using SQL is it's easier searchability, and the
  possibility of fine locking of parts of document for concurrent access to 
one document.  With respect to concurrency, gnumed uses SQL transaction blocks
to ensure integrity of foreign keys between parent/child rows, but uses 
manually programmed Transaction ID checking to check for write-write conflicts,
and postgres Push model notifications to push TID changes so clients sharing a 
document  have  a sequentially consistent model of a document. 

- unlike Mozilla, which must incorporate a lexer, syntax analyzer, and 
graphical 
constructor, or sendmail, that reads configuration scripts and have a rules 
parser,
gnumed's configuration consists of mainly specifying which graphical widget 
module
to load ; it relies on it's domains pretty stagnant conceptual evolution - 
handle 
scripts, notes, medications, allergies, immunizations, lists of info (past 
history, 
social history, family history) , investigation requests, referral letters, 
import 
results / electronic discharges , and images of letters / paper results,  and
you've got the basics covered. Add in a DICOM plugin to view radiology images, 
a OpenGalen or SNOMED-CT natural language parser/ classifier, and hey  presto, 
you're 
the vertical app leader.
  in other words, it would take less than 1/20th the work on apache to get a 
functional gnumed.







 
 

On Sun Dec 18 20:44 , Richard Hosking  sent:

>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:    
>
>
>
>Dear all
>
>Herewith the results of a quick Google for “successful Open Source projects”
>
>
>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”.
>
>
>  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: /
>> /**************************************/
>>
>> 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
>>  
>>
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel