Software licensing: Charge per-major-version or per one-year-free-upgrades?

A is the most common licensing scheme and used my most installable desktop applications such as Office, Photoshop, Nero, SnagIt, etc.

That licensing scheme is easy to understand for your customers, licenses key and upgrades are easier to handle and you don't have to release a new version if there is nothing to release. You release at the rhythm of your own innovations.

However, B can provide value if your software matches at least 2 of the following points:

• You provide reference data updated often (such as Virus Definition for Anti-Virus softwares)
• Support is an important part of the offer
• Your product is based in quickly evolving technologies (software components, OS enhancers, security scanners, etc)
• You innovate a lot by providing valuable new features often.

B has the advantage to provide you with a constant and predictable stream of income. Customers tend to "renew" more than the "upgrade" scheme of A.

However when not used correctly, B can be a business killer. You will be the slave of your scheme.

Please note that it's very common to change your scheme in the life cycle of a product.

Must read: The Strategy And Tactics Of Pricing

Go for B, 3 big advantages,

1) You'll make more money with the same number of clients (although you can argue that B can decrease number of sales)

2) Support will be much easier because everyone will have the same version

3) Since everyone got the latest version your customers experience will be much better (means they won't get annoyed by already fixed bugs etc.) and this will bring more customers

If all else were equal and you chose A, would you support older, major versions, e.g., would you provide a 2.0.1 and a 3.0.1 together to address a problem that exists in both? If not, then the primary difference between the two is that A gives you opaque, flexible control over when to raise funds from you existing user base and how much you want to raise while B is transparent and fixed.

Option A allows you flexibility to adjust the cost and time points of your iron triangle by allowing you to raise revenue to cover a larger upgrade or faster delivery of upgrades (or to do the reverse without angering your customers.) It also offers your customers more control and predictability because they only pay for what is available now, not for a promise of things to come, and only when they want.

Option B depends somewhat on your reputation, some customers will be less likely to buy a year if they can't tell how many upgrades they'll get, or if they'll get any at all. So some people will be more willing to buy B if they perceive they're buying a service that improves but doesn't change drastically instead of an application that should be growing significantly (Evernote v. Photoshop.)

Note that licensing approach is related to but not causal to the version distribution within your customer base. As Skype just reminded us all very loudly, even free doesn't mean people will stay current. Many other companies (e.g. Microsoft, Mozilla) have discovered for us that even aggressive auto-updating systems leave some users out of date.

Option A gives both you and the customer more control and predicability. It also slightly relieves the pressure on you to deliver major versions faster, perhaps with lower quality or less rationality (e.g., customer perceives there's not enough improvement to warrant the 3 to 4 you shipped largely to placate your annual customers, lowering your marketing v. honesty score.)

The best place to get the answer is from your customer base. Talk to them them directly and research the vendors of other products they tend to buy. Many of those vendors won't be direct competitors and may be willing to talk about what they've learned about pricing models in your market.

If you can't decide, you could allow customers to pick during the first year, giving you an A/B test of sorts.

Other people have addressed these from the vendor perspective; I'll tackle it from the buyer's side.

A lot of the consumer-level software I use is "pay an upgrade fee on a major new version", including Microsoft Office. I rarely buy the upgrade immediately, and sometimes never do. That's because the older version often works fine for me, the benefits of the new version are not clear, and the upgrade fee is often a budget shock. In fact, I've gotten so far behind on MS Office, I've simply switched to Open Office/Libre Office, and MS has lost me as a customer.

The "pay an annual fee" model is common for enterprise software. Software I've bought that uses this includes the Microsoft Developer Network ("MSDN"), Apple's Mac and iOS developer programs that get me access to non-public goodies, the Perforce version control system, and the FogBugz issue tracking system. I really like it because it's predictable and easy to budget for.

The one thing I'd suggest is if you go for the annual-fee model, be sure to do multiple releases a year and make the upgrades really easy. Perforce does that with twice-a-year releases, and doesn't distinguish minor and major releases; for 2010, they're just 2010.1 and 2010.2, and I'm really happy with them. FogBugz does annual-fee but less frequent notable releases, and upgrades are kind of a pain if you're not on Windows, and I dropped them for Redmine.

I'm currently developing as a contractor for a company that has a (to me) quite astonishing pricing model: they do a minor release once or twice a month, a major release every 2-3 years, constantly add new functionality, and haven't charged an upgrade fee in over ten years. Their software is aimed at a narrow, expensive vertical market, starts at about $2000 a copy and goes up from there, and their customers are insanely loyal. Because they never charge for upgrades, and they're quick to respond to user feature requests, once they get in the door someplace there's never any justification for the customer to buy a competitor, and they've completely crushed everybody else to where they're the 800 pound gorilla in their market and the only remaining competition is one-person shops with $100 software with about 1/20 the functionality.

Something to consider in the decision is how your development process works.

If you have a single main-line release, and you apply fixes to the same development stream as you create new features, you can't hardly charge for an "upgrade", you have to charge for "support".

If you create a new branch at periodic intervals -- say, a "major release" -- and you can still apply bug fixes to the "previous release", you can charge for upgrades while still providing free "bug fix" releases. You should have clearly defined new functionality or else the customer will wonder what the hell is being purchased.

My company takes the second approach. When new major functionality is added to the product, the "major" number is incremented. That's where the "free updates" end. Eventually the bugs stop being found and the updates stop being provided. This year the product got a new RESTful interface. End-of-life for the previous release is set to 12 months after the last patch release. If existing customers want the new features, they can pay for them -- they didn't pay for them the first time around. To keep customers at the end of a major release from feeling they bought an obsolete product, anyone who purchases the product less than a year from a major release gets "grandfathered" in to the new major release.

I have a competitor who takes the first approach and they can't figure out how to charge for support because they promised free upgrades years ago. Were I in charge of that company, I'd change that term for new customers, but of course I'd prefer they leave things the way they are so they don't make as much money.