Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...The Need for Module Standards and PracticesThe Need for Module Standards and Practices
Previous
 
Next
New Post
7/8/2010 1:55 AM
 
Sebastian,

Thanks for the response. I agree with your thoughts. I too prefer to buy from the vendors you mentioned and other reputable ones. But, I have clients whose requirements aren't met by such notable vendors and require me to venture out into unfamiliar territory much more often than I would otherwise choose. I'm supporting about 100 modules currently to meet my clients' needs and many types aren't provided by the most respectable vendors.

I agree that certification probably isn't the answer. I do think it's possible that there are other options that are less extreme and expensive to manage that still puts some needed boundaries in place. I can't suggest what those might be but my hope is that the community can collaboratively find the sweet spot along the continuum between no guidelines and certification. Perhaps a broad set of standards are established such you must use basic relational data normalization, you must use primary keys on all SQL tables, etc.Then, perhaps the community can regulate and report non-compliance. If enough reports of non-compliance are submitted, perhaps DNN staff could verify the issue and then leverage some teeth put in place such as flagging modules in Snowcovered as being non-compliant. I suspect a compliance body could be formed of volunteers with vested interest and summary findings merely reviewed and verified by DNN staff.

I'm not suggesting this is the right answer, I'm just trying to broaden the framework of what it might look like. I don't think it needs to be complicated or expensive to manage. But, I do think some basic standards would be beneficial to the community in terms of identifying and hopefully wrangling in poor practices among module developers.

Thanks again for your thoughts,
John
 
New Post
7/8/2010 10:55 AM
 
Bruce Chapman wrote:
John, I agree with many of your points.  Particularly about releasing source code if a product is decided to be abandoned.   
Or bought out by DNN Corp...?  :)

Jeff
 
New Post
7/8/2010 11:06 AM
 
John Tisdale wrote:
Thanks for the response. I agree with your thoughts. I too prefer to buy from the vendors you mentioned and other reputable ones. 
I think that's the real key to this problem --  The marketplace will determine those vendors who have the best support and track record.  And while I sympathize with having to support 100 modules, I have to believe there's a possible change to your own business model that might help you.  Stop accepting cleints whose needs you can't properly meet.

Okay, it's really tough in this economy to turn down money, but sometimes the fit just isn't right.  I still have clients asking me to take over managing PHP code, even though it's been half a decade since I worked with it in any real manner.  And I admit, I don't turn them all down, though I wish I could.  I know a good PHP developer I refer them too, but he's not local and most of my clients still want to see my face (can't understand why...).

My other take on this is that, over the years, I've adapted a number of modules to specific needs, or used products like XMod to accomplish tasks, but I haven't had to work with those for some time.  Now, as I need to update sites to current DNN versions, I'm breaking my own, poorly documented and non-standard mods.  In effect, I'm giving myself the same headaches you're experiencing from the community at large.  While the professional, responsible, modules are much more available now, just the conversion process takes too much effort on my part.  I still have a client on a DNN 3.x site for this reason (they wouldn't know and don't care anyway).

I also don't believe certification is the answer.  It will either need to be funded by the developers or it will become similar to other industruy certifications, where anyone gets accepted.  Social features on Snowcovered might help, but even those get gamed.  Look at all the hassle eBay goes through in dealing with ratings of vendors.  Reviews can help, but even those are notoriously unreliable unless I know the reviewer.

Jeff
 
New Post
7/8/2010 5:56 PM
 
Coding standards in modules and people publishing modules and sticking around to support them would be great, but it is going to be very hard to come by.  People have already mentioned the problems with ratings, reviewing modules, etc. so I won't go into those.

You did however mention the module you used was pulled by the developer leaving you in a tough spot.  That's the reality of things.  If you buy the module and don't get the source you are counting on the developer to stick around in case anything goes wrong.  My company switched to DNN for their website and we have purchased many modules and built many of our own to fit our needs.  One of our rules in purchasing modules is to buy the source package.  It costs more to purchase the source version, but it protects us.  If the developer disappears we have the source so we can still fix problems if they come later.  

If a module doesn't offer a source version, and the developers refuse offer one, we don't buy the module.  End of story.  The headaches you are going through trying to get a new module to replace an old one (and chances are the features will not be identical) are reason enough for us to stay away.  If we can't get a module with the source we either build our own or say we can't do what is needed and other options are presented.
 
New Post
7/8/2010 9:09 PM
 
Jeff Cochran wrote:
Bruce Chapman wrote:
John, I agree with many of your points.  Particularly about releasing source code if a product is decided to be abandoned.   
Or bought out by DNN Corp...?  :)

Jeff

 Well, I'm still independent!  Maybe we'll see modules bought and integrated into the community edition, but I can certainly understand the circumstances why source code woudl remain closed for PE-only modules.

Mike : I completely understand your position here and respect your choice regarding source code.  I don't release source code for purchased modules for many reasons the first most important is that I won't support modified code, and it's impossible to know if you're dealing with a plain vanilla or recompiled version.  I know that loses me sales but it's a policy I have.  For the record I would never orphan a product if I decided to no longer pursue it.

 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...The Need for Module Standards and PracticesThe Need for Module Standards and Practices


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out