Great questions.

We use SVN for source control.  Bug tracking and project management really depends on your situation.  For a free .net bug tracking app I recommend BugNet.  Depending on your style you can also use it for project management.

1) Decide the minimum version of DotNetNuke you are going to support. Then create an install for each version until the latest.  You will want to automate backing up and restoring these sites.  Create a test plan which includes clean install, upgrade install and uninstall for your module.  Our test plans are very detailed.  We try and cover every possible interaction, document the intended behavior and account for multiple browsers.

2) Trial versions go along with your plan for licensing and protection.  See below.

You can't.  You can only make it more difficult.  Decide what you want to protect.  Protecting your actual code is tough but you can use obfuscation.  Code encryption is also an option, but doesn't work under medium trust.  Protecting and enforcing your licensing is a little bit easier.  Do you want to limit your product to a certain number of portals or module instances?  Do you want customers to activate the product?  Do you want to provide featured or time limited versions? How will you provide the customer with the serial number after purchase?  There are products available to make this easier for you and we have tried most of them.  We ended up building our own solution.

1) Customers give you money, they expect and deserve support.  The level of support is up to you.  Whatever you decide make sure it is very clear to your customers.  You may want to provide different levels of support and charge extra for more time consuming issues.  For example, offer installation support for free but charge extra for CSS support.  You may want to offer an installation service where you will install and configure the module for a fee.  In that situation, you want to make it clear what support options are available when just getting started.

2) Choose a support tool that allows you to efficiently manage support.

3) If you are just getting started, I would plan on 1 support request per sale.  I'm not saying that's realistic, but you should be prepared.  If you are getting a high number of support request then you should look at your documentation and the usability of your product.

Snowcovered, DNN Marketplace and your own site.  Your goal should be to get people to buy directly from you.  It took us over 3 years, but now 90% of our sales are direct through our own site.  Snowcovered and the DNN Marketplace are great marketing tools and a great way to get started.

Couple other things...

1) Release schedule - How much time can you commit?  As soon as you release 1.0 customers will be ready for 1.1.  I would suggest releasing 1.0 and have a few features ready for 1.1 and 1.2 within 30-60 days.  Show your customers you are commited.

2) Price - Do you want to make money or be popular?  Free or cheap modules make you popular, not financially stable.  Decide how much money you want to make each month from your module business.  "Guestimate" the maximum and minimum number of licenses you think you can sell each month.  Now set your price to meet your financial goals.  You also need to consider the price points of your competition, but remember you don't have to be the cheapest.  If sales are better than you expected raise your price with your next release.

3) Don't compete with me :)

I realize this thread is nearly six months old, but I thought I would answer here in case you never found a solution -- or for the next person who comes along with the same question.

VisualSVN is what you want.  It integrates right in to Visual Studio and makes checking items in and out of SVN a breeze.  I've been using it for about 4 or 5 months now, and it's well worth the $49 cost.  They also make a free VisualSVN server that I run under Windows 2003 SBS for the backend.

I don't want to speak for Will, but that's what I suggest.  By actually writing out a test plan, you make sure you don't miss anything.  Programming is complicated stuff.  One seemingly innocuous change might break something elsewhere in your module.  Only by testing thoroughly can you be sure you don't miss something -- which won't make your customers happy and will make more work for you in the long run.

Any 3rd party you use to sell your modules is going to take a cut of the sales.  Snowcovered, for example, takes 25% of the sale.  If you were to sell the module directly on your web site, you can cut your loss back to 3 or 5%, which are common discount rates for Credit Card Processors or PayPal.  In essence, you make an extra 20%.