A lot of people have asked me why we don't use third-party assemblies in BlogEngine.NET, so I thought it was about time to explain why.
One of the most important rules that I laid down before starting on the BlogEngine.NET project, was that no third-party assemblies were allowed. This rule was forged out of the assumption that most of these assemblies did a whole lot when only a little bit was needed for BlogEngine.NET, and that little bit was easy to write our selves.
It’s obvious that it would take longer to write the code instead of just referencing the assemblies, but it was worth the extra effort. BlogEngine.NET is build for .NET developers so my initial thought was that they wanted to be able to change every little thing they wanted to suit their needs. Third-party, precompiled assemblies doesn’t allow for easy customization so that would counter the .NET developers needs. That has a big part in why BlogEngine.NET is so open and simple to customize
If you look at most other .NET blog and CMS platforms in existence today, you’ll see that they make heavy use of various third-party assemblies. All of the assemblies and libraries are open source or at least free of charge and they are all very powerful and easy to use. However, the decision has been made so we had to come up with alternatives to the libraries and that proved surprisingly effortless for our simple needs.
What we didn’t use
Web control libraries
It’s a very cool library for handling trackbacks and pingbacks and pinging Technorati, Feedburner etc. when new posts are created. It does much more than that, but these features were the ones we needed. XML-RPC is standard XML that can be parsed and XPath’ed so why did we need a third-party library for handling XML?
Rich text editor
There are quite a few compression libraries that can gzip or deflate the HTTP response stream. Instead we used the build in compression classes in the CLR and wrote a single HttpModule to do the job.
There exists hundreds of CAPTCHA control libraries for ASP.NET both visible and invisible ones. However, a CAPTCHA is one of the simplest things to write – it takes only 20 lines of code to create a rock solid invisible one – so that’s what we did.
As you can see, we did a lot of reinventing for BlogEngine.NET, but it actually wasn’t that big a deal.
In the enterprise
For enterprise projects where third-party dependencies can be costly, it would be beneficial to be sure what the needs are and if they can be built instead of bought. You should also weigh the value of owning the code instead of using third-parties. It various from project to project and from library to library, but one thing remain the same: third-party dependencies is not as flexible as building your own implementations.
The hobby project
Most hobby projects start when you get an idea and want to realize it real quick. Then you don’t want to do much reinventing because that would just slow you down and your code is probably not essential either. In those cases I would use as many third-party libraries as possible to get the code running and my project realized.
There are many factors to consider before using third-party libraries and some demands real thought. You have to be real careful about using third-party libraries for essential components, because then you loose control of the most important parts of your application. For BlogEngine.NET we also had to consider our target group - the developers.
If you base your business/application on a component provided by third-party, you might want to think twice.