.>.. and if you don't like it, complain to the module developer! I would not complain directly to Microsoft for instance if my latest copy of Wordstar isn't working properly :). >

now there is a name for the past - however I still have two clients that use it. and yes you can still buy boxed sets. $25 plus postage - available both for Windows and Dos. Wordstar was the fore runner of bundled software - they would supply the last verson to computer sellers to include in the sale - the ciustomers liked it so much they would buy the latest version. And of course it is no used complaining to Microsoft - microsoft was a back shed operation when wordstar hit the market back in the 8080 and z80 days.

However I will agree that a developer should be free to determine what software development tools he purchases and uses thus what version of sql he uses. However to not allow for sql 2000 would point to a developer that does not understand that a very large sector of his possible market only has access to sql 2000.  They are bound by the hosting company and hosting companies are bound by the cost of updating their software.

The high end user may indeed have access to the latest version buy how many of the community sites are high end users. If the product they are developing is for a product that supports the older version as well as the never then it is only logical to assume that the modules will also. if not then mak it clear so the user/buyer can make his decision.

Writing software for old version compilers/sql etc etc is a bug bear some times but then you charge accordingly - I still write software under CPM/Cromix operating systems using Btree - but I charge a bit more then I would for Windows software.  In fact development costs backwards are a lot less then forward - I have already got the pay back on all the previous Visual studio versions and sql versions etc- going forward  I have a lot of future costs with upgrades.

I would in no way consider sql2000 to be a legacy product - in Microsoft world i may be but in the real world it is still there and will be for some time. If say DNN dropped support for sql2000 then it at worse would probably halve its community test bed.

 
Trading Costs
Jon nailed it, in my opinion.  Those who refuse to move along and keep within one very major revision of the current version are simply trading one cost for another.  Instead of taking on the cost and effort of upgrading up front, they're implicitly agreeing to accept severe limitations (no new modules available) and the cost of maintenance later down the road (pay a developer to write a custom legacy-compatable module just for you).  Such maintanance can also come at an inflated price:  what happens when you need a new module but can't find a developer who remembers the quirks and limitations of SQL2000 (and/or IE5, etc).  Sure, a decent developer will be able to figure things out.....eventually.  How much extra are you willing to pay to have that developer spend part of their billable hours re-training his/herself in aging software? 

Example:  Good contractors in my area charge $110+ per hour.  If one contractor working to produce a legacy-compatable product spent the equivalent of one day (8 hours) getting refreshed / troubleshooting items specific to SQL2000 that would be $880.  SQL2005 Standard Edition retails at $885.  Why pay the contracter for an extra day to refresh on SQL2000 (and then walk away with the knowledge I paid for) when I could spend the same to get a SQL2005 license?  Upgrading isn't free, of course (time = money), but every effort saved due to having SQL2005 over SQL2000 knocks down the cost of the upgrade until it eventually (hopefully) starts making me money thanks to future costs avoided.

Let's take the premise beyond SQL Server.  Compare writing a DB-connected, web-aware app in VB6 versus VB.Net 2.x+.  There's a huge advantage in simplicity and stability under VB.Net over VB6.  Such an advantage should translate into shorter dev cycles and, therefore, less paid to that contractor for custom development.  But, wait -- perhaps the features you need doesn't require custom dev because the new version of your software already has it.  If so, perhaps you won't need to hire that contractor at all...

Consider DNN:

• How much more work to add a custom "deny role" permission setting to a module under DNN 3.x or 4.x compared to 5.x where this feature is included by default?
• How much work is required under DNN 3.x or 4.x to create a custom module to allow non-admins to manage user accounts compared to 5.x where the feature is included by default?
• What about developing a MS AJAX-enabled app under DNN 3.x versus DNN 4.5+?  It's simple enough to include the MS AJAX library under 3.x once you know how but under 4.5+ you don't even have to spend the time to learn how.  In addition, under 4.5+ you're more likely to end up with a module that conforms to DNN's MS AJAX-implementation standards and "plays well with others" therefore requiring less maintenance development down the road.  Time saved = money saved.

Would you make the same "developers should support legacy software environments" argument and demand that DNN module developers write and support two versions of every module in order to support both the legacy DotNet 1.1 framework as well as 2.x+?  As Jon and others have already said, "you have to draw the line somewhere".
 
  
Opportunity Costs
I don't think anyone has a problem with the idea that, if you want new functionality in your legacy DNN site, the very first step is for you to UPGRADE your copy of DNN.  Why should this be different with regards to SQL Server?  Ahhh....because SQL Server is not free.  It's perfectly understandable that you'd try to avoid the cost of a new SQL license(s) if possible.  By not upgrading, though, you accept the "opportunity cost" of not being able to always take advantage of newer software solutions and, potentially, having to pay much extra in terms of having legacy-compatable solutions developed instead of picking up some $80 module on SnowCovered.

Cost managers must recognize and accept that tech won't wait -- not as long as ten years, at least.  You must strike a good balance between "upgrade costs" and "opportunity costs".  Where is the break-even line between the two?  If you are truly concerned with managing costs, you have to draw it somewhere...
 
 
-mamlin

You don't need the standard edition if you're a developer. The Express edition is free and it has all the functionality of the standard edition in terms of SQL functionality minus the enterperise features.

You have to look at the license issue from both the developer and host sides. The cost is 0 for the module developer. Use the Express edition. Eventually the module will be hosted somewhere. Either internally at a company or at a web host. A web host will need the CPU license. The CAL version won't do and that includes the $885 version you mentioned.. So a host has to fork out at least $4000 per server. That's a big cost. They can go with the Express edition but they are limited to 2G in database, single cpu and 1G RAM. SQL Server 2008 has a web edition. I am not sure how that works exactly. I have seen monthly fees and a one time cost for that.

So for SQL Server 2005+ only module developers, what they are doing is that they are not considering SQL Server 2000 only hosts. Every module developer is free to support any technology they want even if it limits their potential market. If they don't care about the SQL Server 2000 only hosts, that should be OK.

DNN supports SQL Server 2000. No one is asking why they are still supporting a "legacy" database. Because it's still a common database platform.