Which Module Package Should You Purchase? 

A while back when asking for input on blog postings a very common question was recommended as the topic.  That question was "How do I determine which module package I should purchase?".  Within the DotNetNuke Eco-System there are a number of different purchase options for third-party modules, however, in the end it boils down to two different package types.  Install packages and Source packages.  Which is right for you?  This answer isn't quite as clear as one might expect, and the following blog posting will walk through the different things that need to be considered before making that purchase choice.

Package Types

First I want to start off by level setting my generalization of module packages to ensure that everyone is reading from the same general base of information.

Installation Packages

 The most common package types available for purchase are Installation packages.  These packages are simply installation versions of the modules, designed to be directly installed to a DotNetNuke installation.  In most commercial module scenarios the source code for the module is compilied into DLL files and is NOT visible by looking at the code included in the package.

Source Packages

Source packages are typically an "added option" item to a modules purchase.  The source package may simply be a modified installation package, something that you can install to a DotNetNuke installation and all source files will additionally be deployed.  A source package might also exist as a separate zip file that contains the entire project source.  The key is that the source package includes all code and project files necessary for your to build and deploy the module. 

What is right for me?

 A good majority of individuals purchasing modules come to a purchase decision by coming to a conclusion similar to the following: "I'm not a developer, I'm not going to be modifying the source".  At first review this thought really seems to identify the proper decision, only buy the source if you are a developer.  Well I'm going to argue and recommend that EVERYONE should be purchasing the source version of modules, even if they are not developers.  This isn't a ploy to improve source package sales or anything, but a simple professional recommendation to help buyers protect themselves from future loss.  The following sub points illustrate WHY I think it is important that you purchase the source versions of modules.

Future Planning

 One of the biggest reasons to purchase the source code for a module is to ensure that you are planning for the future.  It is never something we want to wish upon someone, but developers do come and go.  You don't want to get a few years down the road using a module to just find out that they have gone out of business and you can no longer get upgrades to the module.  This type of situation can literally stop a site from being able to upgrade to newer versions of the DotNetNuke framework.

With the source code it is at least possible to get a consultant to help make a module work with newer DNN versions should an issue arise. 

Ability to Enhance

 Another big reason that leads me to recommend the purchasing of source code for modules is that once you have the source code it is possible to enhance the product, should it be needed, to fit your specific business implementation.  With access to source versions of a product it is possible for you to then expand the functionality to meet your specific business needs.  These enhancements can be completed with an internal development team if you have one, or via a consultant that has experience working with DotNetNuke modules.

Ability to Review Code

Depending on the specific environment you are working in it might also be a requirement that you have all source code to a system for security reviews, or internal/external audits of computing systems.  This audit trail might be of special importance to those working in professional environments.

Summary

Overall, The point of this article is to simply shed light on a few reasons why one might want to consider buying the Source version of a module.  Is it necessary in all times?  No it isn't, but it is a decision that should be properly evaluated with each and every module purchase.  As with all other decisions when it comes to building a website the entire picture must factor into the purchase decisions.

Please feel free to share you comments below.  If you have specific directed questions please use the forum to discuss.

 

Posted by Mitchel on Wednesday, December 31, 2008
 

Comments

If you have a programmer and you're willing to customize - then buy the source version. I have never found a module that does everything I need, works the way I want, or is bug-free. Having the source version will allow you to get the functionality you need, and debug any problems you may have in the future.

By Rafe Kemmis on Wednesday, December 31, 2008 at 9:51 AM

Mitchel -

Great blog post - this will certainly help answer a great deal of the questions we see in the forums and elsewhere.

I thought I would add one point. Your blog looks at this topic from the perspective of the prospective module purchaser ("How do I determine which module package I should purchase?") Another important part of this equation is how the module developers in the DotNetNuke ecosystem choose to label their module package prior to marketing them.

Example... I have seen package labels which include: Source; Install; Install Only; PA; Enterprise; Standard; Unlimited; Professional; Basic; Base; Single Portal; Multi Portal; Developer; End User; Light; and many more variations.

If, perhaps, there were fewer variations in labelling, module buyers would also have an easier time sorting out which packages would suit their needs.

By Bill Walker on Wednesday, December 31, 2008 at 11:15 AM

Bill,

That is a very good point as well, and an additional dimension to the problem that I need to find a way to cover......

By mitchel.sellers@gmail.com on Wednesday, December 31, 2008 at 11:23 AM

I couldnt agree more with you. But as a solution provider / integrator I can tell you this... there will be still some scenarios where customers will want to cut costs as much as they can, and as long as the module in question covers up all the basic functionality they need at the present time, most of them are ok to gamble for the future in need of support and or features.

In these cases, if it turns out that they do need some extra features, which arent likely to come anytime soon you can always play around with the module's own API to offer an extended solution. The same applies when you need a features which is available on a later version of the module for which youre not willing to spend another 50$ just to get it... CSV/Excel exporting springs to mind...

And theres the other side of the coin where the module who just purchased turned out be an overkill... with just the install version. One quick example I can think of is ZLDNN Article module, used in conjuction with the ZLDNN maps = Very happy customer :D

But again, in the end it really depends on your customers needs and a bit of your own foresight and true involvement with the project to identify and make a correct assesment of the clients needs.

By Alfonso Perez on Wednesday, December 31, 2008 at 12:03 PM

Many major enterprises have a policy of always buying source, the issue for many is whether that's a good policy for smaller shops or individuals. MY general tendency is to agree with Mitchel, the source always makes recovering a dead module possible. By dead, I mean unsupported, as when the module developer gets bought out by a company that kills the project, dies in a tragic hamburger incident, moves to a mountaintop to contemplate life or simply gets tired of supporting modules. So many DNN modules are developed by one-man shops that this is a real possibility.

But, I have foregone the source when the price didn't justify it, when there were similar competing modules available that I could always switch to, or when any other alternative might exist.

By Jeff Cochran on Friday, January 02, 2009 at 4:20 AM

Comments from the following blog entry: Sobre el c, located at: http://www.dotnetnukeole.com/Blog/tabid/267/ID/76/Sobre-el-codigo-fuente.aspx

By DotNetNuke Ol on Wednesday, October 21, 2009 at 10:58 AM
Click here to post a comment

Disclaimer