The Evil truth of Open Source Code Dependancies

Lurking... just beyond the shadows... lies an evil so hideous that...

Okay too dramatic. Still, there is an big problem that is cropping up more and more with many open source projects. It seems that in an effort to leverage existing open source code (which is good) we are creating a series of dependencies that make implementation daunting. Just look at the dependency list for the Apache Software Foundation's Ant. Ant is build tool, something programmers use to help compile and link a big program that has a lot of interdependent components. For all of you UNIX/Linux fans out there, think make on steroids. In any event, one look at the dependency list is enough to make a strong stomached open source supporter turn green. There are over 30 libraries and other related components, from nearly as many different sources, that are required to use Ant. Use, not compile.

The core problems with this type of system are:

• Complexity - The obvious problem. It's so difficult to get things installed and configured right that you go nuts


• Version Control - You now have to worry about what version of each dependant component you are dealing with. A change in a small library can break the whole system. Woe be to the programmer who uses an updated version of a component in his new application.


• Bloat - Open source used to have the advantage of being fairly lean. Not so anymore. This is not to say it's any more bloated than proprietary systems like Windows Server 2003. It's just not very different anymore in that respect


• Conflicts - So, you have applications that use different versions of some core component. Have fun working that out.

This is a good example of why people go with closed frameworks like .NET. Even though you are at the mercy of Microsoft, they at least do the heavy lifting for you. Dealing with all this complexity costs money. It costs in terms of system management and development time, as well as errors that decrease productivity.

Ultimately, these factors need to be worked into the open source cost structure. It's one thing when open source is used by hobbyists. They can get a charge out of monkeying around with code elements like that. For professionals, it's another story. They don't have time for this. What's the solution? One solution has been installers that put the whole stack plus applications languages on your system. Another option is to pull these components into a coherent framework like .NET . Then you can install just one item and get the whole package. Complexity and conflicts can be managed by a central project with proper version control for the entire framework. There are commercial frameworks that do this but we need an open source framework that ties together all open source components. Otherwise, open source development will be cease to penetrate the large scale enterprise software market.