[APBeta] V2.1 release schedule

[Dan Kuchta]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.astroplanner.net/pipermail/apbeta-astroplanner.net/attachments/20130610/e7ba0bf6/attachment-0003.htm>