[APBeta] V2.1 release schedule

[Dan Kuchta]

Hmmm ... I must have missed it when you proposed it last time.  Either that
or it was described a little differently and I may have drawn some
incorrect inferences.  In any case, as you may have noticed :-), I'm all
for it!

On the other hand, those fast cars and champagne sound pretty good! ;-)
-Dan


On Mon, Jun 10, 2013 at 9:56 AM, Paul Rodman <paul at ilanga.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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/0c834555/attachment-0003.htm>