eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Its easy to think of source code as a product. Energetic and skillful people go into a room; tired people and lines of code come out. People routinely measure and even agonize over the lines of code produced per unit of programmer effort or calendar time. They truly seem to feel that writing more code means getting more done.
Thats an error that has always led to bad decisions, but in the era of open-source software, it merely paves the way for a more serious mistake. People start from the mistaken viewpoint of source code as product and follow a logical path to this flawed belief: that the worth of an open-source software effort is measured by the amount of code that it puts on display.
When viewable lines of code are the metric, enterprise developers rightly object that they dont have time to scrutinize hundreds of thousands of statements. They need to be building new value on their software foundations, not inspecting the components of those foundations to see how they were assembled. Hearing this, development managers conclude that open source is not a compelling proposition and that cost-of-ownership measures, some of which favor proprietary products, are the only important guide to their decisions.
Thats a compounded error that Id like to help these teams avoid.
Lines of code are input, not output, to a problem-solving process. Solving a problem in fewer lines of code by using a better algorithm or by choosing a higher-level language is adding value to a development effort—not taking it away. Does anyone disagree so far?
It follows that the enterprise value of an open-source software effort is not measured by the lines of code that it exposes to the scrutiny of a development team. That scrutiny is a cost, not a benefit, to any business goal—unless the companys business is the support of an open-source software product, but thats a special case.
In any more typical enterprise, the net worth of code is the value of the functions that it can perform, minus the cost of developers reading and writing lines of source. Repeat after me: Any touches to source code are an input, not an output. Ideally, therefore, no one touches the source code at all.
So, if no one touches the source, why does open source matter?
Because the open-source format preserves flexibility for future change and guarantees that problems can be addressed as soon as the user organization needs them to be—not according to the convenience of the vendor. Open source is change insurance—and change, unlike most of the things that we insure against, is not a mere risk but a certainty.
When source is available to anyone who cares to look at it, the effort and cost involved in fixing bugs and enhancing functions are priced by a free market instead of a monopoly. When that happens, it changes the essential function of the enterprise development team.
What got me thinking along these lines was my conversation with Simon Phipps, chief technology evangelist with Sun Microsystems, following his much-anticipated keynote speech at this months EclipseCon gathering in Anaheim, Calif.
“I think that open source is shifting the skill of being a developer,” Phipps asserted, “from editing code to being an editor in chief.” After years of industry speculation about an emerging marketplace for reusable software objects, Phipps suggested, “What we see in open source is finally the promise of reuse in a real way.”
Phipps offered Suns own Java Desktop System as an example: “A company that didnt have a staff with 20 years experience in Unix could not have made JDS,” he argued, “but the skill did not go into writing lines of code; the skill went into being an editor, deciding what to choose and what not to choose, knowing how to configure what we did choose, knowing what pieces of code actually did need writing.”
It sounds like a paradox, but the best reason for exposing source code is to give an enterprise development team the freedom to rise above it—and to focus on what they actually want to achieve.
Technology Editor Peter Coffees e-mail address is peter_coffee@ziffdavis.com.