Will "the Mighty" Strohl

What to Expecting When You’re Expecting of the DotNetNuke Ecosystem Vendors

Will Strohl During a Presentation I once gave a session about module development, and one slide in particular was a hit.  It was a last minute addition too.  We spent at least 15 minutes on a slide that was expected to take just 1 minute.  Basically, it outlined some of the considerations that a DotNetNuke® ecosystem customer must be aware of when looking for and buying extensions from any ecosystem vendor.  This is what I want to highlight in this blog post.  I want you to also consider more and expect more of your favorite DNN vendors.  The ecosystem depends on it.

As more and more extensions become available to those of us in the DotNetNuke® eco-system, we as customers tend to and should require more out of those who supply our DNN extensions.  We want things like support, a knowledge base, complete documentation, and above all – a product that works as expect right “out of the box.”  Those are reasonable demands, right?  Kind of…  That depends on the specific vendor.  However, there are some things that I look for when buying an extension for one of my websites (when I don’t build them myself).  While you cannot meet all of the below criteria, these are topics that I still consider before purchasing any extension.

In short, I look at the following criteria, and use them all collectively to measure my decision to even download and demo a module, much less purchase or install it on a production website:

Support & Documentation

I have seen support & documentation handled in a variety of ways by different people, and those ways continue to change and evolve as the ecosystem does.  Some offer support as an add-on service.  Others offer support as part of the module.  And yet others offer support on a subscription or hourly basis.  And there’s very few vendors out there with complete documentation, much less a knowledge base of any kind.  You might ask why, and you’d be right to.

In short, resources are short for most ecosystem vendors out there.  Many have only 1 to 5 employees on staff.  Only a small handful can boast more than 10 employees.  With so few people on staff, most of the vendor’s attention gets paid to development.  After all, that’s what they’re selling.  Everything else is a “nice to have” feature, so they slap a forums module on their website and move on.  I submit to you that this should no longer be acceptable to any of us looking to purchase an extension.

We have seen some of the more successful DNN vendors out there be very successful in offering everything that I suggested earlier, and doing it well nonetheless.  With the advent of all kinds of 3rd party support and feedback solutions (most of which are still free), there is little excuse for any DNN ecosystem vendor to not have all of the resources at the fingertips of their customers – even if they are not free.

Lack of documentation is not a deal-breaker for me, but it might be for many of you.  I feel that if the extension is easy enough to use without documentation or support, then why demand it?  However, I also realize that my skill set and expectation when using a web-based program is much different than others.

Frequent Release Cycles

Probably the first thing I look at when considering a DNN extension purchase is when the last release was.  If there hasn’t been a release in the last 12 months or more, then I am very weary of continuing to look at any other presented information.  If there has been a release in the last 6 month, then it’s a winner!  However, if available, I will also look at the dates of the release history as well. 

Frequent releases really is a clear indicator of how dedicated the vendor is to maintaining the module.  Even if the current release is working great and with no bugs, existing customers most certainly expect there to be new features and/or usability enhancements, and updates to keep with the latest DNN framework changes.

This is perhaps the most important thing I look at in this entire list.  I would suggest you do the same.

Demo Site or Demo Extension

Nothing annoys me more than when an extension vendor simply posts screen shots on their website or Snowcovered and expects a customer to get anything meaningful from that alone.  I realize that the alternative takes significantly more resources.  However, the alternative is even more costly.  I know several vendors who offer a trial licensing mechanism, demo website, demo version of their module, etc.  Having this available is an invaluable tool to help me decide on if the vendor has a solid release that meets my needs.  A screen shot or single line of “feature text” cannot compete in this area.

If the vendor doesn’t provide this, then I would ask for a money-back guarantee or another method to give you a warm fuzzy about the purchase.  Having the demo site puts the risk on the vendor, whereas not having this puts all of the risk on the customer.  This not the place that any customer wants to be in.

Community Reputation

This may be the second most important item in my list.  Even if I can demo the module, and everything else looks good, I always ask one or more trusted sources in the community if they have used the vendor and the specific extension.  Every now and then, I will even ask a question like this publicly in the forums or on twitter.  However, when you do this, you need to always take the comments “with a grain of salt.”  As we all know, people on the Internet are very harsh when voicing their opinion if it’s negative.  Try to read through the lines if such an opinion appears to be emotional at all. 

This section is once again not a deal-breaker for me, but rather used to gain context on any experiences that I might hear or read about.  In addition, I would place product ratings in the same category. 

XHTML Compliance

XHTML compliance is increasingly more important every single day.  As skin developers/designers, 3rd party component vendors, and other component vendors release new tools and controls, they are more and more relying on your website to be XHTML compatible.  While on the surface, this might not mean a whole lot to you right now, it will.  XHTML websites have been proven over and over to be faster loading, SEO-friendly, more accessible, and more easily integrated with other controls and tools.

As an example, many implementations of the popular lightbox control for image galleries does not display properly in Internet Explorer if the website doesn’t render properly in XHTML.  So, this will have a variable level of importance for all of you, but just know that it should be on your list too.

Template System

The more control you have over your skin and how your website appears overall, the more likely that you will want more control over the HTML output that a DNN extension has.  The best way I have seen to manage this so far is through the implementations of template systems in modules.  The best ones I have seen give the option of saving the altered template for the specific module instance, or all modules.  In addition, it should offer an option to revert the template back to the default.  However, if there is a template system, then there MUST be appropriate documentation.  I have yet to see an implementation done where it was so simple to use that we didn’t need to refer to any other information for support.


Localization is a term used to describe another mechanism in DNN that’s available to extension developers to allow their products to work equally well on DNN sites of various languages with text content that’s globally used.  (However, it’s not yet available for dynamic content.  Soon though!)  All the vendor needs to do is plan for it, and include a simple resources file in their installation package for each supported language.

Localization is incredibly important to me, and it’s even more important to those using DNN in other (non-English speaking) countries.  However, it is not just important to me to be able to switch languages easily, but to also change phrases, entire words, or event an entire section of text, as needed.  In fact, it’s been helpful in fixing typos that I’ve found in modules on more than one occasion.  For these reasons, I think that localization should be important to you too.

Implements IPortable

IPortable is another nice feature in the core of DNN that allows extensions to be portable across DNN installations, portals, and so on.  Basically, this implementation gets consumed by a vendor, allowing them to generate an XML file containing all of the content and settings that they choose so that it can be used to install another instance of the same extension elsewhere.  This is a very useful feature.

Some module vendors may argue that this implementation is not necessary for their module, but I would counter their argument.  Even if all your module does is make use of the built-in module settings, those can and should be exported using IPortable. 

If a module you’re considering purchasing is not using IPortable, demand a demo or trial copy of the module to make sure it works like you expect if you regularly move around or expert modules for any reason.

Source Code Available

I don’t know about you, but the source code version of a module is extremely important to me.  There’s something to be said of having the source code right there at your finger tips should you need it for any reason at all.  I can tell you that nearly all of the modules that I do purchase include the source code.  Only 2 come time mind right now that don’t.  Not all vendors offer source code, but that’s not necessarily a red flag of any kind.  In fact, in many cases, it might be a good thing. 

I feel so much better with source code in-hand.  Even if you’re not a developer, you should too.  Having the source code ensures that you and your company have another option should the vendor or the product cease to exist at any point in the future.  If you have the source code, you or someone you contract can easily fix bugs and add new features as desired.  However, if the module still exists, I would suggest refraining from this, as you will be forking the code, and will no longer be able to go along with their upgrade path (unless that’s your intent).

If you don’t have an option to purchase the source code and it is important to you for any reason, speak to the vendor and see what options you have.  In the least, it would be in their best interest to hold the source code in escrow, should the code need to be released for any reason if the company no longer exists.  There are a number of ways to do this, so once again, check with the vendor.


Licensing is only as important as you want or need it to be.  In general, most vendors out there explicitly name very few restrictions to how their extensions are used.  The only thing you need to be aware of is how many DNN single instances (installs) it’s allowed to be installed on, or how many portals and/or domains are allowed to be used with them.  Usually, this information is made very clear.  If for some reason you cannot find this information easily, it should raise a red flag.  Each vendor should make this information easily and readily available to you.


Security is a very wide open topic that I will try to keep as short as possible.  It is also the most overlooked topic that there is - in any industry.  You will need to audit the module yourself to make sure it fits your immediate security concerns.  In the very least, you should perform the following checks:

  • Does it make any unexpected outbound calls to the Internet?
  • Does it attempt to unexpectedly access any system or network information?
  • Does it modify any core files or database objects?
  • Does it unexpectedly access or create any administrator or host accounts?

That was far from an inclusive list.  I just hope a vendor pops up in the DNN ecosystem in the near future that offers an audit and certification service to take care of this for us.  I for one would demand such a certification from any DNN vendor if it existed.

Open Source Extensions

The standards above in some cases may be difficult for certain ecosystem vendors to achieve.  However, I do want to make it clear that I also give plenty of leniency to open source projects.  As you might imagine, their resources are significantly more difficult to pool together, if at all.  So a release in the last 2 years may be more acceptable, for example.

I would invite you to give all open source projects the same leniency as well.  They work hard when they can, and as they can.

In Summary

I have laid out a pretty elaborate and difficult set of standard for any single vendor to be able to achieve.  However, I do this in the hopes of only buying an extension once.  I will be extremely surprised to ever run across a vendor who does meet all of my criteria.  They will be forever DNN superstars in my book!  That being said, it is incumbent upon the administrators and hosts of any DotNetNuke® website to look at their own criteria to make sure that they are enforcing it.  Sure, it will take you a little bit longer to find an extension that fits your needs, but you’re much more likely going to be happier with the extension you end up with, and spend less money finding it.

blog comments powered by Disqus