Open Source Projects

My friend Tim Hibbard recently posted why he doesn't use open source code in production applications. Now it is known to most people that I am a huge believer in Open Source Software, (I have even been told that I live and die by it) so I feel compelled to respond to his recent post. I am going to go through the post and respond to the bits that get me the most rilled up.

"I don't feel comfortable using third party code because I don't always know the author's true intentions. "

...

"The third reason why I avoid open source is purely selfish.  I want to be the best developer I can be, and I would rather learn how to code the functionality than use somebody else's code. "

This seems to me a large "Not Invented Here" problem, I totally understand that larger open source projects can seem incomprehensible, but trust me when I say you will eventually understand what is going on, and what the intentions are, but it does take some investment of time. We all suffer from NIH from time to time, but learn to notice this behavior and stomp on it like the little pest it is.

I would also like all people to take a look at some of the better run open source projects like NHibernate. It has commercial grade support options, it used on large scale production systems, includes very verbose logging, has lots of users and developers, and enjoys multiple books since its API is so similar to the Hibernate API.

...just because it worked on my machine and it compiled on the build machine doesn't mean it's rock solid. 

Well, I understand but it is my hope that one can make rock solid code, even if it uses third party code. I run my tests on my development machine, and my build machine which tends to be enough. I do however deploy to one server and no desktops. If I was going to I would probably look into setting up some kind of VPC to test the different operating systems.

I don't want to be staring at a function at 9:00 PM on a Friday wondering why it's not working on a client's machine and trying to determine if it's my fault or a third party's library's fault.

This is true of the .Net framework itself and is not the best of arguments. Developers have a lot of tools in production environments including logging, tracing, and of course playing with the code itself. So, I don't really find this to be a compelling argument.

This is why Seperation of Concerns is such an important concept. If your code is not cleary seperated then this can be a big problem, but if your code is nice and orthogonal then these problems become much less of an issue.

I also feel that third party library's can limit your scalability.  It's just another link in the dependency chain that could be broken as you adapt new technology.

I guess my first question would be, what do you mean by scalable? Third party code can greatly increase your ability to scale code production by not having to write the code yourself. If you are talking about performance, I would be wary of optimizing your code to early.

I do use the Enterprise Library in my production apps.  I feel better knowing that it is delivered by Microsoft.

Ok, this is just my opinion but the Enterprise Library is just too darn complex. There are better implementations just about everywhere. It may be that my needs are to simple to necessitate the use of the EntLib. But if you need those features I would encourage you to look elsewhere.

Microsoft is not the end all of code development, after all we are all developers. And we all want people to use our products. There are a lot of high quality open source projects out there, and all I ask is that you give them a real shot.

In closing, Tim I love ya', you make me think and challange the beliefs I have in software development. Know that I wish you nothing but the best.