Every company that develops software whether for internal use or to sell to customers is now working in a new "mixed-IP" environment created by the spread of Open Source. This new environment's impact on software development has been dramatic.

A mixed-IP environment means that virtually all software developed today is a mix of proprietary software and Open Source programming libraries. And while this environment has dramatically accelerated software development, it has also muddied the waters with respect to understanding the intellectual property (IP) ownership issues behind one's software assets. If you or your company develops software, you need to understand what's going on.

There's no arguing that the impact of Open Source on IT has been huge. The impact of Linux alone has been incredible, with IDC recently forecasting that the market for "desktops, servers, and packaged software running on Linux will exceed $35 billion by 2008." By anyone's standards, $35 billion is a lot of money.

But the impact that Open Source is having on software development is in many ways more dramatic that its impact on IT, yet it isn't talked about nearly as much. It's difficult to find out, for example, the dollar impact that Open Source programming libraries have had on software development. But while I don't know the exact number, I can tell you it too has been huge.

The Two Categories of Open Source
At a high level, Open Source code can be separated into two categories: full applications and programming libraries. This is illustrated in Figure 1.

From this figure, you can see how these two groups break down. Open Source applications are applications that you can use immediately to solve business problems. The Apache Web Server and Linux are great examples, but there are thousands of others that are less well known. These applications are reshaping the IT landscape by providing organizations of all kinds with free high-quality applications they can put to work immediately.

Open Source programming libraries, however, are less visible and less well known than the major Open Source applications. But in some ways, they are having an even greater impact. For example, while not every IT shop uses Linux yet, virtually every programmer today is using Open Source programming libraries.

Virtually every Java programmer, for example, uses Sun's JDK to write and run Java programs. Not all of them realize, however, that Sun's JDK includes copies of Open Source programming libraries for XML, XSLT, and XPATH processing. These programming libraries come from the Apache Software Foundation and are included at no cost in the JDK.

Sun includes these Open Source programming libraries in Java for the same reason that other companies use Open Source programming libraries - they are high-quality libraries with rich feature sets that can be used and distributed by them at no cost.

What would it cost Sun if it had to develop all this functionality internally? It would certainly be significant. Not only that, Sun would also lose the advantage of being able to use code that's already widely used and debugged. The Apache XML libraries are used by thousands of applications around the world and they're solid. It wouldn't make business sense for Sun to write XML processing libraries when these other libraries are available and free.

For the same reasons, it doesn't make sense for any other company to write XML processing libraries either. Why waste time writing XML processing libraries when your developers can be focusing on important things like implementing new features to solve important customer (or internal) problems?

And Java XML processing libraries are just the tip of the iceberg. Open Source programming libraries are available for virtually any programming problem today regardless of the language you program in. There are libraries available for building graphical interfaces, for processing complex math algorithms, for security, for e-mail processing, for generating reports and graphs, and for virtually any other common programming task.

The result of all this is that there has been a massive shift from programmers working on low-level development tasks to writing code that leverages Open Source libraries and focuses efforts on higher-value activities involving the actual business logic in their applications. The net result is that there have been huge gains in programmer productivity; programmers can now build applications dramatically faster. As a result, they can spend more time focusing on what their users need.

But these benefits haven't come without challenges. These challenges are related to understanding the IP ownership issues behind software assets.

Open Source's Impact on Software Assets
Before Open Source programming libraries were widely used, understanding the IP ownership of a software program was relatively simple. Basically, companies either developed all their own software or licensed source code from some third party. Figure 2 demonstrates this.

In any case, it was clear who owned what. Besides, they had contracts that spelled out exactly what their rights were with regard to the proprietary/licensed code they got from third parties.

Contrast this with the following Figure 3, which shows how software assets are structured now that companies are leveraging Open Source programming libraries.

As you can see, the Open Source libraries are now a core part of the software asset. The software asset requires these libraries to run; without them the software program doesn't work.

On the one hand, this dependency brings with it a significant increase in the productivity of the company's development staff. It can get much more done using Open Source libraries, but some dependencies are built into the application that weren't there before.

Besides increasing the productivity of a company's developers, using Open Source libraries can sometimes make it affordable to build applications that would otherwise cost so much to develop that they'd never get built. In these cases, accepting the dependencies on Open Source libraries is the only choice available.

On the other hand, these new dependencies raise some new questions. One important one is, "Who owns the software asset now?" The company owns the code it wrote itself, of course. And the proprietary/licensed IP is owned by whoever developed and licensed it to them. But now things are more complicated; who owns the Open Source programming libraries and how does that impact ownership and licensing of the software asset as a whole?