[APBeta] V2.1 release schedule

Mon Jun 10 06:56:09 PDT 2013

No, I believe your scheme is the one I'm thinking of. I hadn't had my morning coffee. The scheme boils down to:

a. Initial licence fee (say $50) entitles you to latest release and any updates and further releases for a period of a year. Those updates and releases will continue to run and be useful to you forever.
b. At any stage in the future you can pay an upgrade fee (say $30) and the same deal as above.
c. There is no such concept as letting your licence "lapse". i.e. you can upgrade at any time.

Benefits to you: you don't need to pay if what you have is working fine, and the latest release doesn't have any new features of interest. It keeps me on my toes and constantly innovating in order to get you to be tempted to upgrade. If I don't innovate, you don't pay.

I proposed this scheme a year or three ago and it was almost unanimously rejected. I guess it was matter of "better the devil you know...".

Fortunately, I have a fairly consistent stream of new users, but I believe the above scheme would work better for both you and me. When I _do_ release a major release, it's all champagne and fast cars for a month or two.

Paul R.

On Jun 10, 2013, at 6:24 AM, Dan Kuchta <dankuchta at gmail.com> wrote:

> Hi Paul:
> 
> >> ... I suggested a "licencing" form of updates, where you paid, say, an annual fee to get any improvements ...
> 
> I'm not sure if we're talking about exactly the same thing here.  It's that "annual fee" that I think people object to.  The way it's worded in your note, it infers that you pay every year, on some yearly schedule set by the developer.
> 
> With the scheme I'm talking about, you only pay when you think there's enough new features or bug fixes to warrant the price.  And the schedule is different for each individual.  In other words, if I buy a license for a year's worth of upgrades on June 1, I can get any updates released before June 1 the following year.  For another uses who buys a license in October, it goes until October of the next year.  Again, the expiration date is encoded in the key and is compared to the release date of the software.
> 
> While these may seem like small differences from an annual fee program, to me it puts control in the hands (and wallets!) of the users.  You don't feel like you're tied to a "rental" fee for the software that needs to be paid on a set schedule every year.  Just my 2 cents, but I find this to be a very nice way to do things.  It doesn't make me feel like the software vendor is trying to suck a steady income stream out of me.  And it allows me to reward the vendor's hard work with a payment when I feel like the additional features have reached critical mass, based on *MY* needs.  If there's lots of new features that I don't care about, then I don't need to pay just yet.
> 
> -Dan   
> 
> 
> On Mon, Jun 10, 2013 at 8:51 AM, Paul Rodman <paul at ilanga.com> wrote:
> This was the scheme I proposed for V2 onwards. However, it was shot down in favor of the "pay for a major release and subsequent bug fixes only" scheme. It would mean lots of smaller incremental releases and bug fixes, rather than interminable beta periods, etc.
> 
> It's the scheme used by the purveyors of the development software I use (recently renamed Xojo). 
> 
> Paul R
> 
> 
> On Jun 10, 2013, at 4:30 AM, Dan Kuchta <dankuchta at gmail.com> wrote:
> 
>> Hi Paul:
>> 
>> Just wanted to mention an update fee scheme that's used on one piece of software I own, that I think works particularly well.
>> 
>> The license key has encoded in it in some way, an expiration date for updates.  When a user downloads a new version and goes to install it, it will first notify the user if the update was created after the key's expiration date and offer to sell the user a new one that will last for another year, or whatever the appropriate time frame is.  If the user doesn't really want the upgrade that badly, he can choose to continue using his existing version as long as he wants.
>> 
>> The nice thing about this is that there is no yearly "subscription" fee for the user to pay or for the developer to keep track of.  If the user is happy with their current version, they can use it without extra charge for as long as they want.  This also frees the developer from worrying about what goes into a major release, when it's appropriate to charge for a release, etc.  The developer can just create releases with whatever he wants, whenever he wants. 
>> 
>> Note that the way this works is based on the expiration date of the key and the date the software was released.  In other words, if a key lasts for a year, a user can still use a 2-year old key as long as the update he's downloading was released over a year ago.  This means you'd want to maintain some number of older releases available for those people who didn't get around to downloading at the right time.
>> 
>> Not sure if you could implement something like this for Astroplanner, but it always seemed like a very equitable way to handle updates to me.
>> -Dan
>> 
>> 
>> 
>> On Jun 7, 2013, at 12:19 AM, Paul Rodman <paul at ilanga.com> wrote:
>> 
>>> Well, the reason behind producing monolithic major releases is so that I can generate income from updates. Making continual small updates doesn't allow for update fees. I suggested a "licencing" form of updates, where you paid, say, an annual fee to get any improvements to the app during that year, but no-one was interested in that.
>>> 
>>> I believe V2.1 will be the last minor release before the next major one (V3), although there might be a 2.1.1 bug fix release if it's warranted. I have to (a) figure out if I still have enough energy for V3, and (b) what would go into it. After 2.1 leaves the factory I plan on taking a small sabbatical to ponder these issues, and to update AstroAid.
>>> 
>>> Paul R.
>>> 
>>> On Jun 4, 2013, at 12:37 AM, Ken Harrison <kenm.harrison at gmail.com> wrote:
>>> 
>>>> Paul,
>>>> Great news!
>>>> As I've mentioned...may be the time has come to let your "child" leave home....
>>>> Can you make the V2.1 the "official" release version and only do further "updates" on an adhoc basis??
>>>> (The AAVSO are also dragging their feet when it comes to accepting spectroscopy as another tool for variable star observing.)
>>>> 
>>>> 
>>>>  
>>>> On 4 June 2013 02:42, Paul Rodman <paul at ilanga.com> wrote:
>>>> My current plan is to release V2.1 on or before the end of this month (June). The main issues I have been and will be attacking (telescope mount and ASCOM) are showing signs of being resolved. Other than that, there's a plethora of smaller issues to deal with, and a manual to update.
>>>> 
>>>> Sadly, I will not be able to get any AAVSO stuff going as "promised", since the AAVSO people don't seem to be much interested in cooperating with outside developers these days. Much of the AAVSO stuff that still lurks in V2.1 will disappear, since it just causes nasty crashes at this point in time.
>>>> 
>>>> Paul R.
>>> 
>>> _______________________________________________
>>> APBeta mailing list
>>> APBeta at lists.astroplanner.net
>>> http://lists.astroplanner.net/listinfo.cgi/apbeta-astroplanner.net
>> 
>> 
>> ================================================================
>> God grant me the Senility to forget the people I never liked anyway,
>> The good fortune to run into the ones I do,
>> And the eyesight to tell the difference.
>> 
>> _______________________________________________
>> APBeta mailing list
>> APBeta at lists.astroplanner.net
>> http://lists.astroplanner.net/listinfo.cgi/apbeta-astroplanner.net
> 
> _______________________________________________
> APBeta mailing list
> APBeta at lists.astroplanner.net
> http://lists.astroplanner.net/listinfo.cgi/apbeta-astroplanner.net
> 
> 
> _______________________________________________
> APBeta mailing list
> APBeta at lists.astroplanner.net
> http://lists.astroplanner.net/listinfo.cgi/apbeta-astroplanner.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.astroplanner.net/pipermail/apbeta-astroplanner.net/attachments/20130610/05a85dee/attachment-0003.htm>