I have just picked up on the email module debate and the importance of quality module support.

This is a really interested area for me, since in theory the use of 3rd party modules can be very powerful. However when one is building a business on providing solutions it is vital that the "partnership" with the modules/component suppliers is of a high quality otherwise the initial saving can result in lost business. Many of my peers have been bitten by issues with components which they have only found later in the development lifecycle and have vowed to only use their own code in future. Now I appreciate that DNN module source can be bought (more expensive), but it does highlight how important it is to verify the supplier, test the module, test the support process and check the supporting materials ie manuals etc. Also what happens when the supplier stops operating or becomes "reclusive". What is the exit plan for you business ?

On balance I believe that the use of 3rd party modules is best so that one can focus on providing the solution. However it is so important to do the homework before taking the dive.

Food for thought...

Sam

 

In my opinion this is a constant struggle in the DotNetNuke ecosystem not just for customers, but also for developers. 

As a module developer myself, I have avoided going the route of offering commercial modules as I just can't guarantee that i could support the incredibly wide user base.  However, with providing free modules like I do, I end up spending more time supporting things that I could ever have imagined, (about 10 hours a week, on items with no incoming cash flow).  That considered, I couldn't put something out there if I couldn't support it in some fashion, and I couldn't roll up and leave.

Since I don't really publish commercial modules, I spent a large percentage of my time building custom modules for clients, these I have to fully support, AND every time the client is given full source code for all modules.  I've also been contracted many times to modify third-party modules that the orig. developer either stopped supporting it or were not fast enough to respond. 

Therefore as the first poster mentioned I think there are a few common "rules" that are best practices to protect your business interests

1. Review the company to see if they provide good support, contact them and see how quick they respond
2. If you are not happy with the results of 1, find another person that would be willing to support you if needed
3. ONLY buy source versions of modules, this way, if the developer goes away, or doesn't support you can branch out on your own
4. form a relationship with a developer that would be willing to modify other peoples code if the situation comes up if you don't have an internal development team.

I find this the really only viable solution as custom building everything isn't practical or cost effective, but leaving yourself open if a developer closes up is not really an option either.  I find that for my clients this gets the best of both worlds.

---

-Mitchel Sellers
Microsoft MVP, ASPInsider, DNN MVP
CEO/Director of Development - IowaComputerGurus Inc.


Visit mitchelsellers.com for my mostly DNN Blog and support forum.

Visit IowaComputerGurus.com for free DNN Modules, DNN Performance Tips, DNN Consulting Quotes, and DNN Technical Support Services

As a module developer who distributes free and paid-for modules, I'd just like to add the dimension of price to the discussion.   Whilst bargain-basement prices for modules (I have seen them for less than $10) might seem tempting, you must ask yourself as a buyer how much support are you realistically going to get for that $10.   I've seen a few mentions of developers who get overtaken by their creations and can no longer provide support - probably because there's not enough money in the sales to justify the amount of time spent supporting those sales.  It's a discussion I've seen before, but I think in general module developers interested in building a sustainable business (whether hobby or full time) need to either increase their prices to cover the amount of support, or sell support packages as an add-on to the price.

And as for developer ratings - it's a good idea, and at least on snowcovered there's a mechanism for this.  Googling the developers name can also turn up what people think.   But the most important thing missing in my view is that people buy a module, then never give feedback to things like the snowcovered ratings.  The ratings help fellow customers more than the developers, so if you've bought a module and never rated it - why not go back and let  the developer (and the world) know what you think?