The Dark Side of the Source

One of the great benefits of using open-source, or any source-available software in general, is that, well, you have the source. If you run into a problem then you can debug right into the source-code of your third-party libraries and figure out what's going on. Fantastic. As a consultant on the road I welcome the ability to dive deep.

However, there is a dark side to source code availability: you can get sucked in very easily debugging code that isn't yours. Think about that. You encounter a bug, and, instead of having X lines of code to debug (where X is the number of lines of application code) you've got X + Y lines of code to debug (where Y is the number of of open-source lines of code). Now, the extra lines of code (Y) may give you greater visibility in solving your problem. Or, you may end up loosing time trying to figure out somebody elses code: I call this "The Dark Side of the Source". Recently, I found myself deep in code involving Jetty Continuations, and lost a lot of time trying to figure out what was going on. In the end we had to get directly in touch with the code author to get a fix: if only we'd known to go their first!

So: having the source is great. But don't assume that just because you have the source you can solve all the problems all the time: the source will help you, but you have to be mindful of the impact on your productivity. Go with an open source community that can help you if you get into trouble, and one that gives you a professional support offering for when you get into deeper trouble. The guys at Redmonk (Michael Cote and Stephen O'Grady) have written a nice paper on this - "Working with Open-Source Companies". I got the paper for free from the open.iona.com communities site; I recommend the read.