December 14, 2024

Don't Be Evil, Yet

Mike at TechDirt writes:

As everyone is talking about Google’s (not particularly surprising or interesting) move into offering hosted business apps (basically taking their existing mail and calendar apps, and allowing you to run them for your business), it seems that the story of AOL’s new download software being criticized for secretly installing plenty of additional apps is perhaps more indicative of the drive away from client-side software. These days, it’s gotten to the point where you basically can’t trust any downloadable software at all not to clutter your machine, whether on purpose or not. So, while many people tout the “access it anywhere” or “no setup involved” features of web-based software, the simple lack of additional annoying crud getting installed on your computer may turn into a powerful added incentive for moving towards hosted apps.

The TechDirt guys are usually pretty sharp, but I’m afraid they’re too optimistic here. I’ll grant that today’s web-based software tends to come with less crud than desktop apps, but I doubt that will last.

It’s quite possible to distribute crud with web apps. AOL’s download app installed a browser toolbar; but a web-based app can carry its own crud-filled toolbar – it just has to put that toolbar inside the browser window, just above its app functionality. The main difference is that web apps’ crud has to be displayed inside the browser window, which doesn’t seem like much consolation to a user who depends on the web app.

So why is AOL distributing crud with its app while Google isn’t? One possibility is that Google practicing its “Don’t Be Evil” motto. Another possibility is that the companies are at different stages of a standard software business model, which goes like this:

  1. build market share
  2. lock in customers
  3. profit from lock-in

Economics tells us that if a customer is locked in so that he would have to pay a cost of C (in money or hassle) to stop using your product, then you can extract extra revenue of C from that customer. You can extract that value by charging him a higher price or by subjecting him to hassles that he would pay C to avoid. In this case the hassle is crudware that the vendor is presumably being paid to deliver.

AOL’s client software is at Stage 3 of this plan, so it makes sense for them to be cashing in with crudware. But Google’s web apps are still at Stage 1, where the goal is to attract customers. The same is true, presumably, of most web-based apps – which means that once we all come to rely on web-based apps, they’re likely to start delivering crudware too. Being an early adopter has its advantages.

Comments

  1. Christa Mereen says

    Why did you name this comapy after my dog fritz

  2. In response to Mike’s statement that “it’s gotten to the point where you basically can’t trust any downloadable software at all not to clutter your machine”, and in agreement with Phillip, there’s always free software.

    Developers of free software tend to make their apps behave very well because (in my opinion) 1) they are annoyed by crud and lock-in attempts themselves, and 2) they know that these kinds of “features” would just be removed if present.

  3. Has nobody noticed that giving all your documents to a search company might be really, really bad for your privacy?

  4. Google needs to lockin web users e.g. with gigabytes of personal information stored on their cyberspace servers instead of propreitary microsoft formats. Web users then are vulnerable to the 1-2-3 sequence of Getting Sucked in, Getting Locked in and then Paying to Avoid Migration costs.

    This is nothing new, For decades IBM and seven sisters tried to lock you in to their main/minis etc. to today’s consolidation around IBM 360/SunOS-Java/Microsoft Win-Office-.Net/Oracle PLSQL or even HP in Printers. This game continues with vendors like IBM now trying lockin by reemphasizing their “reassuring IBM-like” IT services, reliability, “grids”, Utility,etc. to wean the residual “babys” who are still stuck on Microsoft .Net/Java teats etc. back onto the IBM teat.

    I confronted Microsoft’s office products manager for Mac and he basically admitted to the diminishing returns (my words) of trying to add features or migrate users to “newer” revenue producing versions. He agreed that companies like ours who needed control of their own content can easily set up intra/extra/internet CMS systems that actually open up collaborative content. However he hinted few people had the sophistication necessary to do it like us and Microsoft WYSYWIG, UI-training kept users (“babys” in my words) locked in. I countered by saying the babies have grown up – witness YouTube postings, etc and teh UI-training is now browser UI. In other words their franchise is not end users now, but the medium paid legions of MS-certified IT babies now that depend on it for their jobs and keep microsoft-ware working in the bowels of enterprises today.

    On the web, AOL suffers from being the Pipe. In the US the cell/phone and cable providers protect their duopolies by pretending NOT to be just pipes, yet being unable to deliver innovative apps on the edge. Do you really think SBC/AT&T would have invented the Internet or have let it survive now? You got to be be crazy if you think comcast/AT&T will be anything other than profitable pipes. AOL bombed because it kept on obstructing innovative apps, rather than using its lead to promote them. The recent attempts to charge internet content publishers and establish toll-booths on the internet highway by cable/dsl providers is just another attempt to choke the internet-throat for profits.

    Going back to google, it seems there are no legions of IT-admins rooting for them and other than search, they don’t really have a firm lockin yet. Even Ads are only 3+ years old for them. But to give them credit, they are trying hard. Their core business is only the peripheral business of Yahoo/MSN and they have to be careful to coopt them not tread on too many fronts. In fact I think they are very adept at coaxing and frightening big old time media managers like AOL and MySpace into billion$ deals that consolidate Google’s hold. But I think those deals are getting steeper every time and pay-per-click returns are diminishing.

    However there is an alternative here for web users. People who are willing to stay open source can render impotent lockin attempts by Just dont use their proprietary stuff or migrate away from them. I can see using WiFi networks as a third path to avoid the cable/dsl monopolies.
    — More later.

  5. Except, hold on a minute,

    When we start to use web apps, our computing environment—the one thing you’re really trying to protect from crud—drifts off the local machine and into this fuzzy Internet place. More and more my data moves off the drive and onto the network somewhere. So do my app preferences etc.

    If one day we use web apps exclusively, the local machine will be so irrelevant to my environment that I can wipe the drive on lunch break, reinstall the OS, and continue working. Indeed a thin client OS will install clean in less time than it takes many operating systems to boot.

    It doesn’t matter whether the crud corrupts the local machine; what really matters is how much it corrupts your computing environment, wherever that is. Right now that’s mostly on the local machine, but if we used web apps exclusively, I would take little consolation in the fact that the local machine is crud-free. Just like I would take little consolation in the fact that the monitor doesn’t have a virus.

    Web-app crud would be something that corrupts your online filesystem, app preferences, etc. It doesn’t have to be overt corruption, but anything from rising complexity to feature creep. The fact that it doesn’t drift onto the machine is not much to brag about, if none of my stuff is there.

  6. Mike and Matt,

    I take your point — it does matter that web-based crudware is inside the browser window. That does help somewhat but not (I think) enough to make crudware a non-issue for users of web-based apps. The more you come to depend on (say) your web-based office suite, the more you’ll have that browser window up and open — and the less the in-browser nature of the crudware will matter.

  7. In reply to John E., John J, and Neo, I’ll agree that switching from desktop to web-based apps has its pros and cons. That’s an interesting topic worthy of future posts, but it’s not what I wanted to discuss here.

  8. It should be noted that going Web based carries a number of dangers for users.

    1. Users can’t choose not to upgrade, or choose to downgrade, because of a bug or because a newer version has steeper system requirements. If a change breaks things they can’t roll back.

    2. The app is not reliably available. It will require a network connection a downloaded one might not need. It will be unavailable if the remote server goes down. It will be unavailable if it is intentionally disabled by the vendor. Software on my own machine I can expect will continue to function until I uninstall or alter it somehow; a Web app may stop functioning on someone else’s say-so, including maliciously.

    3. The above DRM-like remote-deactavatability creates an obvious temptation for the software company to engage in extortion and other consumer-hostile behavior, and leverage to make their demands stick.

    4. Your data may also be held hostage. It may be in a format nothing else reads, so the vendor can withhold your data from you by withholding the app from you. Or the data may even be physically stored on their site. Advantage for user: accessible anywhere. Disadvantage for user: only accessible when the vendor wants it to be, giving them even more leverage to extort from you!

    This is another case of our property rights being undermined. We nearly fought WWIII over things like this — Western property rights vs. communism. Now we’re letting all sorts of companies get away with pushing us towards a situation where they’ll be able to say “All your data, gadgets, and tools are belong to us”.

    This trend must stop.

  9. Matt Norwood says

    I second Mike Masknick’s point above: browser-based crud may impede your ability to use THAT app, but it has no effect on the rest of your machine. This can still be a lock-in problem if you have to, say, migrate your data away from Google’s crud-filled app, but it’s a very different case from installing a desktop app, where the crud affects everything you do on the machine, sometimes when you’re not even running the app, and sometimes even after you’ve uninstalled the app.

  10. John E. makes a great point. Also consider the challangs Microsoft has with getting their countless users to apply critical security patches. With Google’s model, they can silently patch vulnerabilities (and YES, their will be vulnerabilities) without needing the users to do anything.

  11. john s erickson says

    I think that there is something different going on here. I think that Google’s services-oriented approach allows them to be much more agile in introducing and adapting new business models, and especially presenting much lower thresholds of adoption to the user. I would argue that the smaller client “footprint” (client app and bundled crudware) are part of that calculus.

    As a case in point, compare how quickly they can version and redeploy their client, in contrast to AOLs client. Users “upgrade” simply by returning to the service, in contrast to AOLs users who must make the decision, retrieve and perform the upgrade. Even without considering the (potential) bundling of crudware, this is a threshold that must be overcome.

  12. Hey Ed,

    Good point… but I think there’s still a difference. Web-based apps may include “crud” like toolbars within the app you’re using, but they don’t install crud on your hard drive that impacts it all the time, slowing down your machine and causing conflicts with other apps.

    I guess it’s possible that web-based apps will also try to get you to download crud as well, but I still think it’s pretty different.

    Mike

  13. enigma_foundry says

    Exactly, recal that AutoDesk supported and encouraged .dxf (drawing exchange files) before they were the dominant CAD vendor. Once they became a near monopoly, although they still supported .dxf files, you started losing features if you saved to .dxf. Then, their .dwg file formats became incompatble from version to version.

    The same pattern seems to be operative here, unless someone can posit an alternate business model…?

  14. Good point