|
Page 2 of 2
The Power of Transparency
The process is transparent, so a CIO can see who is doing what. "Everybody sees the requirements and the code that is being developed because it's all on the Internet. It is much faster to get clarity on what is happening, what needs to happen and how it should happen, and it is probably easier to get consensus because the transparency takes away the tyranny of power."
Unlike a corporate meeting with high-powered SVPs who might intimidate a project manager, open source project requirements are usually on a wiki and the issues are easier to deal with. "It quickly becomes apparent to many people if things aren't happening," says Ziph.
CIOs can get a sense of an open source application by looking at the communications around it to see the date of the last update, how long it takes for changes to be accepted, and the community's level of enthusiasm. Again, a very different approach from buying a software package.
"If you see a lot of talk, a long road map, but no new features in the last three months, you might not want to participate," according to Ziph.
Because the source code for open source applications is there for anyone to see, users can adapt the systems or integrate them. Linux Box recently integrated an ERP, collection management and CRM system, "which meant working with three databases, two languages, and a different user interface," said Ziph. "The idea was to enter the customer information once and have it appear in all the other systems. You can collect inventory information from any system and it appears in the others. To buy a single application with all of this functionality would have cost millions. We put it together and will now give the glue to the community. The three pieces were all open source."
For open source to work, an organization needs developers who understand code and can fix things when they go wrong, or seek help from the community to get a patch, then test and apply it. The time to fix a problem is usually pretty short, because the IT department can draw on the community.
"You need new criteria for assessing quality, and you need policies for how to test, whom to trust," says Ziph. But vendor code might have problems that the seller won't disclose until the fix is complete; with open source the problems are identified and addressed quickly.
"You have to be engaged in a different way with the community," she says. "With open source, your constituency isn't just internal customers but your community and your peer group and you have to track a lot more things and you have to collaborate a lot more."
Most Linux Box clients turn their code over to the community, but some want to keep it private. Some pay the company a bonus when the code they write is accepted by the community.
"If a CIO decides as a matter of policy that the firm will require any code be given to the community, that places peer pressure on their developers," Ziph notes. "If you send it to the community for peer review and it is rejected, then you as the CIO know you have an issue to deal with. Suddenly you have the cooperation of a larger number of people reviewing the quality of your staff's code."
Only registered users can write comments. Please login or register.
|