In-Depth

It works when a developer gets stuck

• By Alan Joch
• February 1, 2005

According to open-source development veterans, the collaboration model offers several technical advantages, but by no means guarantees success. For open-source development to work, experts offer the following suggestions:

Adopt public-domain code carefully.
Even though a larger development community may validate open-source code, La Quinta’s Internet technologies division treats the software as if it’s running it for the first time. The company runs code developed out-of-house through a full suite of regression, load cycle, quality assurance and functional tests using commercial testing tools. As an extra safety measure, the division runs production systems with open-source software that’s a revision or two behind the current release to give bugs and bug fixes time to become public. “We’re not a bleeding-edge production shop, although we are downloading the latest betas or alphas so we’re always in the know about the newest technologies,” Raven Zachary, director of Internet technologies, says.

Clearly define code specifications.
The open-source approach doesn’t eliminate project management skills that all development projects require, says Jorg Janke, principal of Compiere, Monroe, Conn., developer of the Compiere ERP open-source application. “We found most of the collaboration that happens with open-source development concentrates around coding,” Janke says. “Because today’s development tools are so productive, coding may represent only about 10 percent of the development effort. The rest of the work is focused on project specification and definition.”

For the collaborative model to work, define product specifications.
“The objective should be to meet the spec, not to have a big discussion about what should be achieved,” according to Janke. Vague specs can turn code collaboration into a nightmare, he adds. “When it comes to vaguely defined software, the only way to get proper collaboration is to turn to very traditional development practices: defining the scope of the project, defining the APIs, defining the time frame, and then splitting up the work,” Janke says.

“What does work is when developers communicate by saying something like, ‘Hey, I’m stuck here, does anyone have any ideas?”