A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
I am planing to release the next major version. A few years I have
been working on the principle that minor updates within the
major version are free. For example, 2.3.1 to 2.4.5. but
updates into major version ( eg 2.x to 3.x) - paid, 50 % of the
original purchase price.
In this case, the main versions are installed in separate folders :
C: \ Program Files \ My Program 2 \
C: \ Program Files \ My Program 3 \
So the products are fully independent. The keys are
different. So, people can try version 3.x, and purchase an upgrade if they like to .
Inside of registration keys I don't store purchase date.
One day I noticed that one author has released major version and
wrote that the type of update on the majority paid version , but if
you bought the program after October 1, 2012, then you free update .
And if earlier - that is paid.
With me, on the 15th of October, I suppose releasing a major version,
if a customer is buying the product ( version 2.x), then the version
released on 15th of October (3.x) will be paid for him ( he has to
buy the upgrade ) . That is not quite probably nice for the buyer.
I wonder how it's better to do major upgrades?
I have heard Microsoft has a certain period (I think 6 months), ie if there
is a new Office, and you bought the old Office 5 months, it can get a new
one for free. I think it's so.
The difficulty is that it is necessary for these clients to
automatically generate a new free keys and send them. But the
difficulty is not so real, since I don't manually generate the keys
(it will do the CRM program).
Still there is a great desire to offer the software on a subscription
I have heard Adobe began selling its "traditional " non cloud products
by subscription. For example, for my product customer to pay X for a
new product , and then , X / 2 for each paid upgrade (once a year )
Maybe for client it is better to pay once a year X / 2 or a little more
than X * 3/4. And correspondingly it's possible to offer the subscription - semi-annual and
I think, in this case - it is necessary to prescribe the exact end
date of the license registration key.
I am planning to show on purchase page 2 options:
1. traditional/classical (i.e., slightly improved , as described above)
2 by subscription.
And the customer can choose what suits him best.
I would appreciate any ideas and tips.
Thursday, October 03, 2013
I think the transition to a subscription will greatly simplify your system of versions.
Thursday, October 03, 2013
I agree with Alex, but customers might not like it (although some will).
What you need to offer is "Support & Maintenance" -- if they are paying for yearly Support & Maintenance, they get major version upgrades. Give them the first year for free (this is important!), and subsequent years cost roughly 20% of the original purchase price. We started doing this a few years back and it has been a nice fairly reliable (and growing) revenue stream.
The current system sounds pretty reasonable.
If you want to add subscriptions to that you can do it in addition to the basic plan, let people have a choice.
Say there is "priority support" which means answers within 24 hrs, and basically means you just answer their emails first. Perhaps corporate customers will like this. The average one-man customer isn't going to like subscriptions and will prefer the option of major upgrades, so allow that price for them.
I wouldn't get too complicated in the pricing.
+ 1 Alex & Doug.
I no longer offer updates or major version releases for paid upgrade - instead I offer an upgrade subscription programme.
I have two types of customer - perpetual licenses and subscription licenses. Subscription license users have updates and upgrades built into their subscription fee so that's taken care of.
For perpetual license users (about 80% of my customers) they have to pay a subscription which guarantees all updates and major new version releases. This is done on a recurring payment basis so I have to spend very little time chasing renewals. I introduced this about 2 1/2 years ago and it now accounts for well over 30% of my income. It also means I'm not sweating and working like a dog to release a new version to get upgrade sales (which from 15+ years in running my own software business are ALWAYS disappointing) and means I can spend time developing knowing I'm getting paid. It also means that I release updates more regularly rather than working for 6 months+ or 1 year+ to get a new version out. The customers are happy cos they're getting regular updates and it's all included in 1 inexpensive annual fee. By releasing regularly rather than a big new version release it stop users from subscribing "just before" you release a major new version.
I'd recommend offering new customers 6 months subscription to an upgrade programme and if they want to subscribe to updates after that they can subscribe annually. Make sure you make it clear that you aren't making upgrades available for sale outside of an upgrade subscription.
There are a couple of downsides - for example I can't take 6 months out of developing ie to develop a new product etc cos users have paid for and are expecting regular updates. The other is that I've found a lot of customers are almost expecting a pseudo-bespoke development package and I've had a number of moans when I receive a suggestions and it's not immediately implemented in the next update. However that's more about managing customer's expectations than the programme itself.
I'd highly recommend doing it this way. It works for me :)
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz