 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / August 2007How to implement "Check for Updates"?
How do people implement this? A SOAP service? Thx > How do people implement this? A SOAP service? The Sparkle framework is a popular choice. Drop it into an app, put an XML appcast file on your server, and it just works. http://sparkle.andymatuschak.org/ http://code.google.com/p/sparkleplus/  SignatureTom "Tom" Harrington MondoMouse makes your mouse mightier See http://www.atomicbird.com/mondomouse/ >> How do people implement this? A SOAP service? > [quoted text clipped - 3 lines] > http://sparkle.andymatuschak.org/ > http://code.google.com/p/sparkleplus/ Thanks, I'll check it out. > How do people implement this? A SOAP service? If you think about it a bit, it turns out that you don't need any server-side smarts at all. For an absolutely minimalistic approach, all you need a is a simple file on your web server which contains the latest available version number. Then the client app can just fetch it and compare it against its version. If the version from the server is newer, pop up a window and take the user to your download page. To get fancier, you can augment the version number with extra information, like release notes to show to the user, and the download URL so that you can change it. Fancier still, you can download the updated version within your own application, then install it for the user. This is what Sparkle, mentioned else-thread, does. Fanciest, you can go with various delta updating systems so that you don't have to re-download the entire distribution each time. Interestingly, you can actually accomplish file-granular delta updates without any server-side smarts, just a bunch of static files. This works well on OS X where apps are a collection of a large number of mostly fairly small files. I implemented this in a few applications back before automatic update systems were all the rage. But I wouldn't do it again, the bandwidth savings simply are not worth the massive increase in effort required to create the system. As a final note, try to approach this deliberately and slowly, and even if you don't use Sparkle (which seems like a very good system), try to learn what you can from it. The reason for this is that most bugs are transient but updater bugs can be for life: if you ended up using a stupid URL for the update data in your 1.0 then you're stuck supporting that stupid URL *forever* even if you fix it in 1.0.1. SignatureMichael Ash Rogue Amoeba Software >> How do people implement this? A SOAP service? > [quoted text clipped - 31 lines] > the update data in your 1.0 then you're stuck supporting that stupid URL > *forever* even if you fix it in 1.0.1. Thanks for the reply, i don't need much at all. The file method might work for me. > > How do people implement this? A SOAP service? > [quoted text clipped - 6 lines] > If the version from the server is newer, pop up a window and take the user > to your download page. An even more simple check is if you just keep the current .dmg at a permanent URL and check the modification date. An interesting hybrid method is to put the app package up directly on the site and simply check the Info.plist file. > As a final note, try to approach this deliberately and slowly, and even if > you don't use Sparkle (which seems like a very good system), try to learn > what you can from it. The reason for this is that most bugs are transient > but updater bugs can be for life: if you ended up using a stupid URL for > the update data in your 1.0 then you're stuck supporting that stupid URL > *forever* even if you fix it in 1.0.1. A better approach is to ask yourself if users even care before you bother with the effort. I've never implemented update checks in my software because I find it endlessly annoying to be bugged by other people's software for the oh-so-terrible sin of trying to use the software I already have. Automated checking is one of the first things I turn off. Not to mention that 9 times out of 10 I'll see the update listed on a Mac software tracker (like my own! <http://mat.subsume.com/> :-) long before a built-in check is scheduled to happen. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, teranews.com, x-privat.org >> As a final note, try to approach this deliberately and slowly, and even if >> you don't use Sparkle (which seems like a very good system), try to learn [quoted text clipped - 11 lines] > listed on a Mac software tracker (like my own! <http://mat.subsume.com/> > :-) long before a built-in check is scheduled to happen. This is a very good point, although I must disagree with your conclusion. I think that they are very valuable, not just to users, but also to developers. I believe you are in the minority in disliking such things. My experience is that most users like to be as up to date as possible and they appreciate anything you do to reduce the effort they need to put in to stay that way. Speaking personally, I basically never visit software update sites and so the only way I'll discover updates, which frequently have essential bug fixes in them, is if the app tells me itself. Update systems also have benefits for developers by reducing the support burden. The easier it is for people to update, the fewer users you'll have running old versions, and the fewer support requests you'll get from people running old junk and running into some bug you already fixed. A good example of this is LiveDictionary. For a couple of years it was forced to use unsavory hacks which could be broken by any Safari update. As such I believed it was essential to ensure that users could get a fix in rapid fashion. Because of this situation I implemented a fully automatic update system for LiveDictionary. (Incidentally, this was released in April 2004. I'd be interested to know if anyone knows of earlier systems. Mine seems to have been well before the current wave of integrated updaters, anyway.) This allowed me to push out updates very quickly following system updates which I believe greatly reduced the problems users experienced in these circumstances, and consequently reduced the volume of e-mail I had to deal with following these updates. Obviously you should decide for yourself, and any automatic capability should be optional, but there are many benefits to it and frameworks like Sparkle make it very easy to integrate such a system into your product. SignatureMichael Ash Rogue Amoeba Software [snip] > > A better approach is to ask yourself if users even care before you > > bother with the effort. I've never implemented update checks in my [quoted text clipped - 8 lines] > I think that they are very valuable, not just to users, but also to > developers. He may be in a minority, but he's certainly not alone. I especially despise updaters that check when a program is started. I rarely use Adobe Reader; Preview does almost everything I need faster. But once in a while I get a pdf that I want to extract text from, and Reader has a convenient "save as text" option. It should take less than a minute to start Reader, open the file, and save it as text. Instead, it seems to me that every time I want to do it (ESPECIALLY if I'm in a hurry), there's some trivial update that I have to decide to install or not before I can get my work done. If an updater unobtrusively displays a window I can ignore, I'll tolerate it. If it browbeats me into updating, I'll find another application. Steve >[snip] > [quoted text clipped - 28 lines] > >Steve I agree, Adobe in general is the worst by far. Starting Photoshop takes forever, and it always seems to dump you into the automatic updater which then demands that you download 10s of megabytes of "Adobe Stock Photos" updates. > >> As a final note, try to approach this deliberately and slowly, and even if > >> you don't use Sparkle (which seems like a very good system), try to learn [quoted text clipped - 17 lines] > > I believe you are in the minority in disliking such things. There is no need to "believe" anything. It should be fairly easy to track who downloads what when and how. As a proponent, simply post the evidence you have. To support your point it should show that the majority of downloads are initiated from a built-in updater and are not correlated with the release date. > My experience > is that most users like to be as up to date as possible and they > appreciate anything you do to reduce the effort they need to put in to > stay that way. I *am* that kind of user. The problem is that built-in updaters are *not* timely and *increase* the bother of using the software. In many ways, you're doing a kind of premature optimization regarding software distribution. > Speaking personally, I basically never visit software > update sites and so the only way I'll discover updates, which frequently > have essential bug fixes in them, is if the app tells me itself. I think there is a little lie hidden in that statement that exposes your true advantage in using a built-in update. The lie, of course, is that if you don't use release tracker sites then it'd be hard to find software in the first place, built-in updater or not. The underlying truth, then, is that users visiting trackers may discover *other* software that does the job better than yours. I personally don't have a problem with a developer being selfish, but at least have the guts to bullet point vendor lock-in as a major advantage of using built-in updaters. > Update systems also have benefits for developers by reducing the support > burden. The easier it is for people to update, the fewer users you'll have > running old versions, and the fewer support requests you'll get from > people running old junk and running into some bug you already fixed. Everything in that paragraph is, at the very least, misguided. As you noted yourself, the developer takes on a *greater* burden by having to support yet another distribution method. Also, your support policy is independent of update methods; if your policy is only to support the newest version, take responsibly and simply state that instead of pretending a built-in updater makes a difference. > I believe greatly reduced the problems users experienced in these > circumstances, and consequently reduced the volume of e-mail I had to deal > with following these updates. All that points to is that *whatever* system you had in place before apparently made it easier to email you than to discover a newer version. There is no doubt that a built-in updater would address that, but there are all sorts of other support changes that could have been made to accomplish the same thing. > Obviously you should decide for yourself, and any automatic capability > should be optional, but there are many benefits to it and frameworks like > Sparkle make it very easy to integrate such a system into your product. Yeah, and there might be benefits for similar things like a crash reporter, but just because Apple has a closed system for those things doesn't mean that other Mac developers actually serve the users by presenting their own inconsistent implementations. If we want to have a discussion as a community, consistency is a more fruitful topic than which third-party frameworks can be used. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, teranews.com, x-privat.org >> This is a very good point, although I must disagree with your conclusion. >> I think that they are very valuable, not just to users, but also to [quoted text clipped - 7 lines] > majority of downloads are initiated from a built-in updater and are not > correlated with the release date. I'm not really able to comprehend how you're able to say this. Either you have an extreme lack of understanding of statistics or you've given up on facts while attempting to make your point. I have a conversion rate in the low single-digit percentages. I generally take this to indicate that the vast majority of downloaders decide they do not feel my program is worth the money and stop using it, and therefore do not hit the automatic updater. Given this situation, one would expect that normal downloads would vastly outweigh autoupdater downloads even if every single long-term user always downloaded every update using the autoupdater. So while you're correct that showing this would prove my point, it is utterly ridiculous to think that it's something I should be required to do. >> My experience >> is that most users like to be as up to date as possible and they [quoted text clipped - 5 lines] > ways, you're doing a kind of premature optimization regarding software > distribution. They do for you, they don't for me. We obviously have different tastes. This is why I think they should be optional. But I don't believe it's premature, just optimization. Not all optimization is bad. >> Speaking personally, I basically never visit software >> update sites and so the only way I'll discover updates, which frequently [quoted text clipped - 9 lines] > bullet point vendor lock-in as a major advantage of using built-in > updaters. After reading this paragraph I feel as though I am trying to explain Amazon to my grandparents. "You mean they just come in the *mail*? But how do you order? No no, I got the part about using your computer, but when do you talk to the sales girl?" Believe it or not, there are ways to discover new software which do not involve slavishly following software update sites. You may have heard of this web site called "Google", it's pretty cool. And there are these people called "friends", who often have neato recommendations. There is no lie in my statement, only truth. I find it interesting that you jump out with this utterly unjustified ad-hominem attack and decide to call me a liar because of some "contradiction" in my simple and truthful description of how I use and obtain software. Oh, and you also run a software update site. I wonder what *your* hidden agenda is. Note that I was entirely civil in this thread prior to this message. But any hostile tone you may find in this message is purely intentional: I don't like being called a liar just because I don't use your product. >> Update systems also have benefits for developers by reducing the support >> burden. The easier it is for people to update, the fewer users you'll have [quoted text clipped - 7 lines] > newest version, take responsibly and simply state that instead of > pretending a built-in updater makes a difference. Hey look, it's a tradeoff! Everything we do is about tradeoffs. This means that you are not allowed to say that my proposal is no good just because it involves tradeoffs. In my opinion, the *added* burden of implementing the autoupdate system is more than made up for by the *decreased* support burden of people with old versions. Is that sufficiently clear? Your statements imply that discovering a person who has asked for support is running an old version and getting him to update to the latest take no time or effort. The way I do things, I have to actually write e-mails to these people, and sometimes they are mistaken about their situation and think they're running the latest when they're not, and it all takes effort. Clearly I am being inefficient about this. Could you share your secret for accomplishing all of these things with no effort? I assume some sort of automated system, but so far my quests for an artificially intelligent support bot have met with no success. >> I believe greatly reduced the problems users experienced in these >> circumstances, and consequently reduced the volume of e-mail I had to deal [quoted text clipped - 5 lines] > are all sorts of other support changes that could have been made to > accomplish the same thing. Well apparently you didn't even read my entire message, because if you had, you would have noticed that this sytem was in place from day 1, so there is no "before". The paragraph you quote is speculation, hence "believe". You're right that there are other ways to accomplish this. However, I am enumerating all of the benefits of such a system, not all of the *unique* benefits of such a system. >> Obviously you should decide for yourself, and any automatic capability >> should be optional, but there are many benefits to it and frameworks like [quoted text clipped - 6 lines] > discussion as a community, consistency is a more fruitful topic than > which third-party frameworks can be used. And you're entitled to your opinion, but I disagree completely. It is unfortunate that Apple does not provide a unified software update for third parties but this does not mean we should refrain from creating our own. Sparkle is a fantastic framework and if it does not meet your needs then it is fairly easy to create a simple system which can accomplish many of the same things. Speaking of crash reporters, Smart Crash Reports is another valuable addition to your app. SignatureMichael Ash Rogue Amoeba Software > >> This is a very good point, although I must disagree with your conclusion. > >> I think that they are very valuable, not just to users, but also to [quoted text clipped - 11 lines] > have an extreme lack of understanding of statistics or you've given up on > facts while attempting to make your point. Come again? I'm directly *asking* you for facts that actually back up what you vaguely "believe". If you don't have them, just say so and concede the point. > I have a conversion rate in the low single-digit percentages. Irrelevant. You presumably have data for the set of users it *does* apply to. If you're putting out crippleware, or whatever would prevent users from getting future updates, that is a completely unrelated business decision. I'm not really interested in puzzling out those issues, I'm only interested in how useful the bother of built-in updates is. > So while you're correct that showing this would prove my point, it is > utterly ridiculous to think that it's something I should be required to > do. Yeah, it's impossibly stupid of me to approach this using a scientific process. Let's all instead just join hand in a circle and *believe* while we sing Kumbaya. > > I *am* that kind of user. The problem is that built-in updaters are > > *not* timely and *increase* the bother of using the software. In many [quoted text clipped - 4 lines] > This is why I think they should be optional. But I don't believe it's > premature, just optimization. Not all optimization is bad. Given that you have presented zero hard data in support of the value of built-in updaters, it is the very essence of premature. > You may have heard of > this web site called "Google", it's pretty cool. And there are these > people called "friends", who often have neato recommendations. Please. Google is rubbish for trying to find Mac software. Just *try* to create a plausible scenario where a potential user could find your LiveDictionary using Google. On MacUpdate, though, it's right near the top for the simple search of "dictionary". And a friend's recommendation is nice, but even they need to find the software in the first place. > I find it interesting that you jump out with this utterly unjustified > ad-hominem attack and decide to call me a liar because of some > "contradiction" in my simple and truthful description of how I use and > obtain software. I didn't call you a liar, I said your statement contained a lie. And while it might be convenient to think you can brush the issue under the rug by saying it is only you "personally" speaking (as though anyone would assume you spoke for someone else! :-), the reality is that a built-in updater *does* encourage lock-in, which is why you really should push that as an advantage when speaking to other developers instead of pretending it's all about the users. > Oh, and you also run a software update site. I wonder > what *your* hidden agenda is. There is nothing hidden. I directly state why I created a meta-tracker. The process of releasing software on all platforms, not just the Mac, is nothing short of sh.t and has actually gotten worse as the Internet exploded. It is nothing short of insane in this day and age that every site wants developers to manually enter data into a web form about each new version. > Note that I was entirely civil in this thread prior to this message. But > any hostile tone you may find in this message is purely intentional: I > don't like being called a liar just because I don't use your product. Oddly, I don't find anything hostile in your message, nor should you find anything hostile in mine. I've simply asked you to supply some hard data to back up your claims, and stop pretending things are so when they very well might not be. It is unreasonable to get bent out of shape over that. > Hey look, it's a tradeoff! Everything we do is about tradeoffs. This means > that you are not allowed to say that my proposal is no good just because > it involves tradeoffs. Maybe, but I am allowed to say your proposal is no good because it is a premature optimization. You have yet to demonstrate a net positive, so my conclusion is that a developer's effort is best spent on features that can actually be quantified. > In my opinion, the *added* burden of implementing the autoupdate system is > more than made up for by the *decreased* support burden of people with old > versions. Is that sufficiently clear? It always has been clear. What is not clear is why you are of that opinion when you have no sound reason to hold it. As I said, what versions you choose to support is unrelated to having a built-in updater. > And you're entitled to your opinion, but I disagree completely. It is > unfortunate that Apple does not provide a unified software update for > third parties but this does not mean we should refrain from creating our > own. I think it does. In fact, I think Apple's updater is also pretty shitty, so I think using that as any kind of reference is a step in the wrong direction. It may just be that this is a problem that doesn't have a cookie cutter solution. > Speaking of crash reporters, Smart Crash Reports is another valuable > addition to your app. No, it isn't. It's just another way bad developer f.ck over users for the sake of making their own lives a little bit easier. Go over to Windows if that's your cup of tea, because I'm getting fed up with it on the Mac as both a developer and *especially* as a user. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, teranews.com, x-privat.org >> > There is no need to "believe" anything. It should be fairly easy to >> > track who downloads what when and how. As a proponent, simply post the [quoted text clipped - 9 lines] > what you vaguely "believe". If you don't have them, just say so and > concede the point. You're asking me for *impossible* facts. It's as though you asked me to poll all 300 million US citizens in order to prove what's popular. >> I have a conversion rate in the low single-digit percentages. > [quoted text clipped - 4 lines] > issues, I'm only interested in how useful the bother of built-in updates > is. Let me see if I can make this clear. There are three ways to obtain my software: autoupdater, download URL off my web site, and from external sources. I have no reason to think that the external sources are significant, being a couple of magazine CDs and presumably things like getting copies from friends and shady pirate sites, so the first two are the significant ones. Note that the download link for people who are updating is *exactly the same* as the one for new users, so there is no way for me to distinguish between them without redoing my download process, which I'm not going to do for the sake of this thread. Even if I did, there would be nothing to prevent a great deal of users from downloading from the "new users" URL even though they're upgrading, skewing the stats. There are two groups of users: long-term and short-term. The long-term group would generally correlate well with the group of purchasers, which I do have good data on. The only group which is using the autoupdater is the long-term group, for reasons which I hope are obvious. The short-term group isn't using it because they don't keep the app long enough to update it. Due to the conversion rate, the short-term group outweighs the long-term group by something like a factor of 30-40. And you want me to prove my point by showing *more* autoupdate downloads than web site downloads? Even though by all rights, even if every single long-term user used the autoupdater, the normal downloads should outnumber it by at least an order of magnitude? >> So while you're correct that showing this would prove my point, it is >> utterly ridiculous to think that it's something I should be required to [quoted text clipped - 3 lines] > process. Let's all instead just join hand in a circle and *believe* > while we sing Kumbaya. You're demanding completely impossible statistics for my side, while presenting none for your side. >> > I *am* that kind of user. The problem is that built-in updaters are >> > *not* timely and *increase* the bother of using the software. In many [quoted text clipped - 7 lines] > Given that you have presented zero hard data in support of the value of > built-in updaters, it is the very essence of premature. Well hey, I have zero *hard* data as to how many users obtain my software off magazine CDs compared to my web site, why don't I just shut down the annoying and costly web site downloads altogether? People will appreciate the concreteness of having a CD and I'll save time and money. >> You may have heard of >> this web site called "Google", it's pretty cool. And there are these [quoted text clipped - 6 lines] > recommendation is nice, but even they need to find the software in the > first place. You want a plausible scenario? How about a Google search for, oh, "dictionary english netherlands", or "translation software mac os ox", or "free translation software japanese english for mac", or "safari chinese dictionary"? Note that I didn't have to *create* any of these, I just pulled them out of my logs. People *are* using Google to find my software. And even if my friends use these sites, that doesn't help *me* stay up to date with *my* software. And my friends can find new software through other means, whether it's using Google themselves, or simply making it. >> I find it interesting that you jump out with this utterly unjustified >> ad-hominem attack and decide to call me a liar because of some [quoted text clipped - 8 lines] > should push that as an advantage when speaking to other developers > instead of pretending it's all about the users. If I make a statement, and you say that statement contains a lie, then you are accusing me of making a lie, which means you are accusing me of being a liar. There is simply no way around it. Either retract your statement or admit that you think I'm a liar. You said that my proposed scenario of avoiding software update sites was *impossible*. Can't be done, you said. If I don't visit them in order to find out about new versions of my existing software, then I'll never find any new software. And yet here I am, not visiting those sites, but still finding new software. This is a contradiction! >> Note that I was entirely civil in this thread prior to this message. But >> any hostile tone you may find in this message is purely intentional: I [quoted text clipped - 5 lines] > they very well might not be. It is unreasonable to get bent out of > shape over that. You called me a liar and accused me of promoting a hidden agenda in this thread. Plenty of reasons to get upset. >> Hey look, it's a tradeoff! Everything we do is about tradeoffs. This means >> that you are not allowed to say that my proposal is no good just because [quoted text clipped - 4 lines] > my conclusion is that a developer's effort is best spent on features > that can actually be quantified. Sure, so lets cut off downloads (magazine CD being an entirely adequate means of distribution) support (they can figure it out for themselves) sales (most people pirate anyway) and anything else we don't have reliable statistics for the people who don't use what we offer. >> In my opinion, the *added* burden of implementing the autoupdate system is >> more than made up for by the *decreased* support burden of people with old [quoted text clipped - 3 lines] > opinion when you have no sound reason to hold it. As I said, what > versions you choose to support is unrelated to having a built-in updater. You haven't been giving any sound reasons either, besides a bunch of handwaving or your own personal views. The difference is that I admit it's a battle of opinions whereas you demand statistics (without providing any) and accuse me of trying to push a hidden agenda. >> And you're entitled to your opinion, but I disagree completely. It is >> unfortunate that Apple does not provide a unified software update for [quoted text clipped - 13 lines] > Windows if that's your cup of tea, because I'm getting fed up with it on > the Mac as both a developer and *especially* as a user. Obviously we will just have to agree to disagree. SignatureMichael Ash Rogue Amoeba Software > >> > There is no need to "believe" anything. It should be fairly easy to > >> > track who downloads what when and how. As a proponent, simply post the [quoted text clipped - 12 lines] > You're asking me for *impossible* facts. It's as though you asked me to > poll all 300 million US citizens in order to prove what's popular. Funny, but I'd be able to easily provide the same information by simply looking at HTTP access logs. This isn't the first impossible thing I've done before breakfast, so don't feel too bad. > There are three ways to obtain my software: autoupdater, download URL off > my web site, and from external sources. I have no reason to think that the > external sources are significant, being a couple of magazine CDs and > presumably things like getting copies from friends and shady pirate sites, > so the first two are the significant ones. There is a real pattern of baseless assumption in your posts. Instead of simply having "no reason", why not look into it? For example, I've seen non-trivial traffic for software (InstantLinks) based off a small, simple blurb in Mac OS X: The Missing Manual. Don't be so dismissive of external sources unless you have hard data. > Note that the download link for > people who are updating is *exactly the same* as the one for new users, so > there is no way for me to distinguish between them without redoing my > download process, which I'm not going to do for the sake of this thread. I don't understand why you couldn't track the stats based on user agent. I don't understand why you couldn't track the stats based on referrer. Assuming bad practices are in place for those, I don't understand why it'd be a major redo to add "?source=web" to a link or two and start tracking stats. > Even if I did, there would be nothing to prevent a great deal of users > from downloading from the "new users" URL even though they're upgrading, > skewing the stats. That is *not* skewing the stats, it is rather direct evidence that shows those users don't want to be bothered by crappy built-in updaters. If your aim is to intentionally discard that data, you're poisoning the pot. > There are two groups of users: long-term and short-term. The long-term > group would generally correlate well with the group of purchasers, which I > do have good data on. Data you still conveniently have not shown. > And you want me to prove my point by showing *more* autoupdate downloads > than web site downloads? Even though by all rights, even if every single > long-term user used the autoupdater, the normal downloads should outnumber > it by at least an order of magnitude? Take a deep breath and go back and read what I wrote. Let me help you out: "You presumably have data for the set of users it *does* apply to." So where is all this good data on that subset of users? > >> So while you're correct that showing this would prove my point, it is > >> utterly ridiculous to think that it's something I should be required to [quoted text clipped - 6 lines] > You're demanding completely impossible statistics for my side, while > presenting none for your side. I am in the fortunate position of not being the one making extraordinary claims. You are the one saying the bother of adding a built-in updater is worth it. All you have to do is show the evidence that proves it. > > Given that you have presented zero hard data in support of the value of > > built-in updaters, it is the very essence of premature. [quoted text clipped - 3 lines] > annoying and costly web site downloads altogether? People will appreciate > the concreteness of having a CD and I'll save time and money. You're actually helping me make my point. You absolutely *should* shut down your web site if you have no evidence that it is a net gain for you. Sorry to be reasonable about that and blow your attempt at sarcasm out of the water, but it is the right way to run a business. > >> You may have heard of > >> this web site called "Google", it's pretty cool. And there are these [quoted text clipped - 12 lines] > dictionary"? Note that I didn't have to *create* any of these, I just > pulled them out of my logs. People *are* using Google to find my software. Oh, man, does your data not support your points. If you'd actually attempted to construct a scenario based on your data it go something like this: 1. Enter into Google: dictionary english netherlands 2. Click somewhere beyond 10 screens of results (I'm not going to bother to see how far past that your site is actually listed). 3. Be surprised as hell to find any link that's still relevant. The people using Google are only *stumbling* across your software. Whatever contempt you have for tracker sites, most users specifically looking for Mac software will be better served by them than Google when the topic is so narrow and easily defined. > If I make a statement, and you say that statement contains a lie, then you > are accusing me of making a lie, which means you are accusing me of being > a liar. There is simply no way around it. Either retract your statement or > admit that you think I'm a liar. Again, I said your statement contained a lie, not that you were making a lie. Let me help you comprehend the difference with a non sequitur: women like flowers. Now it would be perfectly acceptable for you to say to me "Doc, you arrogant bastard, that's a lie because my wife is allergic to flowers." See how it is quite possible to state a lie without being a liar? If not, just to make you feel better, you're a filthy liar! :-) > You said that my proposed scenario of avoiding software update sites was > *impossible*. Can't be done, you said. Please quote where I said those things. No, what I actually did was have an "Ah ha!" moment that made me see why a developer *truthfully* was at an advantage in using a built-in updater. > You called me a liar and accused me of promoting a hidden agenda in this > thread. Plenty of reasons to get upset. Oh, grow up! I didn't do either of those things (except at your incessant prompting), and your skin would have to be pretty thin to get so invested in a Usenet discussion. That you went out of your way to deny something your weren't even accused of, though, is very "doth protest too much". > You haven't been giving any sound reasons either, besides a bunch of > handwaving or your own personal views. My sound reason was already given by you: it takes additional effort to implement and maintain a built-in updater. I think you'll find that a lot of things don't get added to software, even things that should (a favorite of mine is app-based URI handling defaults, especially when contrasted with Finder-based file handling defaults), because it isn't worth the effort. > Obviously we will just have to agree to disagree. That's always a terrible cop out. I'm actually here *begging* to be wrong! Aren't you willing to be wrong with the position you've taken? SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, teranews.com, x-privat.org >> You're asking me for *impossible* facts. It's as though you asked me to >> poll all 300 million US citizens in order to prove what's popular. > > Funny, but I'd be able to easily provide the same information by simply > looking at HTTP access logs. This isn't the first impossible thing I've > done before breakfast, so don't feel too bad. Could you explain how you differentiate between upgrading users and new users in a manner that's reliable enough to provide useful statistics? >> There are three ways to obtain my software: autoupdater, download URL off >> my web site, and from external sources. I have no reason to think that the [quoted text clipped - 7 lines] > simple blurb in Mac OS X: The Missing Manual. Don't be so dismissive of > external sources unless you have hard data. I'm not sure how I would do this, unless I did something like produce a special magazine build every time somebody asked me about one, and I just don't want to do that. Incidentally, magazine CDs are a place to get software without visiting software update sites, which you claimed can't be done. >> Note that the download link for >> people who are updating is *exactly the same* as the one for new users, so [quoted text clipped - 6 lines] > it'd be a major redo to add "?source=web" to a link or two and start > tracking stats. New user finds software on update site and downloads. Existing user finds new version on update site and downloads. I have no idea how you can possibly differentiate between those two scenarios unless you install spyware. Perhaps you have some suggestions? >> Even if I did, there would be nothing to prevent a great deal of users >> from downloading from the "new users" URL even though they're upgrading, [quoted text clipped - 3 lines] > those users don't want to be bothered by crappy built-in updaters. If > your aim is to intentionally discard that data, you're poisoning the pot. It's only evidence *if you can see it*. But since you can't detect it, it's not evidence. It *would be* evidence if you were omniscient, but alas I am not, and so I can't tell whether these downloads are new or existing users. >> There are two groups of users: long-term and short-term. The long-term >> group would generally correlate well with the group of purchasers, which I >> do have good data on. > > Data you still conveniently have not shown. Sorry, but you're not getting my sales statistics. Of course you didn't even ask for my sales statistics, and they are completely useless on their own. So why would I show them? >> And you want me to prove my point by showing *more* autoupdate downloads >> than web site downloads? Even though by all rights, even if every single [quoted text clipped - 4 lines] > out: "You presumably have data for the set of users it *does* apply > to." So where is all this good data on that subset of users? With my current setup, I can (but won't) give you three numbers: 1) Number of licenses sold. 2) Number of autoupdate hits per time. 3) Number of dmg download hits per time. Now, please recall that item 3 includes everybody who just tries the software, which is about 30 times larger than item 1. And item 2 must be in proportion to item 1. And now you said, "To support your point it should show that the majority of downloads are initiated from a built-in updater and are not correlated with the release date." In other words, you want me to give you stats where item 2 is larger than item 3. Despite the fact that I know, and you know, and anyone who's paying attention knows, that 3 is going to be many times bigger even in the scenario where every single long-term user uses nothing but the autoupdater. What makes you think I have good data on any subset of my users? All who download from my web site use the same link, and as I stated above it would be impossible to reliably differentiate between a new user downloading after being referred from an update site and an existing user doing the same thing. >> You're demanding completely impossible statistics for my side, while >> presenting none for your side. > > I am in the fortunate position of not being the one making extraordinary > claims. You are the one saying the bother of adding a built-in updater > is worth it. All you have to do is show the evidence that proves it. Extraordinary is in the eye of the beholder. Given the number of apps I have which have such systems, and which don't, I would say that the app makers (at least of the kind of software I use) are already on my site, and *you* are the one making extraordinary claims. All I'm saying is that people use built-in stuff when it's provided. You're saying that people hate it. Somehow I need to give evidence and you don't. Very clever of you, saves you a lot of trouble to be sure. >> > Given that you have presented zero hard data in support of the value of >> > built-in updaters, it is the very essence of premature. [quoted text clipped - 8 lines] > you. Sorry to be reasonable about that and blow your attempt at sarcasm > out of the water, but it is the right way to run a business. Alright, I welcome any suggestions on how to measure this. Please note that it would be possible in theory for all of my sales to come from downloads off of some bizarro Chinese pirate mirror which carries the exact same bits I offer for download. The default position is to think that most of my sales come from downloads on my web site. But there are a lot of other places people can get my software, most of which are extremely hard to measure. By your standard of proof I have no *hard* evidence that the web site is worth my money. >> You want a plausible scenario? How about a Google search for, oh, >> "dictionary english netherlands", or "translation software mac os ox", or [quoted text clipped - 15 lines] > looking for Mac software will be better served by them than Google when > the topic is so narrow and easily defined. You're changing the argument. I never said anything about "better served", I just said that *I*, *personally*, do not use them. >> If I make a statement, and you say that statement contains a lie, then you >> are accusing me of making a lie, which means you are accusing me of being [quoted text clipped - 8 lines] > without being a liar? If not, just to make you feel better, you're a > filthy liar! :-) Let's try another analogy. Me: "My wife doesn't like flowers." You: "There's a lie in that statement. If she doesn't like flowers, how can you show her that you love her?" Allow me to do quote your original statement: "I think there is a little lie hidden in that statement that exposes your true advantage in using a built-in update. The lie, of course, is that if you don't use release tracker sites then it'd be hard to find software in the first place, built-in updater or not." Remember now, that I was only speaking for *myself* here. I have no trouble finding new software despite not slavishly checking update sites every week. And yet you accuse me of lying and state that my personal habits, which I have followed for years, are impossible! Need I remind you that "lie" refers to *intentional deception*? It is not the same as a falsehood. Then you go on to say, "I personally don't have a problem with a developer being selfish, but at least have the guts to bullet point vendor lock-in as a major advantage of using built-in updaters." So not only am I liar, but I'm a selfish liar. Oh, but I shouldn't get upset, because you have a bunch of weasel words so you can make it look like you didn't mean to say what you said! Good luck with that. >> You said that my proposed scenario of avoiding software update sites was >> *impossible*. Can't be done, you said. > > Please quote where I said those things. No, what I actually did was > have an "Ah ha!" moment that made me see why a developer *truthfully* > was at an advantage in using a built-in updater. I said, "I basically never visit software update sites", and you said, "The lie, of course, is that if you don't use release tracker sites then it'd be hard to find software in the first place...." The only way I've been able to interpret this is that you think I'm unable to find new software, therefore couldn't have obtained what I have, therefore the scenario I describe is impossible. Maybe you did just have an "ah ha!" moment and you were just trying to apply these things to the general userbase and none of it was meant to apply to me personally. If that is the case then you did an utterly terrible job, and your wording came out looking like a personal attack. >> You called me a liar and accused me of promoting a hidden agenda in this >> thread. Plenty of reasons to get upset. [quoted text clipped - 4 lines] > deny something your weren't even accused of, though, is very "doth > protest too much". See above where I quote the bits where you called me a selfish liar simply for stating my own habits. >> You haven't been giving any sound reasons either, besides a bunch of >> handwaving or your own personal views. [quoted text clipped - 5 lines] > contrasted with Finder-based file handling defaults), because it isn't > worth the effort. Ah yes, positional definitions. "Sound reason" from you is a simple statement that effort is involved. "Sound reason" from me is a complicated set of web site statistics which involves modifications made to my software and web site. Double standard, anyone? >> Obviously we will just have to agree to disagree. > > That's always a terrible cop out. I'm actually here *begging* to be > wrong! Aren't you willing to be wrong with the position you've taken? I am not obligated to argue with every single point that gets made. You noticed the quoting, right? So that phrase only applies to your statement that Apple's updater is shitty, and that Smart Crash Reports is only so you can "f.ck over users". Neither point has any hope of generating a productive discussion so I refuse to address them further. There's no "cop out" present. SignatureMichael Ash Rogue Amoeba Software > >> There are three ways to obtain my software: autoupdater, download URL off > >> my web site, and from external sources. I have no reason to think that the [quoted text clipped - 11 lines] > special magazine build every time somebody asked me about one, and I just > don't want to do that. I never said you could easily track magazine users (though you might try to look for a traffic spike around the publication date). What I said is that you shouldn't discount the significance of such an external source for no reason. > Incidentally, magazine CDs are a place to get software without visiting > software update sites, which you claimed can't be done. Quote where I made that claim. What I *did* essentially claim is that you were disingenuous in suggesting that tracker sites aren't that useful to most people simply because you don't like to use them. All my server logs say you're wrong, and your logs probably say the same thing. > >> Note that the download link for > >> people who are updating is *exactly the same* as the one for new users, so [quoted text clipped - 13 lines] > I have no idea how you can possibly differentiate between those two > scenarios unless you install spyware. Perhaps you have some suggestions? You don't. Both cases go into the "a built-in updater is a waste of time" bucket. I'm not sure why you try to keep shifting this to a new vs. existing user issue. > >> There are two groups of users: long-term and short-term. The long-term > >> group would generally correlate well with the group of purchasers, which I [quoted text clipped - 5 lines] > even ask for my sales statistics, and they are completely useless on their > own. So why would I show them? I'm confused; what's your point here? Was this a failed attempt at trying to construct a straw man? All I'm asking for is a simple statement like "N% of registered users downloaded the last update using the built-in updater over 3 days after the release date". > What makes you think I have good data on any subset of my users? Because you f.cking *said* you did; go re-read the top of the last quoted block! Excuse me while I boggle at your inability to follow the conversation. > >> You're demanding completely impossible statistics for my side, while > >> presenting none for your side. [quoted text clipped - 7 lines] > makers (at least of the kind of software I use) are already on my site, > and *you* are the one making extraordinary claims. Just because a developer jumps on a bandwagon doesn't mean it's a good idea. The burden is still on you to show that the *use* justifies bothering with the implementation. > All I'm saying is that people use built-in stuff when it's provided. > You're saying that people hate it. Somehow I need to give evidence and you > don't. Very clever of you, saves you a lot of trouble to be sure. I didn't say people hate it, just that I always shut it off, and I have no problem agreeing that people will generally use what they're given. That doesn't make your case for you, though, because the issue is about whether or not the giving *causes* the use or merely *correlates* with it. That's why I asked for stats that are distanced from the release date, because it is quite possible for a user to read about an update on a web site or in a newsgroup *before* the app does its scheduled check, manually using the built-in updater not because it is better but just because it is there. > >> > Given that you have presented zero hard data in support of the value of > >> > built-in updaters, it is the very essence of premature. [quoted text clipped - 10 lines] > > Alright, I welcome any suggestions on how to measure this. I really can't run your business for you; I'd like to stay on the topic of software updates. I will say, however, that hosting a web site is so cheap these days that it's nearly at noise levels. Even if you never made a sale directly from it, there are many other net benefits that are worth the trivial cost. > > The people using Google are only *stumbling* across your software. > > Whatever contempt you have for tracker sites, most users specifically [quoted text clipped - 3 lines] > You're changing the argument. I never said anything about "better served", > I just said that *I*, *personally*, do not use them. I'm not concerned with your sample set sized at 1. Perhaps that is why you also got caught up with the lie/liar thing. I didn't change the argument, but rather followed it to where you took it. Your own evidence demonstrates that Google is just garbage for finding software. > Need I remind you that "lie" refers to *intentional deception*? It is not > the same as a falsehood. I wasn't looking for a political-level spin doctoring here. Try to skirt the *real* issue all you want, but the fact remains that one of the few *true* advantages of implementing a built-in updater is vendor lock-in. > Then you go on to say, "I personally don't have a problem with a developer > being selfish, but at least have the guts to bullet point vendor lock-in > as a major advantage of using built-in updaters." So not only am I liar, > but I'm a selfish liar. Oh, but I shouldn't get upset, because you have a > bunch of weasel words so you can make it look like you didn't mean to say > what you said! Good luck with that. You're the one breaking out "falsehood" as though it materially matters, so don't try to accuse *me* of using weasel words. The issue is that you're refusing to own up to the reality of things. The reality is that a developer benefits from lock-in. The reality is that Google blows for software searches. I don't particularly care to couch those phrases in some manner you find more palatable if that still won't get you any closer to agreeing with the underlying reality. > Maybe you did just have an "ah ha!" moment and you were just trying to > apply these things to the general userbase and none of it was meant to > apply to me personally. If that is the case then you did an utterly > terrible job, and your wording came out looking like a personal attack. No, you just *read* a personal attack into it. I obviously have no problem calling you a f.cking liar if I *wanted* to do that, but I didn't and you simply decided to get steamed. I honestly don't know or care if you have the best intentions for your users in implementing a built-in updater, but without any evidence that it *does* benefit them I, as a developer, naturally looked for how it would benefit you. > >> You haven't been giving any sound reasons either, besides a bunch of > >> handwaving or your own personal views. [quoted text clipped - 10 lines] > complicated set of web site statistics which involves modifications made > to my software and web site. Double standard, anyone? As I already said, yours is the extraordinary claim that requires extraordinary proof. Nobody said science is equitable. If you don't like being on the wrong side of it, simply change your position. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, teranews.com, x-privat.org [massive snippage, lack of response should not be taken to construe agreement, blah blah blah] >> Incidentally, magazine CDs are a place to get software without visiting >> software update sites, which you claimed can't be done. [quoted text clipped - 3 lines] > useful to most people simply because you don't like to use them. All my > server logs say you're wrong, and your logs probably say the same thing. Please quote where I said any such thing. All I said was that I don't visit them very often and so they're a bad way for me to stay up to date with my software. >> New user finds software on update site and downloads. >> [quoted text clipped - 6 lines] > time" bucket. I'm not sure why you try to keep shifting this to a new > vs. existing user issue. And once again you misunderstand the whole concept badly. You want me to give numbers showing that more people use the autoupdater than use the regular download. But such numbers will never happen, even if every single regular user uses the autoupdater for every single release. Is this sufficiently clear? >> > You're actually helping me make my point. You absolutely *should* shut >> > down your web site if you have no evidence that it is a net gain for [quoted text clipped - 8 lines] > made a sale directly from it, there are many other net benefits that are > worth the trivial cost. I thought you were all about measurement! Decent hosting will cost at least $100/year. In terms of the value of my time, this costs more per year than adding Sparkle support to my app, which literally can take ten minutes to implement. (Yes, I have done it in ten minutes, I'm not just making this up.) Why do you insist that I come up with elaborate and impossible statistics to prove the one, but you just say "eh, can't be proven, but there are plenty of side benefits" to the other? >> Ah yes, positional definitions. "Sound reason" from you is a simple >> statement that effort is involved. "Sound reason" from me is a [quoted text clipped - 4 lines] > extraordinary proof. Nobody said science is equitable. If you don't > like being on the wrong side of it, simply change your position. Please describe *why* it is an extraordinary claim. You keep saying this but you do not support it. In fact, you keep saying a lot of things but you do not support any of them. SignatureMichael Ash Rogue Amoeba Software > [massive snippage, lack of response should not be taken to construe > agreement, blah blah blah] [quoted text clipped - 9 lines] > visit them very often and so they're a bad way for me to stay up to date > with my software. I never claimed you said it, merely that it was suggested by what you said. As with the lie/liar thing, you seem to have serious reading comprehension issues. > >> New user finds software on update site and downloads. > >> [quoted text clipped - 16 lines] > > Is this sufficiently clear? Apparently still not to you. For the last time, I don't give a flying f.ck about the stats on the general population! All I'm interested in knowing is if the people who *can* make use of a built-in updater *do* significantly make use of it. Without any data from you or anyone else, the better option is to spend the time on other issues. > I thought you were all about measurement! I'm all about not wasting effort. If your $100/year hosting is a big bite out of your business, absolutely look into killing it. For most, though, bean counting that level of expense is yet another form of premature optimization. Triage is your friend. > In terms of the value of my > time, this costs more per year than adding Sparkle support to my app, > which literally can take ten minutes to implement. (Yes, I have done it in > ten minutes, I'm not just making this up.) Again, as you have noted yourself, the initial implementation is not the end of the story. You have to maintain the damn thing, and without stats there is no overwhelming reason to think it's worth the bother. > Why do you insist that I come > up with elaborate and impossible statistics to prove the one, but you just > say "eh, can't be proven, but there are plenty of side benefits" to the > other? It's not that the value of web sites can't be proven, but rather that they have, well beyond the scope of this discussion, *overwhelmingly* been shown to be a net gain for many different reasons across all types of businesses. The same cannot be said for using a built-in updater, and your (still) not providing stats doesn't shine any light into the darkness. > >> Ah yes, positional definitions. "Sound reason" from you is a simple > >> statement that effort is involved. "Sound reason" from me is a [quoted text clipped - 6 lines] > > Please describe *why* it is an extraordinary claim. Because that's the way science works. Believe all you want that praying to Elvis at a homemade shrine improves your karaoke act, but your belief is not reason enough for me to do the same. The same holds for other things like using a built-in updater. You have done precisely zero to actually show that anything you're doing accomplishes more than you doing nothing. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, teranews.com, x-privat.org >> [massive snippage, lack of response should not be taken to construe >> agreement, blah blah blah] [quoted text clipped - 86 lines] >actually show that anything you're doing accomplishes more than you >doing nothing. Nice rant. Obviously you are superior to anyone else posting into csmph, and obviously all these people should be doing your research for you. > Nice rant. Obviously you are superior to anyone else posting into > csmph, and obviously all these people should be doing your research for > you. On the contrary, I am obviously inferior because "all these people" (just Mr. Ash by my count, but I have a pretty nice kill file) because they seem to have found a silver bullet. I, too, would like one *if* it actually works. Sadly, as is often the case of reporting anecdotes with a sample size of one, no evidence has been offered that *they* have done *their* research. Until I see some hard data, I'm done with this thread. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, teranews.com, x-privat.org In article <droleary.usenet-360F07.06175329082007@sn-ip.vsrv-sjc.supernews.net>, > > Nice rant. Obviously you are superior to anyone else posting into > > csmph, and obviously all these people should be doing your research for [quoted text clipped - 6 lines] > a sample size of one, no evidence has been offered that *they* have done > *their* research. Until I see some hard data, I'm done with this thread. I get it-- you never implement anything in software unless you have incontrovertible scientific proof that the feature is worthwhile. Don't add a feature unless someone can produce detailed statistics proving it's worthwhile, right? Oh wait, I guess I must be in your "nice kill file"-- because you're only seeing a "sample size of one", despite my earlier participation in the thread (with numbers). Enjoy your little echo chamber. If you tune people out, they must not be saying anything. SignatureTom "Tom" Harrington MondoMouse makes your mouse mightier See http://www.atomicbird.com/mondomouse/ >> >> New user finds software on update site and downloads. >> >> [quoted text clipped - 22 lines] > significantly make use of it. Without any data from you or anyone else, > the better option is to spend the time on other issues. I'll try it one more time, then I'll leave you alone. My statistics cannot separate the general population from the people who can make use of the built-in updater but don't. Not only that, but as far as I can tell this separation is effectively impossible to do in any reliable fashion. Even if it were possible, I'm not doing it, and I'm not going to implement it just for the sake of this one thread. Clear? >> I thought you were all about measurement! > > I'm all about not wasting effort. If your $100/year hosting is a big > bite out of your business, absolutely look into killing it. For most, > though, bean counting that level of expense is yet another form of > premature optimization. Triage is your friend. So bean-counting $100/year is premature optimization but *not* beancounting a one-time cost of less than sixty minutes to add an automatic updater to your app is premature optimization? >> In terms of the value of my >> time, this costs more per year than adding Sparkle support to my app, [quoted text clipped - 4 lines] > end of the story. You have to maintain the damn thing, and without > stats there is no overwhelming reason to think it's worth the bother. I don't recall where I noted that myself and I really have no idea why. As part of the initial implementation you script every piece of the maintenance. My "maintenance" consists of literally seconds per release. I simply run a script, let it complete while doing much more painful tasks like filling out the forms on software update sites, then do a remote edit on the server and change a number in one file. If I really felt like it I could script that last bit too, so that the entire procedure would consist of a single command. >> Why do you insist that I come >> up with elaborate and impossible statistics to prove the one, but you just [quoted text clipped - 7 lines] > and your (still) not providing stats doesn't shine any light into the > darkness. For businesses which are not entirely web based, how was this shown? What statistics have you seen which cause you to believe this? Why do so many businesses still not have them if they have been so overwhelmingly shown to be a net gain across all types of businesses? >> >> Ah yes, positional definitions. "Sound reason" from you is a simple >> >> statement that effort is involved. "Sound reason" from me is a [quoted text clipped - 13 lines] > actually show that anything you're doing accomplishes more than you > doing nothing. Funny, you didn't answer my question. You're just reiterating what I have to do for my extraordinary claim. You haven't explained why you believe it's extraordinary. All I'm really claiming is that the < 1 hour of initial setup plus < 1 minute of work during each release will, over the lifetime of the product, more than pay for itself in terms of reduced support costs and higher customer satisfaction. Given the amount of time and money most developers spend on trivial junk like absolute pixel-perfect GUI elements, this does not seem to be a terribly extraordinary claim to me. SignatureMichael Ash Rogue Amoeba Software >> Apparently still not to you. For the last time, I don't give a flying >> f.ck about the stats on the general population! All I'm interested in [quoted text clipped - 9 lines] > reliable fashion. Even if it were possible, I'm not doing it, and I'm not > going to implement it just for the sake of this one thread. As far as I understand from your previous posts - only your registered users can use the built-in auto updater, right? In that case you should be able to check easily at least what is the percentage of your registered users that actually use the auto-updater. This doesn't provide the "hard data" to prove it being worth implementing and maintaining or not but can give some extra view on what is the added value for your users... >> My statistics cannot separate the general population from the people who >> can make use of the built-in updater but don't. Not only that, but as far [quoted text clipped - 9 lines] > maintaining or not but can give some extra view on what is the added > value for your users... Unfortunately that's not true, and I might not have made myself clear. I expect that it is mostly registered users who use the autoupdater, simply because unregistered users will presumably stop using the software after a while, whereas registered users will presumably keep using it. However, there are a lot of things which confound this link: - Of course registered users are free to stop using the app, and unregistered users are free to keep it, even though it will bother them a lot if they try to use it, but the autoupdater is linked to Safari so it will still notify them of new versions which they can download. - The trial period is ten launches of Safari, not counting a launch which happened within 24 hours of the last counted launch, so at least ten days. Looking at my download stats, the number of people who download the app in a ten day period is a significant proportion of the number of registered users, although there's no telling how many of them will keep using it for that long, but the people who download a trial version just before an update could make a significant contribution to the numbers. - Registered users may run the software on more than one machine. I don't mention or encourage this anywhere, but whenever people ask me I tell them to go ahead and use the same license for more than one machine as long as it's just for their own personal use. - Pirated users certainly exist and can use the autoupdater like anyone else. I have no clue how common they are. Further complicating the issue is the fact that my logs don't go all the way back to the last update so I couldn't count even if I wanted to without releasing a new version. A survey of the logs I do have reveals that daily autoupdate downloads amount to 1% of registered users, which seems surprisingly high for something which hasn't had an update since March. I'd guess that most of those people are people who are just trying it with an old version obtained somewhere, and they then hit the autoupdater when they run it. But that's just speculation. SignatureMichael Ash Rogue Amoeba Software In article <droleary.usenet-38C199.02443625082007@sn-ip.vsrv-sjc.supernews.net>, > > >> This is a very good point, although I must disagree with your > > >> conclusion. [quoted text clipped - 16 lines] > what you vaguely "believe". If you don't have them, just say so and > concede the point. Like I said in another post-- your requirements for such numbers are completely meaningless anyway, so what's the point in anyone trying to fulfill them? As Mike Ash said, you've constructed a scenario in which even overwhelming support among people who use a given app will still produce numbers that-- as you take it-- would suggest that auto-updates are a waste of time. There's no basis for either the idea that a majority of downloads are from auto-updates or for the random distribution over time. SignatureTom "Tom" Harrington MondoMouse makes your mouse mightier See http://www.atomicbird.com/mondomouse/ In article <droleary.usenet-6C1D5C.14052423082007@sn-ip.vsrv-sjc.supernews.net>, > It should be fairly easy to track who downloads what when and how. > As a proponent, simply post the evidence you have. To support your > point it should show that the majority of downloads are initiated > from a built-in updater and are not correlated with the release date. I could post some numbers from my server logs, but your restrictions above don't seem to make sense. First, why should the majority of downloads have to be from my auto-update system in order to show that it's valuable? If someone visits my web site and downloads my app, that reduces the percentage of downloads that are from the auto-update system. But it says nothing at all about whether that person will later find the update system to be valuable. And why not correlated with release dates? Why wouldn't they be? If people find the update system useful, why wouldn't they upgrade within a day or two of a new release? There's no basis for expecting auto-update downloads to be randomly distributed over time. For whatever it may be worth, the number of downloads from my auto-update system is more than 90% of the total sales of software which have that system. Some people may be getting auto-updates while testing the app, of course, but my numbers seem to indicate that my users mostly like the feature. Some don't, of course, but such data as I have suggests very strong support for the system. SignatureTom "Tom" Harrington MondoMouse makes your mouse mightier See http://www.atomicbird.com/mondomouse/ >>> How do people implement this? A SOAP service? >> If you think about it a bit, it turns out that you don't need any [quoted text clipped - 26 lines] > listed on a Mac software tracker (like my own! <http://mat.subsume.com/> > :-) long before a built-in check is scheduled to happen. Thanks for the reply. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.