Geeks With Blogs


Add to Google

Tim Hibbard CEO for EnGraph software

I've thought about posting this for a while now and responses to my architecture post by Dave and Dru have got me thinking about it again.

I avoid open source frameworks or libraries in our production desktop applications.  I don't have a problem with third party when it comes to web applications or internal apps.  I use AjaxPro and skmRSS on Where's Tim and my home site.  I use Indy.Sockets all the time in our internal apps.

Where's Tim is just for fun though and if it goes down, it's not that big of a deal.  And our internal apps mostly just automate things that could still be done manually.  When it comes to production applications, the apps that pay my salary, I get a bit possessive over what we deliver.  ParaPlan isn't a helper application.  It's is an agency's backbone.  Our client's entire lifecycle of doing business is generated by, or inputted into ParaPlan.  If our software runs into a bug and one person can't do their job, then everybody else's job is impacted by it.  Kyle and I give all of our clients our cell phone numbers, and when something goes wrong, we get called and they have to pause their operation until we get it fixed.

For me to properly support our clients, and to keep my cell phone minutes under the allotted bucket, I need to understand everything that our code is doing.  I don't feel comfortable using third party code because I don't always know the author's true intentions.  Generally, it is intuitive and 99% of the time, it works.  But I don't like taking the chance that it might not.  We also have unit tests and pre-deployment processes that should catch most problems, but just because it worked on my machine and it compiled on the build machine doesn't mean it's rock solid.  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.  And I don't to be the one trying to explain to the client why I used somebody else's code and that's why they can't do their job. 

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.

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.  That might mean that it initially takes me longer to push something out the door, but it makes me smarter and more valuable to EnGraph. The next time I'm faced with a similar problem, I'll be able to use the knowledge that I learned instead of throwing a third party library at it.

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

In no way is this a knock against people that consume or develop open source libraries.  I'm not scared of proprietary information, I post my code all the time.  I also pick apart code from open source libraries to understand what they are trying to accomplish.  I think the open source community is a great thing.  It's just not something I want to use.


Posted on Monday, May 7, 2007 2:19 PM .NET , Where's Tim , Goldstar | Back to top

Comments on this post: Why I don't use open source in production desktop apps

# re: Why I don't use open source in production desktop apps
Requesting Gravatar...
You can still push your developer skills to the limit while leveraging open source libraries. You will just become more powerful. Having code already prebuilt for you lets you concentrate more on higher level features within the same time frame. Letting you create more robust architecture and not get yourself bogged down with nuts and bolts. You dont want to be the nuts and bolts guy. You want to tell the nuts and bolts guys what to do. The present and the future is one of peicing together prebuilt parts and thats extrememly skillfull in itself. The future of that will be DSLs and Software Factories, if you keep nutting and bolting away you might end up driving a bus.
Left by The J Man on May 07, 2007 2:30 PM

# re: Why I don't use open source in production desktop apps
Requesting Gravatar...
J Man,
Ironic that you would refer to driving a bus as our software manage people-moving fleets!
Anyways, I understand your point, but I still need to understand what the nuts and bolts do. If the nut breaks, and I (or somebody in my company) didn't write it, then our time to solution just escalated unnecessarily.
Truth be told, I write code all the time that depends on a third party library, the .NET framework. But that has been put through vigorous testing to ensure that the nuts are going to do what the nuts are supposed to do without exception.

Left by Tim Hibbard on May 07, 2007 2:44 PM

# re: Why I don't use open source in production desktop apps
Requesting Gravatar...
Hmmm... interesting post. But I've gotta disagree with you (shocker!, hehe). If you're using open source code and you're having issues with it, you can, um, open... the... source... and, um, possibly make the fix. That's not much different than trying to figure out your own code from 6 months ago, or code that someone else on your team wrote.

And The J Man is right... building software is moving to 50% knowing what already exists, 40% knowing how to put it together, and 10% stuff you write yourself. You can still be a nuts and bolts guy in that world, so you shouldn't worry about that.

Also, just because it's not from Microsoft doesn't mean you shouldn't use it.
Left by Dave Donaldson on May 07, 2007 3:03 PM

# re: Why I don't use open source in production desktop apps
Requesting Gravatar...
You are absolutely correct about being able to change open source code (obviously!). And assuming that the code is well documented and the author's intent is clear, it's probably not that big of deal to customize the code for your purposes. With CSLA, Spring.NET and NHibernate, I'm sure that enough community support exists to make these customizations relatively pain free.

I'm just not ready to bet the farm on it yet. We are already taking an ROI risk in porting our flagship app to .NET because we are a small shop and it's taking me a lot longer to push it out the door than originally anticipated. I don't want to delay it any longer because somebody else's code didn't play nicely with a client's configuration.

Maybe once we have a couple rock solid iterations in the bag, I'll feel more comfortable introducing open source stuff. I really like the AOP stuff that Spring.NET enables.
Left by Tim Hibbard on May 07, 2007 3:34 PM

# re: Why I don't use open source in production desktop apps
Requesting Gravatar...
The funny thing is, personal custom code is the most open source of open sources, it is V1 by default. Every line of code the open source guy wrote was time spend thinking and googling and building and testing.. even if the guy just did a V1 pass on it. People get killed with Open Source when they dont open the source. Its like editing a book that was already written instead of writing a new book.
Left by J Man on May 07, 2007 3:41 PM

# re: Why I don't use open source in production desktop apps
Requesting Gravatar...
Indy is a bad word where I come from ;)
Left by Lance on May 07, 2007 4:38 PM

# re: Why I don't use open source in production desktop apps
Requesting Gravatar...
I agree mostly with this position to avoid 3rd party libraries for critical desktop apps. However, there is still a big tradeoff, because you are sometimes reinventing the wheel. What I do is make sure to use the library or code in non-critical or test apps for a good long time until it proves itself, and also keep tabs on the community feedback and usage. This doesn't take so much effort. With my C# work this is more reliable than with my PHP work. I often try and subsequently reject many PHP packages before finding any that work the way I want, and I end up distrusting them even then. In that context, I am more in agreement with the attitude posted here. Also, my C# tools allow me to identify a 3rd party library as the problem, and I make sure I can get under the hood, have source on hand, etc., which makes 3rd party code usage much more secure. It's all in how one approaches the problem.
Left by Bob Dickow on Jul 10, 2015 5:08 PM

Your comment:
 (will show your gravatar)

Copyright © Tim Hibbard | Powered by: