<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Importance Of Self Updating Applications</title>
	<atom:link href="http://www.agilemicroisv.com/2009/01/the-importance-of-self-updating-applications/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agilemicroisv.com/2009/01/the-importance-of-self-updating-applications/</link>
	<description>Small fish. Big pond.</description>
	<lastBuildDate>Thu, 11 Mar 2010 08:05:18 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mark S</title>
		<link>http://www.agilemicroisv.com/2009/01/the-importance-of-self-updating-applications/comment-page-1/#comment-14</link>
		<dc:creator>Mark S</dc:creator>
		<pubDate>Wed, 28 Jan 2009 20:20:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.agilemicroisv.com/2009/01/the-importance-of-self-updating-applications.html #comment-14</guid>
		<description>&lt;p&gt;We have a home grown auto-update mechanism, that works much like
what you&#039;re doing. When the application runs, the thread kicks off,
checks, and if there is something, balloon tip.&lt;/p&gt;

&lt;p&gt;The problems we&#039;ve run into:&lt;/p&gt;

&lt;p&gt;We offer a choice: Install now. Remind me later. Skip update.&lt;/p&gt;

&lt;p&gt;Why did we do that? Well, because we figured this mechanism would
not just be for bugfix updates, but also for major upgrades where we
would change upgrade fees. But IMO it&#039;s a mistake to offer the choices.
We should just do the install of bug fixes and minor version updates...
For major version upgrades ($), we should probably alert them and give
them a link to a landing page that sells them the benefits of
upgrading. Let that be manual download and installation.&lt;/p&gt;

&lt;p&gt;Despite putting a message in during the major upgrade process
explaining that continuing with the installation would require $$, we
created significant anger and frustration out of users who thought we
were trying to bilk them out of money for updates. &lt;/p&gt;

&lt;p&gt;Second issue, giving people a chance to skip the update results in
people not installing fixes. Then you get support calls that would be
resolved had people just updated.&lt;/p&gt;

&lt;p&gt;We&#039;re in the home user market BTW.&lt;/p&gt;

&lt;p&gt;Here is another thing to consider. Lifetime updates or only minor
version updates? How about if they bought version 2.2, and 3 weeks
later version 3.0 comes out. I think these are other topics that you
should explore ahead of time and make good decisions on.&lt;/p&gt;

&lt;p&gt;If you don&#039;t have lifetime updates, then you&#039;ll be supporting two or
three versions of the product in the field, and getting support calls
for bugs that were already fixed, and feature requests for features
that are already implemented in newer versions had the person just
upgraded. You have to figure out the profit made from upgrades and
compare it to the costs of all of those support calls. (IMO, lifetime
updates is the way to go. It&#039;s just worth it to have everybody as
up-to-date as possible.)&lt;/p&gt;

&lt;p&gt;Lifetime updates also eliminates issues that arise from people who
bought and then a new version comes out and they want a free upgrade.&lt;/p&gt;

&lt;p&gt;Alternatively, there is the subscription model, which you can offer
people the latest version as long as they maintain their subscription.&lt;/p&gt;

&lt;p&gt;Alternatively, you can change your model so that new features are
delivered via &quot;add-ons&quot; rather than major version upgrades. So that you
can keep people up-to-date with the latest version of the core product
(essentially lifetime updates there), while delivering new features via
&quot;add-ons&quot; that they would pay for separately.&lt;/p&gt;

&lt;p&gt;These last two alternatives seem the best of choices. They allow
automatic, silent updates, reduced support calls, money from existing
customers who buy from you again and again, and I imagine, the happiest
customers who always feel like they are getting their money&#039;s worth.&lt;/p&gt;

&lt;p&gt;Man, did I just ramble or what!   ;-)&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>We have a home grown auto-update mechanism, that works much like<br />
what you&#8217;re doing. When the application runs, the thread kicks off,<br />
checks, and if there is something, balloon tip.</p>
<p>The problems we&#8217;ve run into:</p>
<p>We offer a choice: Install now. Remind me later. Skip update.</p>
<p>Why did we do that? Well, because we figured this mechanism would<br />
not just be for bugfix updates, but also for major upgrades where we<br />
would change upgrade fees. But IMO it&#8217;s a mistake to offer the choices.<br />
We should just do the install of bug fixes and minor version updates&#8230;<br />
For major version upgrades ($), we should probably alert them and give<br />
them a link to a landing page that sells them the benefits of<br />
upgrading. Let that be manual download and installation.</p>
<p>Despite putting a message in during the major upgrade process<br />
explaining that continuing with the installation would require $$, we<br />
created significant anger and frustration out of users who thought we<br />
were trying to bilk them out of money for updates. </p>
<p>Second issue, giving people a chance to skip the update results in<br />
people not installing fixes. Then you get support calls that would be<br />
resolved had people just updated.</p>
<p>We&#8217;re in the home user market BTW.</p>
<p>Here is another thing to consider. Lifetime updates or only minor<br />
version updates? How about if they bought version 2.2, and 3 weeks<br />
later version 3.0 comes out. I think these are other topics that you<br />
should explore ahead of time and make good decisions on.</p>
<p>If you don&#8217;t have lifetime updates, then you&#8217;ll be supporting two or<br />
three versions of the product in the field, and getting support calls<br />
for bugs that were already fixed, and feature requests for features<br />
that are already implemented in newer versions had the person just<br />
upgraded. You have to figure out the profit made from upgrades and<br />
compare it to the costs of all of those support calls. (IMO, lifetime<br />
updates is the way to go. It&#8217;s just worth it to have everybody as<br />
up-to-date as possible.)</p>
<p>Lifetime updates also eliminates issues that arise from people who<br />
bought and then a new version comes out and they want a free upgrade.</p>
<p>Alternatively, there is the subscription model, which you can offer<br />
people the latest version as long as they maintain their subscription.</p>
<p>Alternatively, you can change your model so that new features are<br />
delivered via &#8220;add-ons&#8221; rather than major version upgrades. So that you<br />
can keep people up-to-date with the latest version of the core product<br />
(essentially lifetime updates there), while delivering new features via<br />
&#8220;add-ons&#8221; that they would pay for separately.</p>
<p>These last two alternatives seem the best of choices. They allow<br />
automatic, silent updates, reduced support calls, money from existing<br />
customers who buy from you again and again, and I imagine, the happiest<br />
customers who always feel like they are getting their money&#8217;s worth.</p>
<p>Man, did I just ramble or what!   <img src='http://www.agilemicroisv.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>
