Carlos,

I agree with your point about 'breaking features'.  That's the reason I'm not quick to move to a new version in a Production environment until it's been through at least 3 or 4 months of use by the community.  Like it or not, each DNN project team is responsible for testing, and there is a small group of folks who are supposed to test modules before releasing them.  Unfortunately, these groups will never catch all issues during the testing cylce, so something gets release, with what others might consider a 'big' breaking change.  No body likes to go backwards, so these issues go back into the project for assignment and fixing.  I don't see any effort to provide quick patches for fixes fo anything but the framework in general. 

I don't like that situation either, but it's more of a resource issue I would suspect than a 'desire' to make thing uncomfortable for the community.  The internal search and syndication method has been 'busted' for some time, and that's pretty embarassing to me, too.  I guess, I've just become accustomed to providing workarounds for these types of issues for so long, it doesn't cause me much grief.  I sorta take things in stride, because, it still beats the heck out of anything else I've used for .Net concentric web development and management.  If you ever used MS's FrontPage, back in the day, that was truly disgusting, and I paid for that junk software.  At least, I know from working on the Core Team long ago that there really is an effort to do the right thing, it may not be immediately recognizable, but the 'involved' folks are really trying to get things right. What I see over the last year or so, it more attention being paid to spreading DNN to commercial capitalists ventures rather than the original audience of OpenSource community members.  What I hope is that the effort doesn't diminish from the framework as a whole. I see only a very few Core Team members participating in these forums, and I miss the touchstones.

Cheers,

Nothing is ever better or worse.  It is always better or worse than another product for a specific function in a specific environment.  If I have only Microsoft servers and ASP.NET developers and nobody I employ knows PHP or how to configure it, then DNN is a better choice that any PHP solution.  Conversely, if I have PHP developers and an all Unix/Linux environment, then I probably don't want to consider a DNN option.

Note that the word FREE never enters my consideration, nothing in life is actually free.

Jeff

Michael,

That is true.  I wouldn't even call DNN a CMS, but rather a content framework.  The distinction is a very important one when folks try to compare DNN to something else.  So, what's the point?  It really is more of a question of 'what you want to do with it?'.  I suspect the post was just another twawler trying to get a rise out of folks.  Most of us who've worked with DNN know the value of it, and though it's frustrating at times, DNN is my preferred framework.  As I said, I use a lot of technologies, and find .Net concentric apps and web frameworks much easier to use for 'need it now' situations. 

I use Linux/HPUX and their related technologies to work with disparate data islands, which require mostly text manipulation, which is quickly done with the Korn Shell Script, awk, sed, and other tools.  However, when it's time to actually use that data, I rely on .Net technologies for presentation, because that's what the bulk of my clients have for desktops.  DNN is what we like to use for Web apps, because of it's ability to provide the framework, and allows us to build our custom solutions with existing modules, or new ones.

I do a lot of work with newsfeeds, and when I get a feed to present, I just have to tweak the xsl to change the presentation, in Joomla, I have to tweak the code, and use PHP.  Seems silly, when xsl allows presentation changes to be made with much more simplicity.  But, in defense of those technologies, it could be a matter of experience, too, which makes it seem so.