Written by:
8/21/2009 

As is usual for me, I will be working on one thing, and concentrating on another thing, and then – BOOM!  An idea or thought pops in my head that is usually completely unrelated to the tasks at-hand, but are really good ideas.  This time, it’s more of a philosophy though.  I think those of you that have private modules that you only make available to certain customers should consider selling those “private” modules.  Here’s why…

I am not going to mention any names, but during my evaluation period where I was trying our different Social Networking solutions for DotNetNuke®, one of my options was from a major DNN vendor.  From one stand point, I really favored that option from the outset, because I trusted this vendor completely to very quickly, efficiently, and consistently fix or add any features that I needed.  Good right?  Maybe…

Then there were other public options out there, such as: Active Social, and SmartSocial.  When I began looking over and then testing my options, as a Technical Director who is shaping the future of a technology department and constantly monitoring strategy, I looked the following concerns:

• Flexibility out of the box
• Ease of use for administration
• Usability for end-users
• Feature set
• Future road map of features
• Stability of the company who owns the product
• Reputation of the developer(s)/company
• Ease of requesting new features from the vendor
• Cost of developing new features in-house
• Ability to customize the look of the module
• and more…

From this initial list, you can see that there was plenty to worry about before marrying ourselves to a solution.  And you can tell that we had already resolved to not developing this solution in-house.  We wanted something that was already built, and that would grown with us with the least cost going forward in the long term.

We chose to go with Active Social, because of several reasons.  Most of all, it relieved most of the concerns above.  In fact, I even had a meeting with the company’s owner, Will Morgenweck, to address other concerns that I cannot publically post.

Initially, the private solution that I mentioned would have been the better choice, but it did not have the amount of features that Active Social did out of the box.  There’s the problem.  Active Social doesn’t have all of the features that are important to us right now either.  And there’s the difference.  In order to get the private solution to the point of matching Active Social, we would have had to pay for the development hours to get the features in place. 

Playing “devil’s advocate”, lets say that the private module had all of the features that Active Social currently has.  We already know that we have needs that are net served in the current module, but know that they are on the road map of the module.  We will not have to pay for those features.  We will just have to pay for the ongoing subscription to the module every year.  This also includes free support during the duration of our subscription. 

In case you’re not following me, let me describe to you how cost is going to get out of control fast…  If we chose the private solution:

• We would have to scope out and have meetings about the requested features
• We would have to pay for every single feature that we wanted, at a hourly development fee
• We would have to test the module updates as they are completed to ensure that the requirements were met
• We would have to do an additional level of bug testing and user testing in-house

In contrast, the public solution:

• The module updates might already scoped out, and if it’s new, the meeting would probably not cost us anything
• We would only need to pay for module updates if they are not already on the product road map
• The testing is done by the development company
• Our in-house testing would be less rigorous (as long as we chose a reputable vendor)

Hopefully, I have illustrated what I am talking about well-enough to get my point across.  If you’re a private module vendor, your module would better compete with others out there by having your customers do the leg work in suggesting and scoping out new features.  You could then incorporate only the best parts of the module to your private customers.  This would in-turn have a positive effect on your private development efforts, because development would not get stifled by distractions from other projects you might be working on. 

Now, this is not a “one size fits all” suggestion…  There are of course other concerns.  Certain modules would not have the same level of demand from customers.  In such cases, my argument would definitely not fit, as you would not get your return on investment (ROI).  You might fork out more expenses on development to a module that is not being purchased.  What good is a module with a ton of great features, if no one wants it?  So you definitely need to use your entrepreneurial business chops to help make that business decision for yourself.

I hope have provoked thought in how you might be handling one or more of your private modules.  If nothing else, hopefully you have a fresh perspective on future modules.

Trackback Print

Tags:

Categories: DotNetNuke

Location: Blogs The Mighty Blog

Your name:
Your email:
	(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel