[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Choice of programming language and project management (Wa
[Gnumed-devel] Choice of programming language and project management (Was: Phillip Eby of Python)
Sat, 5 Sep 2009 08:10:47 +0200
[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
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.)
Klarmachen zum Ändern!