Editor’s note: this post makes excellent points and obviously speaks from experience, but it was posted anonymously which means no sugar coating: People who try to ‘get out in front’ and lead the Open Source
community are not helping it. The Open Source community is a
Meritocracy, where your responsibility and status are determined
by your programming output. Doctors who want to head up projects with
little programming knowledge and less programming experience won’t attract
Real Programmers to do their bidding.

Executive Summary

The Open Source Movement is about source code. People who
can’t program should get out of the way.

[Note: Real Programmers are
experienced programmers that are 100 times more efficient than average
programmers. Think Carl Lewis vs Roseanne. ]

Let’s break it down this way:

1) You are a real programmer and you want to start a project from
scratch. Go read ESR’s papers. You
need a working program that’s useful to you first. No one can tell if
you are a real programmer if you don’t have code. In fact, you
can’t be a real programmer without the code to prove it.

Your goal is not to get people to follow you and write your
software. People don’t like being exploited. People will follow you if you
are already going somewhere and doing something useful. [ Proof: Stand
up in a crowd and say “I want to be your leader and you should all follow
me.” Wonder why people followed Ghandi, but not you. ]

When you are a project leader, people will add to your program and send
you the results. Your job is NOT to incorporate them all. Your job
is to evaluate them. If it’s a good feature and it’s good code,
then you incorporate the code. If the code is bad, you can rewrite it
yourself, or send it back to the author. If your criticisms are valid,
the author will be happy to rewrite it the way you want it. After all, the
author wants to feel useful. If a contribution is accepted, that means the
author is trustworthy, and you should incorporate him in the project
decisions. You may even break off a piece of the project and give him
responsability for it. If there are disputes, they are settled in the
‘pecking order’. You are at the top, the others are valued according to
their contributions.

2) You are a computer novice and/or you think you can program. Of
course, you want to start a project from scratch because it’s no fun
following others. You assume that real programmers will tell you what to
do to make the project better. The problem is that you can’t tell
a real programmer from a self-inflated poser windbag. You will get good
suggestions and bad suggestions, but you won’t have the experience to know
which are which. Even worse, real programmers will instantly detect that
you don’t know what you are doing and leave. They can detect you, but you
can’t always detect them. [ Proof: Build a house without plans. Try to
detect which of the passers-by are expert builders. See how many expert
builders detect that you aren’t one of them. ]

Your best bet is to join an existing/established project and
contribute as best as you can. Even as a novice programmer, you
can point out errors in the documentation, write a FAQ, ask intelligent
questions, find bugs, etc. If you have valuable contributions, you
will be recognized as one of the contributors to the project, and you will
gain experience and be allowed leadership. Only after you have experience
can you consider yourself a real programmer. Warning: Not
everyone who wants/likes to program can become a good programmer. If a
project leader dumps on your ideas, remember that they are
experienced, and you are not. [ Proof: A Zen student wants to “hurry up
and figure out what this Zen thing is already”. The master laughs. Should
the student resent the master? ]

3) You are a doctor and you want to help out. First, admit that
you are not a programmer, and you couldn’t tell a real programmer from a
dorky kid with glasses. Don’t try to program any more than you would try
to rebuild your car’s engine. You don’t have the tools or the expertise,
and you will make a mess that even an expert wouldn’t touch.

Next, recognize that the medical profession isn’t likely to drive
breakthroughs in technology. (Sometimes, as with MRIs, they do, but
not real often.) When it comes to computers, doctors are way
behind. [Proof: Go to a hospital ward or outpatient clinic and count the
number of staff with and without a computer. Go to a ‘conservative’ bank
and try to find an employee without a computer. ]

You have heard about these “.coms” doing “e-business” and making
everything computerized and you want a piece of the new-fangled
action. But recognize that all that glitz was built on 10-30 year-old
technology (TCP/IP, UNIX, e-mail, Databases, perl, the Web). [Note: The
first 3 were started in the 60’s. Perl was written in the mid 80’s. The
Web was invented in 1989. Great, now I feel old. ] Ignore the latest
buzzwords — they are for the computer people, not for you.

If you want to help, do some thinking and write down what you
want. Remember, Thinking Is Hard. Writing down the first thing that
pops into your mind won’t help (“I think it should be user
friendly”). Don’t tell programmers what to do (“It should be done in Java
and XML because I hear those buzzwords a lot”). Be pragmatic and practical
(Would you have a highly skilled nurse do data entry? What if it increased
the accuracy of the information?) Recognize that almost no vendors have a
useful EMR system, and the few places that have one can’t replicate it
elsewhere. [ Quiz: What do Motorola, Intel, Kodak, 3M, Bell & Howell and
Siemens have in common? They all have health care divisions, and
most are churning out useless software like there’s no tomorrow. None are
known for their good programming. Few are likely to attract good
programmers, when good programmers can go work for .coms. They all have
enough money to write junk and just ‘see what sticks’. ]

Your best bet is to give a dose of reality to programmers. Programmers
assume that everyone can type, everyone knows how to navigate a file
system, etc. If you have experience with an EMR, write up your thoughts,
both good and bad. Is it unrealistic to ask for exact hospitalization
dates because few patients remember them? Is it more useful to have large
friendly icons for navigation or an information-packed control panel that
shows at a glance what you need know? What information do you need
on the screen at all times? Would you rather see a list of 100’s of tests
performed on the patient, or a short clinically relevant summary? Would
you rather have items sorted by date (episode) or by type (type of test)?
(hint: neither is right.) Do you want to enter a lot of data so you can
see it later (the computer is just like a chart), or do you want to enter
a little data so it can help you track and manage your patients (the
computer can do more than a chart ever could)?

Writing a program isn’t hard, but making a program useful is. (In
exactly the same way that firing a gun is easier than aiming a gun.) Ok,
this is degrading into a rant because I’ve run out of useful things to
say. [ Proof: Try to find my last point. ] Here’s some tips:

• Do fund open source software developers. No, don’t stuff
  cash in an envelope. Hire some random techies to investigate open
  source software. See if you can devote a departmental server to be a
  source code mirror. Donate old hardware to promising projects. Grill your
  software vendors on interoperability issues (“Does your software work on
  my mac and my daughter’s Linux box?”)

• Don’t try to start a programming project. Leave the
  programming to the programmers and we won’t try to see your
  patients. Thank you.

• Don’t try to control an existing project either. You can make
  suggestions, but don’t get angry if no one follows you.

• Do start a web page, but recognize that it won’t help
  much with writing software. It may help people doing google searches.

• Don’t try to co-opt open source by doing something that
  doesn’t involve source code. The “Source” in “Open Source” refers to
  source code, not some abstract ‘source of all that is good in the
  universe’. You can label it “Open Wishful Thinking” or something. [ Tip: I
  hear that the “Power” and “Active” buzzwords are under-utilized this
  week. ]

• Do understand that sarcasm rules the net.

• Do accept that programmers look down on techie doctors in
  exactly the same way that doctors look down on patients who say “But I
  just read about a new experimental drug that they got to work on lab rats
  once.”

• Do download software and send e-mail to the authors with
  suggestions. But be aware that some software tries to solve
  issues that you don’t understand yet (but will).

• Don’t write anything without the net in mind. The GUI wars are
  over. The Web has won. Things that are not web applications better have a
  darn good reason for doing so. Things that do not store their data in a
  database should be taken out back and shot. Hint: My/mSQL are not real databases.

• Don’t think “Programming can’t be that hard”. Any attempt to
  dumb it down (e.g. Visual Basic) should be looked at with the same disdain
  as a “Do-It-Yourself Surgery Kit” or attempts to “fix” the fact that
  people drop out of med school. Programming is hard in exactly the same way
  that saving someone’s life is hard.

• Do investigate wireless. 802.11b is your friend. [ Hint: All
  the cards are really made by Lucent. ]

• Don’t think that a PalmPilot would be the perfect tool if only
  it had decent medical software. Graphitti is slow, carrying around a
  keyboard sucks, the screen is too small, it has a proprietary OS and the
  handspring port is proprietary. Don’t hold your breath for WinCE
  either.

Signed,

A Real Programmer (TM) sick of all the useless “follow me, I’m
clueless and I’ve got a plan” projects.