X
Business

Open source coexisting with proprietary software

As IT managers warm up to open source deployments, there is a place for both proprietary and open source technologies within enterprises, say experts.
Written by Victoria Ho, Contributor

As open source technology increasingly penetrates enterprises, open source vendors are pushing their message to customers to convert from proprietary software. However, some industry observers see a place for both closed and open source deployments.

Daniel Ng, Red Hat's director of marketing, Asia-Pacific and Japan, said: "Companies can be 100 percent open source."

"Gain more by letting go so the community as a whole can benefit as the program will further evolve into a much better program than it was before," Ng said, referring to developers sharing code with the open source community.

Ng cited JP Morgan Chase as an example of a company that has embraced open source technology--the financial services firm opened its internally-developed messaging technology to the open source community.

Proprietary software products are much better documented than open source because of the volunteer nature of open source software development.
Ridhi Sawhney, IDC Asia-Pacific

Another benefit is cost savings, said Ng. Moving an enterprise's infrastructure to open source will reap savings of three to four times more than only moving the OS from Unix to the Linux platform, he said.

But Ridhi Sawhney, market analyst, Asia-Pacific software research, IDC Asia-Pacific, sees value in both types of software licenses. He said, while the open source community imparts benefits to open source software (OSS) such as lower total cost of ownership and that bugs are discovered and patched in a shorter time, it is the "volunteer" nature of the community which also lends weakness to OSS.

"Open source lacks reliable source of assistance when problems are encountered in an open source product. Proprietary software products are also much better documented than open source because of the volunteer nature of open source software development," said Sawhney.

Compatibility with existing proprietary infrastructure may also pose a barrier for enterprises. Sawhney said: "Some proprietary software is not compatible with open source. The competitiveness of OSS depends on its compatibility with existing proprietary solutions--a crucial strength or weakness."

But Martin Schneider, director of product marketing for SugarCRM does not see compatibility as a technology issue. "The only issues that can arise from hybrid environments [of proprietary and open source software] concerns license compatibility. After all, code is code regardless of it being open source or not.

"IT managers need to know what projects and products they have in place, and insure they are interoperable from a license perspective."

Schneider said the General Public License version 3 is helping to address non-interoperability barriers that come about from multiple licenses being written for one product, known as license proliferation.

"At the end of the day, code is code. If the open source projects prove their worth, they will survive and thrive," he said.

On the other hand, there are "mixed source" vendors such as Novell, which preach interoperability.

Grant Smith, business unit lead for open platform solutions, Novell Asia-Pacific, said the industry is warming up to the notion that both open source and proprietary systems "will inevitably need to co-exist [because] IT managers rarely believe in a one-size-fits-all philosophy".

Smith said: "There are certain areas where the best application or software tool is still proprietary because, for example, the product line is more customized and mature, and has gone through a long period of research, innovation and testing, or a certain company has been investing into developing the solutions."

Regardless of licensing, companies should focus on ensuring standards exist, said Smith. This allows enterprises to switch between proprietary and OSS, depending on which product is more mature at a given time of deployment.

He said IT managers should ask questions such as: "Will it plug into the relevant directory services? Will it authenticate? Will the management console manage various flavors of software? Can data be transmitted across the relevant protocols? Do industry standard connectors and collectors exist? Is the vendor willing to put development effort into integrating with competing and complementing product lines?"

"For CIOs, cost [of a deployment] is a one-time value. But risk mitigation and reduction of complexity will effect the entire project cycle, and CIOs are all very sensitive to these areas," he said.

Editorial standards