Horst Herb wrote: > On Tuesday 19 September 2006 08:53, Richard Hosking wrote: > > Firstly response to Tony: I would be in, and so would be many others. We had > such discussion before. > > >>> Does the project proceed? >>> > > If at least 20 colleagues chip in $2,000 each, why not? > Present.
>>> What licence model?
>>>
>
> GPL, or I am out
>
* GPL is nice because it's viral and encourages both splits and merges.
* BSD is OK because it permits splits but bad because it does not
encourage merges. It may allow proprietary add ins which would be
acceptable to me but the core would have to be BSD as a platform
on which others might build.
* Proprietary would be OK with me. You can run it as a company with
shareholders, which is a well known and favoured business model in
Australia. You could run it as a co-operative although this
business model has been out of favour in the last 20 years in the
bush.
>>> Target platform(s)?
>>>
> All POSIX compliant platforms (because they make sense) + W32 (because they
> dominate the market)
In practical terms a POSIX (not Windows) server and POSIX or W32 clients
are probably the best options.
POSIX server because you need stability, security, failover etc., etc.
W32 clients because the great unwashed know how to push it around. POSIX
clients are the future of course. Just imagine hospital thin clients for
Jon's med app in the west. (With wifi.)
>>> Does the project develop an entire application or just the core
>>> components with a suitable licence to encourage others to add pieces
>>> to it?
>>>
Both of course, as your question implies. Open base with open or closed
modules. It needs to work in Australian general practices and possibly
Accident and Emergency centres before anyone will take it seriously though.
> I would envision a modular system a la Unix - small applications for well
> defined tasks that interoperate well. Starting with something small and
> functional, and extend from there.
>
I think everyone is pretty happy with this summary from Horst.
>>> Core components, programming language and technologies.
>>>
>
> programming language: any that is truly cross platform, popular enough to
> attract a wide range of developers (easy to hire contractors), with
> ready-to-use open sourced modules for all common tasks (database, GUI,
> networking, scanning, printing, cryptography) - however, in a truly modular
> system with RPC APIs choice of programming language for individual modules
> becomes irrelevant
>
I am interested in the gnumed / minignumed experience here. From my
distant view, there seemed to be a constant tension between logic in
client, middleware and back end. As I understand it the favoured option
is that it should be in the middleware but in practice that appeared to
be problematic.
If the middleware co-ordinates everything presumably it will be written
in something "good". I doubt that it would be Perl. :-)
>>> Develop in Australia or India?
>>>
> develop *for* Australia. I made the big mistake with gnumed of wanting to
> make
> it flexible enough for multiple spoken languages and health systems.
>
It seemed like a good idea at the time. Horst, can you elaborate on
these difficulties?
> I am now paying several competent developers in Russia, Romania and Brazil
> (and even the US!) for small contracted modules (eg recently an appointment
> system widget) - they come *very* cheap, and you only pay once the specs are
> fulfilled
>
>
>>> How to make the project sustainable?
>>>
>
> by making it popular
>
by making it good.
David
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
