gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Choice of programming language and project management (Wa


From: Andreas Tille
Subject: [Gnumed-devel] Choice of programming language and project management (Was: Phillip Eby of Python)
Date: Sat, 5 Sep 2009 08:10:47 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

[This is just a copy of a private mail exchange between some GNUmed
 people which seems me worth publishing on the GNUmed list.]

On Thu, Sep 03, 2009 at 05:11:11PM -0700, James Busser wrote:
> I value Andreas' perspective as a GNUmed collaborator without his being 
> "inside" GNUmed construction and so if he can think the link above has 
> also any more lessons for open source medical software and GNUmed in 
> particular us I would be interested in that too.
>
> I *think* on this project we are managing to be clear and consistent and 
> notwithstanding our tiny resources doing pretty ok?

Because you directly addressed me in person I think I should try to
answer.  This answer is by no means private and I would like you to
quote this at any place you feel reasonable.

IMHO it does not make much sense to question the tools / programming
language of your project.  Python has developed over years and can be
considered as one of the modern programming languages.  IMHO the hype
about Java (and I would put C# in the same category) is because it was
pushed to the masses and so they are perhaps more widely known by the
"masses" ... and here I mean really masses of *people* which are not
necessarily good *programmers*.  They just start coding after finding a
short intro of one of the programming languages with out really learning
programming.  I observed a similar effect with PHP: At some point in
time people were told PHP is the cool way to write dynamic web pages and
everybody who intended to have a cool web page started using PHP.

I don't say Java, C# or PHP are "bad" - they are just used by *a* *lot*
of bad programmers and these people tend to be very vocal about their
tools.  But lets leave this semi-professional field.  There are a lot of
other languages like Fortran, C, Perl, Lisp, Ocaml, Haskel, Ruby, Delphi
etc.  The main point is: You have to know your language.  Some languages
are more fit for certain purposes, some are outdated like Fortran, some
will never die like C and the concepts can be very different.  But
that's not so important for the success of a project.

IMHO the key point to success is rather a social skill: Gather a strong
team of people who are able to do professional programming.  My
favourite example is the comparison between Linux, BSD and Hurd.  There
is no question that very skilled C programmers are involved in all
projects.  All are aiming at the same target: Providing a free UNIX like
operating system.  But why is only Linux very well known and de facto
the synonym for Free Software - even if Linux would be nothing without
all the cool applications around?

If you ask me the answer is: It is the very great management skill of
the poeple involved.  While I think Hurd is technically superior it
kills itself because technical superiority does not lead to a product
release.  I have seen Hurd running (and was impressed by some features
which are not avialable in Linux) and I have seen the people working on
Hurd.  They are great programmers and they ask allways for very
complicated new features which delay the release until infinity.

I also have seen BSD and compared to Hurd it had a lot of releases.  And
it has a lot of forks a somehow closed circle of developers (which can
be good to keep not so skilled people out - but finally it is a closed
circle).  I do not want to weight Hurd, BSD and Linux as a technical
product (well, OK in the case of Hurd we do not even have a product).  I
know to few about BSD to compare it with Linux technically.  I just say:
Linux has successed in bringing the product to the market because its
open strategy and its successful management.

Coming back to the programming languages I have the impression that the
same is valid for Python.  It is hard to compare with Java because this
has a completely different background.  From a Debian perspective (which
might be valid for other Linux distros as well) I can say that Java has
not so many competent supporters / programmers because of its commercial
history.  The same is true for C# / Mono.  Even more than in Java I have
the impression that some of the "cool" (=semiprofessional) people I
mentioned above who bought their first programming language book and it
was by chance C# now learned about this cool new operating system Linux
and start hacking in Mono there.  (Don't missunderstand me - there are
*also* very professional C#/Mono programmers out there - but they are
harder to find.)  So we are just lacking experience in Java and C# in
the Linux world which in turn makes it not the optimal choice for a
project.

In short: I regard Python as a good choice for GNUmed.

But I did not wrote all this text only to say this: I have seen a *lot*
of projects who claimed to be able to manage medical records.  I think
only 20% of them survived (with continuos releases) until today.  I
don't think that in any case the choice of the tools was the problem.
The main problems were:
  - People were not able to *handle* the tools
  - Lack of project management

I have the impression that the key persons in GNUmed either know their
tools or - and that's also an important thing! - know what they don't
know and do not try to force some incompetent solutions into a product.

I have a not so good feeling about the ability of the GNUmed project to
gather fresh blood.  Yes, I know the reason that there are not so many
people with skills in programming and medicine hanging around and
waiting for an interesting task to do.  But as I said above (see Hurd -
BSD - Linux): It *is* a very important thing to actively manage a
community and sooner or later it is crucial for the success of a Free
Software project (even a small one).  In Debian we do measure this by
the "run over by bus factor".  Just ask try to answer the question: "How
many key people in our project can be hit by a bus before our project
dies."  If the answer is <=2 you will have a problem sooner or later.
(Note:  For instance becoming responsible for a child or learn that you
are enjoying fishing more than programming might have a similar effect
on the time you can spend on the project as if you were hit by a bus.)

Kind regards

     Andreas.

-- 
http://fam-tille.de
Klarmachen zum Ă„ndern!




reply via email to

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