Should you join the open-source software movement? A session at the recent 2011 Computer Assisted Radiology and Surgery (CARS) congress in Berlin addressed a question that legions of IT and developer types in medical facilities around the world have pondered themselves when they discovered their software didn't do what they needed it to do. The presenter considered it a great idea, actually, and outlined a way for interested medical researchers to try their hand at open-source software development.
And why not? Open-source has gone mainstream. It's abundant, it's available, and in the research community it seems everyone is using it. Even corporations have gotten into the game -- Dell is now offering a workstation with an open-source software option. Medical IT people around the world have built applications successfully for their departments, while others have tweaked someone else's open-source application to make their stuff run better.
With luck and pluck you could become something of a rock star in your interventional radiology or surgery department when you roll out custom-designed software that runs your robots perfectly but didn't have to be built from scratch, according to Kevin Cleary, PhD, who knows a thing or two about the process.
With time your software could even become the go-to standard in your medical niche, bringing you new users and a measure of fame -- though not usually fortune. At the least you will free yourself from having to redevelop the same software every time a graduate student who writes a program leaves your department.
Reinventing the wheel
Why should you be interested in open-source if you're running a research lab? Because if your group builds hardware for anything in medicine from robotics to drug delivery devices, you'll find it needs software.
"Typically, we have a graduate student who does a project, writes his software, leaves the lab, new student comes in and looks at the software and says, 'I can't make any headway at all with this software,' and they start again from scratch," said Cleary, who is the technical director and lead principal investigator of the Bioengineering Initiative of the Institute for Pediatric Surgical Innovation at Children's National Medical Center in Washington, DC.
Among its many strengths, open-source software helps research departments avoid reinventing the wheel and also allows them to build on the knowledge they create for each successive set of users.
"I also wanted quality software," Cleary said. "Since graduate students weren't typically professional software developers, I wanted to put a live process in place that would help build up a code base over time."
The U.S. National Institutes of Health (NIH) actually started funding open source four or five years ago -- and now if you have a large NIH project, the agency requires you to make your results public, including some of the source code, Cleary said.
"You really can't underestimate the effort required for a successful open-source project," he said. "A student can write the code and get the job done, but when you start looking at the overhead of putting in a software development process and having people review the code, the code is a lot better but it takes a lot of time and effort. But if you have a common infrastructure that you develop over the years and want to continue to put in your prototypes, then it really makes sense."
The price of success
Your lab's open-source project needs a champion -- someone who is passionate about the project and can share that enthusiasm with others, Cleary said. It needs a strong manager who can see the big picture, identify milestones, ease the way through conflicts, and keep the group focused. And it needs strong programmers.
"You need people who are skilled in object-oriented methodology, design patterns, and state-of-the-art software development to be part of the team," he said. In the medical field when you talk to doctors, they'll tell you in general terms what they'd like to be able to do. But it's up to your development team to define the precise engineering requirements for those tools and build them, he said.
According to Cleary, you'll need the following to make your project successful:
- A community with a common vision
- Talented and motivated developers and scientists
- A mix of academic and commercial participants
- An organized, lightweight approach to software development
- A leadership structure and good communication skills
- A business model for sustainability
For managers, people skills are as important as technical skills, he said. You have to define your project requirements to meet the goal, then break the task into pieces, Cleary said. "The development model that we use is called 'agile' or 'extreme' programming, where you have a sequence of small iterations in programming, and the idea is to get the first shell of your project up and running as soon as possible, and work from there."
A "lightweight" development process seems to be what works best in the medical field, ensuring adaptability to changing needs and nimbleness that allows important tasks to be reprioritized on short notice. The manager will set the schedule and milestones, track progress, and hold weekly or biweekly conference calls, occasionally real meetings, Cleary said. "Normally, we have a developer's mailing list and a user mailing list, and we kind of separate the two," he said.
Starting up
Once the goals are defined and the development community recruited, you'll need open-source applications to use and adapt to your needs, Cleary said.
That involves licensing source code from a company that develops tools similar to the ones you'll need, said Cleary, who has been working with Clifton Park, NY-based Kitware since 2002, licensing its VTK (Visualization Toolkit) and ITK (Insight Segmentation and Registration Toolkit). His group has adapted these mature open-source software applications into its own suite of tools known as IGSTK (Image Guided Surgery Toolkit). The open-source software library, introduced in 2006, is based on the C++ programming language and has a dedicated user base of perhaps 10 facilities, Cleary said.
Notably, Cleary's user base pays no fees to license the software for their own use, and indeed Kitware received no money for the licensing of Cleary's research group to use its VTK and ITK tools, he said. "They make their money on consulting" on the use of their software tools, said Cleary, who estimates that the firm has more than 50 employees.
In addition to IGSTK, popular toolkits geared to different medical specialties and tasks include the following:
- MARVIN -- University of Bern MEM Research Center, Bern, Switzerland
- CISST -- Engineering Research Center, Johns Hopkins University, Baltimore
- MITK -- German Cancer Research Center, Heidelberg
- OpenMAF -- Institute of Orthopedic Research, Bologna, Italy
- Slice-IGT -- Brigham and Women's Hospital, Boston
For example, Cleary's IGSTK toolkit supports multiple medical trackers for use in navigation, biopsy, and surgery applications, he said. MITK's software can help you build graphic user interfaces (GUIs). OpenMAF offers an interface manager to integrate input and output devices, including trackers, haptics applications, and stereoscopic displays.
Many toolkits run on multiple platforms, commonly Windows, Mac OS X, Linux, and UNIX. "Running on different compilers can actually help you shake out bugs in your software," Cleary said. "But not everything we do runs on all the compilers."
You'll need servers, including a source-code control system, to support your project, he said. There is open-source software for software version control, checking code, and more. The coding guidelines help make the software look like it's written by a single person, and style-checker tools ensure a uniform style.
"You don't want any one person to think he owns the software -- you want the software to be owned by the team," Cleary said.
"A lot of open-source development is about the tools you use," he said. "You want to change them as soon as possible," adapting their function to your own requirements, "but then you want to kind of lock down your process once it's set."
The following are involved in the middle stages of development:
- Establishing an orderly new version release mechanism
- Crafting policies to add new developers
- Establishing a backward compatibility policy for new versions
- Creating procedures to add new features without "breaking the code base" and losing backward compatibility
If you're successful to this point you'll also be seeding "Web buzz" about your project, creating tutorials to help users use it, and writing papers, Cleary said. You'll be developing policies to foster community involvement and feedback.
By the time your project gets to the mature phase, your product has a real user base that counts on its reliability. Therefore the codes, tools, and processes "should be hard to change," he said.
"Successful open-source projects rely on the community," Cleary said. "For one, it helps set the requirements. If you just poll your lab, you'll find one set of requirements, but if you poll a couple labs, you might find a larger set of requirements," he said. The community can also help you find bugs in the code, which is helpful even for mature, well-run projects.
Development and licensing
The main point of open-source software isn't that it's free -- though it often is -- it's that the source code is available, Cleary said. "What open-source advocates really want is what they call 'software freedom' -- the ability to take the code, modify it for their purpose, and include it with other code," sharing your own contributions if you want, he said.
The Open Source Initiative licenses software that follows a series of related guidelines, stipulating free redistribution of software, source code included with software, permitting derived or modified versions of the software, maintaining the integrity of the author's source code, and not discriminating in the selection of who may use the software. For example, Cleary said, an open-source developer cannot bar weapons developers from using his software, or limit the software to any particular use.
An open-source license is way of granting others the right to use an application to ensure software freedom, Cleary said. With a nod to Lawrence Rosen's Open Source Licensing, Cleary outlined the various license types:
Academic licenses allow the software to be used for any purpose whatsoever with no obligation for the user to distribute the source code of derivative applications. The Berkeley Software Distribution (BSD) license, used by the University of California, is the archetypal academic license, a form of which Cleary and his team use to license the IGSTK toolkit.
"If you do derivative work you don't have to distribute it," Cleary said. "That's important for companies because if a company wants to take an open-source product and put it in their code, they might want to put some proprietary code or patented algorithm in there, and they obviously don't want to have to distribute that. So most licenses now let the company use the code, and you don't have to contribute your work back."
Reciprocal licenses allow software to be used for any purpose, but they require the developers of derivative works to distribute those works under the same license, including the requirement that the source code of derivative works be published. Reciprocal works are the opposite of academic licenses because the developer is obligated to distribute his code, Cleary said.
Standard licenses are used to ensure that industry-standard software and documentation are available for the implementation of standard products.
Content licenses stipulate that copyrightable subject matter that is not part of the software code be available to use for any purpose.
"The reason for all this stuff is that no one can come back and stop us from doing it, or in the U.S., sue us for doing it," Cleary said.
