SAN DIEGO--Developers working on open-source projects for business need to develop new ways of approaching the business issues of software development.

They need to be careful where they get code that they believe to be open source, to be sure the code doesn't have licensing provisions that can cost their employers money in the future, cautioned Mark Rankin, director of research and development and a research fellow at ADP Dealer Services.

He also said developers need to get used to the idea that they can count on getting some--but not all--of their tech support from the open-source community. And they need to give back to the open-source community, by donating code to open source so that other organizations can use it.

Rankin offered this advice as part of presentation Wednesday about ADP Dealer Services' experiences migrating to open source at the Burton Group Catalyst North America conference here, which was co-sponsored by InformationWeek and a sister publication, Network Computing.

ADP Dealer Services provides line-of-business computing systems to car and truck dealerships. The parent company provides technology including servers, and IP telephony; ADP Dealer Services focuses on applications, offering modules for accounting, reporting, finances, insurance, human resources, parts inventory and forecasting, and scheduling. Revenue for the business unit is about $1 billion, and for the parent, about $8 billion, Rankin said. The company's customers range from mom-and-pop car dealerships with 15 to 30 employees up to multibillion-dollar corporations.

ADP's legacy software runs on Unix platforms--60% Linux and the remainder Digital Equipment Tru64 Unix running on Alpha processors. It's a green-screen application written in an antique programming language, Pick Basic, with SNA and X.25 networking. The company's main competitor runs on the same technology.

ADP has been gradually replacing the applications, using mostly open-source components. The company chose to use the PHP scripting language, in part because of its support from IBM and Oracle. They used PostgreSQL, with a front end consisting mostly of HTML and JavaScript. "Where we needed a little more oomph, we used managed controls and .Net framework on the side," Rankin said.

Lessons Learned

The migration has been successful, but it required developers to learn some new habits, he said.

Intellectual property and open-source licensing were big concerns, requiring the developers to involve ADP's legal department closely in the development process. "It screws with lawyers' heads," Rankin said. Lawyers look at free software as too good to be true. Lawyers have difficulty understanding technology, and software developers have trouble understanding the law. "Engineers are not lawyers, and lawyers are not engineers," he noted.

ADP avoids using code licensed using the General Public License, which governs the terms and conditions for modifying and distributing Linux and other open-source projects. The reason: the license requires developers who modify GPL code to make the modified code public under the GPL, effectively giving up their intellectual property. Instead, the company uses the BSD open-source license, based on the open-source Berkeley Software Distribution Unix, which allows developers to keep modified code proprietary.

ADP also learned that developers need to be educated not to download code from the Internet without informing managers, and to be sure the code is properly open-source licensed before incorporating it into proprietary software, Rankin said.

"That's huge," said analyst Richard Monson-Haefel of the Burton Group "Developers will take tools and pieces off the Internet, and you really have to have strict policy that everything has to pass through a policy check to make sure it doesn't have licenses you're not familiar with."

Companies need to be prepared to demonstrate diligence, to show that they worked to keep other people's intellectual property out of their software, Rankin said.

Companies can avoid intellectual property hassles by using software from vendors like IBM that indemnify customers, Monson-Haefel said. The catch is that those companies' indemnification is voided if the user modifies the code, which eliminates one of the main benefits of open source.

Another reason why companies need to think carefully about whether they want to modify, or "fork," open-source code for internal use, is that it entails the risk of losing support of the open-source community, Rankin said. "If you fork it, and the community doesn't like what you did, you're going to own those changes the rest of your natural life."

For cases where the open-source community can't or won't provide technical support, companies should find vendors willing to support open-source products. ADP uses IBM to support Linux, Zend to support PHP, and Command Prompt for PostgreSQL.

The open-source community can be counted on for support in some areas. But other projects are uninteresting to the open-source community, and companies will have to either do those projects themselves or hire vendors to do the work. For example, the original Postgres database allows users to see all the tables in the database, and doesn't permit the user to filter the view. That was seen by some at ADP as a security risk, and it was definitely an inconvenience, resulting in information overload. The open-source community wasn't willing to fix the problem, so ADP had to hire Command Prompt to fix the problem, which the vendor was willing to do for a modest sum, Rankin said, about $3,500.